Tomas Votruba has a new post to his site about an update that's been made on Statie, a static site generation tool, to support Twig templates natively.

Statie supports YAML and Symfony Dependency Injection for some time. But you wanted more! You wanted Twig. Sculpin and all the other PHP generators have it.

So there you go! Enjoy.

He shares the three steps needed to set up a sample Twig template and have it rendered as easily as the normal Statie templates:

1. Prepare Layout _layouts/default.twig
2. Create Template contact.twig
3. Enable Twig

Template contents and configuration change examples are included as well as instructions on how to update to this latest (v5.4) version. He includes tips on the naming and locations of the template files as well as a mention of his package to help translate from Latte to Twig templates.

In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

On the Exakat blog there's a post that covers assertions in PHP, a built-in tool the language provides to help perform simple value based evaluation against certain criteria.

PHP has a clever native debugging tool : the PHP assertions. In a nutshell, assertions are a function call to assert(), that triggers an error when a condition is not satisfied.

[...] Unlike debugging conditions, the assert() syntax has to be read in a positive way. When the condition, aka as the first argument, is satisfied, all is fine, and process goes on; when the condition is not satisfied, then an error is triggered: the message of the error is the second argument.

The post then gets into more detail about the assertions, noting that the result has to be positive and that they can be somewhat configured (basically turned on/off and the error level can be adjusted). It also covers some examples of things to test with assertions, how they should be treated as debugging and to avoid using them on resources outside the code (like database connections).

If you weren't able to make it to this year's ZendCon conference that just happened in Santa Clara, you can get at least a little piece of it from this new post to the Zend blog. It's a video from a keynote session from Peter Magnusson titled "Rise of the Native Cloud Developer."

At his keynote session at ZendCon, he shared some of the important and sometimes unexpected lessons Google learned while building for the cloud – such as the importance of lightweight execution containers, relying on failure, and how to overcome the speed of light when building distributed systems.

And then he went ahead to discuss about the rise of the “Cloud Native” developer – how engineers and organisations large and small now using these principles to build truly robust and scalable services, and businesses.

You can watch it embedded in the post or full size on Youtube.

On the Systems Architect blog there's a recent post from Lukasz Kujawa about comparing Apache2 and Nginx for PHP applications, specifically when using the PHP-FPM module. His tests are based on the results from three different application types - a large Zend Framework 1 app, a small PHP script and a WordPress installation.

If you’ve ever been trying to squeeze more out of hardware you must have come across Nginx (engine x). Nginx usually appears in context of PHP-FPM (FastCGI Process Manager) and APC (Alternative PHP Cache). This setup is often pitched to be the ultimate combo for a web server but what that really means? How much faster a PHP application is going to be on a different web server? I had to check it and the answer as often is – that depends.

He ran the tests on an Amazone EC2 instance and optimized the server to ensure that there was a little interference as possible. The used the Zend Optimizer Plus opcode cache and PHP 5.4 and set the logs to go to memory instead of disk. Graphs included in the post show the results of the benchmarking of each application, with the differences (in most cases) not being that wide of a gap.

There isn’t big difference between Apache2 and Nginx in PHP context. Yes, Nginx can be much faster when delivering static content but it won’t speed up PHP execution. Running a PHP script seams to be so CPU challenging task that it completely eclipse any gain from a web server.

Timothy Boronczyk has written up a new post that looks at using assertions in PHP - the actual use of the assert function to evaluate values in your code.

I stumbled upon assertions in PHP today, though why I didn't know they existed after working with the language for so long and what I was looking for originally when I came across them are both mysteries. And with the increasing focus on software quality in the PHP community, I wondered why I hadn't seen them used by others. I decided to ask around, look into PHP's implementation of assertions, and do some tinkering.

He talks some about their usage, some of the common issues surrounding them and compares using them directly on return values vs evaled strings. He also includes an implementation of them in a bit of sample code - a class that uses them (and an assertion callback) to handle the throwing of exceptions.

Assertions are meant to identify program logic/design bugs, not as a run-time error handling mechanism. Isn't this why we do unit testing? Playing devil's advocate, what's wrong with pushing unit tests directly into your code if we have doc comments that are extracted for documentation?

Miro Svrtan has a new post today proposing something that could be added to help handle bad method calls in PHP apps - using the BadMethodCallException (pre-existing) instead of throwing fatal errors.

Using getter method that is not implemented will get you fatal error saying how undefined method is called and request will stop. [...] On the other hand if you would use public property all you would get is a notice saying how this property does not exist and rest of request would be completed. [...] I know that this is due to dynamic typing behavior of PHP and no I am not suggesting raising a notice if undefined method gets called but since 5.1.0 there is a BadMethodCallException class which would be perfect for this situation.

There's been other people that have proposed the same idea as a bug, but nothing formal has been submitted as an RFC to make the change. Miro is looking for feedback to find if others would be interested in this feature and want to make the proposal (leave comments here).

Nikita Popov has posted a plea to developers and project maintainers alike to stop using XML for their configuration files in their PHP-based applications.

I recently tried using Phing (a PHP build system) to do some simple release automation. Just creating a PEAR package and doing a few string replacements here and there. The result? After several wasted hours I ended up using Phing only for PEAR packaging and doing everything else in a custom PHP build script. The reason? Phing uses XML files to configure what it should do during a build.

He advocates a more native solution - a PHP script that defines the configuration options as a part of an object that can be injected into the parts of your app without the need for external dependencies.

Ariz Jacinto has written up a new post with the commands you'll need to get PHP up and runnign with MSSQL Server's native ODBC driver working on linux (accessible through PDO).

Last month, MS announced the preview release of SQL Server ODBC Driver for Linux, a 64-bit binary driver for Red Hat Enterprise Linux 5. This is good news for companies using heterogenous platforms e.g. LAMP stack running a PHP application that connects to both MySQL and MSSQL Server. Meaning, these companies no longer have to use third-party drivers such as FreeTDS that MS doesn't support. Then a few days ago, MS released version 1 of the driver. I immediately downloaded the driver and recompiled PHP with it as a PDO (PHP Data Object) ODBC driver.

His process has five steps to it, including one for making a test script (code included) and another with a few gotchas/performance considerations to keep an eye out for when using the driver.

Fabien Potencier has posted another in his "getting better" series looking at the features that are included in the Symfony2 framework. In this new post he talks about the improvement annotation support.

Later today, I will release Symfony2 beta2. But first, I wanted to talk about a big change that landed into master yesterday. As you might know, Symfony2 uses annotations for Doctrine mapping information and validation configuration. Of course, it is entirely optional, and the same can be done with XML, YAML, or even PHP. But using annotations is convenient and allows you to define everything in the same file.

Two new bundles were added, SensioFrameworkExtraBundle and JMSSecurityExtraBundle, that let you use annotations in the controller for configuration. Examples of this new feature are included in the post giving the configuration settings a more "native" feel.