On the Laravel Daily site there's an interesting article that shares some opinions on when to use Laravel and when to use WordPress as a base for your applications.

In PHP world there are two big groups of developers – those who work with Content Management Systems (WordPress, Drupal etc.) and those with frameworks (Laravel, Symfony etc.). And rarely people work with both worlds – cause their philosophy is fundamentally different.

But when you get a new project from a client – how to decide whether Laravel is the best choice? Or maybe simple WordPress would be enough and would save time/money? Sometimes it’s not that easy to decide. So here are my tips – questions you need to ask.

In the remainder of the article he suggests four questions to ask yourself to help make the decision one way or another:

• Content or user actions?
• Plugins or packages?
• MVP or serious project?
• Who will work on the project?

He elaborates on each point with a bit more context and criteria that could help answer the question in your case.

The SitePoint PHP blog has a new tutorial posted by Reza Lavaryan showing you how to "supercharge your applications" with the help of the Blackfire.io profiling service.

With profiling, we can spot the performance bottlenecks in the code and do something about them. There is a variety of profiling tools out there, each taking a different approach. [...] With profiling, we can spot the performance bottlenecks in the code and do something about them. There is a variety of profiling tools out there, each taking a different approach. [...] Blackfire.io is the new generation of web profilers, which takes the automatic instrumentation approach, but without imposing a performance impact on our application.

First he defines some of the basic terms it's helpful to know when profiling and using Blackfire. He then walks you through getting what you'll need set up:

• a Homestead VM instance with the necessary configuration options
• a script using Faker to generate and write user data to a local database

He then shows you how to execute the first profiling run and what the results look like in the Blackfire views. He uses these results to make some modifications to the script and re-runs the tests to see what kind of gains it provides. Most of his examples use the web interface for the service but the post ends with a look at using the command line tool and getting back some simple metrics as a result.

Jani Hartikainen has posted the second article in his series looking at parsing PHP with Haskell (part one is here). In this new article he builds on the parser he built last time and gets to the actual evaluation of the PHP code.

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.

In this new post to his blog Evert Pot reminds you (the PHP developer) about the loose and strict typing checks that you need to do when checking the values of your variables and never just assume. PHP's loose typing tendencies can cause issues if you're not paying attention.

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.

In a recent post to his blog Ian Barber looks at applying Benford's Law in PHP to determine if the dataset you're working with is "real" or not.

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.

Kevin Schroeder has a new post to his blog today on how to correctly evaluate the Zend Server product from Zend (disclaimer: he is a Zend employee).

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.

In a recent entry to his blog Sean shows off a new specifications library he's created to replace common comparison functionality with a series of specs.

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.

The PHPBuilder.com site has a quick reminder about a handy little bit of functionality PHP has to make evaluations quicker - the ternary operator.

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.

Rob Thompson has posted about some simple benchmarking he did comparing the speed of a series of "if" statements versus one "switch" with multiple cases.

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().

In a new post today, Padraic Brady asks the community for any kind of input as to what they've seen for behaviour-driven development in PHP:

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.