Recently in PHP Category

At IPC 2008 I presented a 60 minutes Session on Making Selenium Test Writing easier using a DSL.

Here the short description:

Implementing automated tests by using Seleniums API methods has several drawbacks. Selenium is great for what it does, providing a generic framework for testing a generic application. Using the Testing_SeleniumDSL framework, I will show you how to create your own Domain Specific Language (DSL), which would allow you to write tests in the language of your business rather than in Seleniums language.

Here is the slide of this session:

At IPC 2008 I presented a full day workshop on Quality Assurance in PHP Projects - In-Depth Best-Practises together with my colleague Wojciech Duda.

Here the short description:

So you know PHPUnit, Selenium, phpUnderControl or CruiseControl and other tools to support testing efforts during your development process. But how does the puzzle of all those tools actually fit in your development process? During this Power Workshop Max Horvath and Wojciech Duda of studiVZ Ltd. will tell you about the everyday life at the Quality Assurance Business Unit. You will learn about best practices, which actually work and fit into an extremely fast moving iteration cycle at one of the biggest and fastest growing Social Networks in Europe. Talking about PHPUnit and Selenium, including tips on how to optimize using those tools, we will also show show you how you should integrate the testing process into your main development process, to be as lightweight and efficient as possible.

Here is the slide of this full day workshop:

SQL injection attacks can allow hackers to execute arbitrary SQL commands on your database through your website. To avoid these attacks, every piece of data supplied to your web application, either via a web form or via web services, or other means, must be validated to not contain information that is not expected.

GreenSQL is a firewall for SQL - it sits between your Website and your MySQL database server and decides which SQL statements should and should not be executed. GreenSQL is distributed under the GPL license.

Introduction

GreenSQL is a proxy for MySQL databases. Web applications should connect to GreenSQL which will forward legitimate SQL queries to your MySQL database, after running the query through a filter. The result of the query will be returned though GreenSQL, too (it is a proxy). If GreenSQL detects a query that is not whitelisted and that includes suspicious SQL, it will block that query and return an empty result set without contacting the MySQL database.

GreenSQL consists of two components: the proxy server / firewall itself and the management interface. You can see a demo of the management interface at demo.greensql.net.

The proxy server / firewall is written in C/C++ and the management interface in PHP.

Even though GreenSQL hasn't reached the 1.0 status, there are already packages for popular *nix distributions like FreeBSD, Debian, Ubuntu, Fedora and SuSe available. Compiling from has been made much easier now, too - there is a automatic database configuration tool, which makes installation much easier than before

Using GreenSQL

The GreenSQL configuration file allows you to set how risky you think certain things are. For example you can assign a weight to the use of certain keywords. The logic is based on evaluation of SQL commands using a risk scoring matrix as well as blocking known db administrative commands (DROP, CREATE, etc). After a specific block level has been reached, the query will not be forwarded to the MySQL server.

The management interface gives you an overview of queries used to contact your MySQL database. Given those details, it's easy to fine tune the rules. Each time GreenSQL considers a SQL query as a security risk - it is blocked. You can alter this behavior for a specific query by explicitly adding it to the whitelist.

Conclusion

GreenSQL is production-ready, yet. But you should keep an eye on it and give it a try in some of your test project - I think it has a huge potential.

Today I released the first public version of my new library PHPTypeSafe. It provides the ability to use PHPs Type Hinting feature for scalar values.

The PHP way of Type Hinting

PHP 5 introduced Type Hinting. Functions were now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). But Type Hints can only be of the object and array type. Traditional Type Hinting with int and string isn't supported.

There were several request on the PHP internals maillinglist to introduce Type Hinting for scalar values, too. All of them got rejected, but at the moment there's a request for comment going on at the PHP Wiki. Besides Type Hints for scalar values the proposals also includes Type Hinting for return values. While the first proposal can be done in the userland, the later can only be archived by changing PHP itself.

So what does PHPTypeHint offer?

By including PHPTypeSafe in your project you will be able to use Parameter Type Hinting for scalar values, the compound type object and the special type resource. A simple example on how to use this functionality would be:

The output would be:

PHPTypeSafe offers the support for the following types:

• boolean (including alias bool)
• float (including aliases double and real)
• integer (including aliases int and long)
• object (generic object matcher)
• resource
• string

Every type hint matcher is strict (so '1' won't match with the integer type hint), as you shouldn't use type hints if you aren't sure about the given /required type of value. (Those cases could still be checked using is_str(), is_int() and the like.)

Requirements and where to get it

PHPTypeSafe has been written using namespaces and is being packaged as a Phar PHP Archive. That's why it requires you to use PHP 5.3 (or later).

You can download PHPTypeSafe at dev.maxhorvath.com.

Feedback

I would be very happy to receive your feedback on how you like the library and if there are any issues on how to use it.

As expected by many, Eclipse PDT's next major release has been postponed.

While two milestones couldn't be released, it became clearer and clearer that the release date of September 15th 2008 couldn't be met.

On December 29th 2008 Eclipse PDT 2.0 will hit the street

There is one milestone and two release candidates planed, before the final version is being expected to be released on December 29th 2008.

Personally I don't mind the delay, as PDT 2.0 will include many improvements to the current version:

• PHP Model Infrastructure
• Mark Occurrences
• Type Hierarchy View
• Override Method Annotation
• New PHP Explorer capabilities
• Extended Open Type
• Code Templates
• Code Assist for Dynamic Variables

One of the other reasons I see for delaying PDT 2.0 (hey - they bumbed the planned 1.1 release to 2.0) is a huge internal API change, also introduced because of the switch to Eclipse DLTK (Dynamic Languages Toolkit - a tool for vendors, researchers, and end-users who rely on dynamic languages).

Well, at least chances might be good they will include (at least a basic) Phar support.

As PHP 5.3 is marching towards the final release, Eclipse PDT's next version needs to support its new features. Two major additions to PHP 5.3 are namespaces and bundling the Phar extension. Especially used in combination, libraries could/should be distributed like Jars in the Java world.

The Phar extension provides a way to put entire PHP libraries or applications into a single file called a "Phar" (PHP Archive) for easy distribution and installation. Phar archives are best characterized as a convenient way to group several files into a single file. As such, a Phar archive provides a way to distribute a complete PHP library or application in a single file and run it from that file without the need to extract it to disk. Additionally, Phar archives can be executed by PHP as easily as any other file, both on the command line and from a web server. Phar is kind of like a thumb drive for PHP applications.

PHP 5.3 and Eclipse PDT 2.0 will soon hit the street

With Eclipse PDT 2.0 to be released in September (or October) support for namespaces is already on the roadmap. Support for Phar archives has not been listed, yet. But in my opinion Eclipse PDT 2.0 must support handling Phar archives when PHP 5.3 will hit the street.

Playing around with PHP 5.3 HEAD and Eclipse PDT 2.0 HEAD I've discovered several drawbacks of the yet missing support for Phar archives - here are the most important ones:

• You cannot browse Phar archives.
• Because of the disability of Eclipse PDT 2.0 of browsing Phar archives you cannot see in the outline which classes are inside of the Phar archive.
• You cannot debug Phar archives. (Eclipse won't open a Phar archive.) (Using Xdebug or Zend Debugger does not change the situation.)

Debugging Phar archives using Xdebug is still an issue with the current stable release (Xdebug won't return enough information to browse the Phar archive), but Derick is already working on solving that issue. I didn't try the Zend Debugger - I don't even know if it runs with PHP 5.3.

Requirements for the Phar support are still to be defined

So opened an feature request at the Bugzilla issue tracker of Eclipse PDT. Roy Ganor, the team leader of the Zend Development Tools Group, responded quite fast and said, that the development team of Eclipse PDT already talked about the support of Phar archives but couldn't decide on requirements.

He asked me to help out and define proposals for requirements in a PDF file or the Eclipse PDT wiki.

Before providing proposals for requirements of the support of Phar archives for the next version of Eclipse PDT on my own, I wanted to ask the PHP community (especially those using Eclipse PDT / Zend Studio for Eclipse), what kind of Phar support they would like to see in Eclipse PDT 2.0.

Please do not hesitate on responding /commenting on this article, as there's not much time left before Eclipse PDT 2.0 shall hit the streets - and I wouldn't like to miss Phar support in this great IDE.

Zend Studio for Eclipse is a commercial edition of Eclipse plus the PDT plugin and various other additions. Unfortunately Zend decided to disable the Xdebug support of the Eclipse PDT plugin. Nonetheless if you'd like to use Xdebug for debugging your PHP scripts, follow these simple steps to restore the Xdebug functionality of Eclipse.

How to enable Xdebug support

First you need to quit Zend Studio for Eclipse if it is still running.

• Got to your Eclipse folder, for this article for instance /usr/local/ZendStudio:
  cd /usr/local/ZendStudio.
• Enter the plugins folder (i.e. /usr/local/ZendStudio/plugins):
  cd plugins.
• inside the plugins folder create a new folder named disabled (i.e. /usr/local/ZendStudio/plugins/disabled):
  mkdir disabled.
• Now move all files starting with com.zend.php.debug into the disabled folder:
  mv com.zend.php.debug* disabled.
• Go back to your main Zend Studio for Eclipse folder and start it via:
  ./ZendStudio -clean.
• Xdebug is available in the main preferences dialog under PHP Debugging.

If you're working on Windows or Mac OS X, the procedure is likewise - you just need to remember the differences on the command line.

Conclusion

In order to get Xdebug working you now need to setup your computer like it is required for Eclipse PDT. Your can find the manual at http://www.eclipse.org/pdt/documents/XDebugGuide.pdf.

The only drawback is that profiling via the Zend Debugger doesn't work anymore in Zend Studio. But for this I would suggest to use Xdebug and KCacheGrind.

Aside from being a member of the advisory board of this years International PHP Conference, I will present one Full Day Workshop and one session at this year's edition of the International PHP Conference:

Quality Assurance in PHP Projects - In-Depth Best-Practises

Full Day Workshop

So you know PHPUnit, Selenium, phpUnderControl or CruiseControl and other tools to support testing efforts during your development process. But how does the puzzle of all those tools actually fit in your development process? During this Power Workshop Max Horvath and Wojciech Duda of studiVZ Ltd. will tell you about the everyday life at the Quality Assurance Business Unit. You will learn about best practices, which actually work and fit into an extremely fast moving iteration cycle at one of the biggest and fastest growing Social Networks in Europe. Talking about PHPUnit and Selenium, including tips on how to optimize using those tools, we will also show show you how you should integrate the testing process into your main development process, to be as lightweight and efficient as possible.

I will present this session together with my colleague Wojciech Duda.

Making Selenium Test Writing easier using a DSL

60 minutes Session

Implementing automated tests by using Seleniums API methods has several drawbacks. Selenium is great for what it does, providing a generic framework for testing a generic application. Using the Testing_SeleniumDSL framework, I will show you how to create your own Domain Specific Language (DSL), which would allow you to write tests in the language of your business rather than in Seleniums language.

I hope to see you in Mainz, Germany in late October!

While it's absolutly correct that direct access to private properties is strictly forbidden in PHP, it's quite disturbing that even reflection cannot do it when you're writing Unit Tests. Sometimes you just want to test whether a private property contains the correct data. With the normal visibility rules you cannot access those from your Unit Tests.

Luckily, as I just read at Tobias Schlitt's Blog, Derick Rethans committed a patch to the PHP 5.3 repository, which allows you to get things done quite easily. You still need to explicitly state that you want to access the value of a protected/private property through reflection by the new method setAccessible(). It's a good thing to avoid people doing stupid things accidentally, but you finally get the access to it.

PHP 5.3 you'll be able to access private properties like this:

But until we'll see a stable PHP 5.3, there we're many working "hacks", which worked for some versions of PHP 5.x - the most current one would be this:

This should get you up and running for PHP 5.2.5 ("older hacks" won't work).

So how could you use it?

I hope those lines of code will help you until PHP 5.3 arrives, as it helps our developers.

Update

As Sebastian points out in his comment to this post, PHPUnit has had support for testing private and protected attributes for quite a while. It can be used via:

I should be reading the documentation much more thoroughly next time (even though I must admit, that none of our developers has known this method, too).