Experiences Developing PHP Extensions

In the past I had done a lot of development in C and C++. It used to be the language I worked the most with. C++ can help make developing a complicated application far easier than writing it in pure C. I have moved away into doing more Java work in the last four years. I started with PHP during the latter part of the C/C++ period. I wanted to try to work on developing a PHP extension based on some C and C++ code I had written a number of years ago.

Reading about extension writing appears very intimidating because of the Macros and Zend api aspects. Starting off from scratch this can be very challenging, particularly setting up the structures and the boilerplate as it were for the extension. PHP is written in standard K&R C so that it can be compiled on any platform, which is a great feature, but the code is very intricate, particularly when it comes to object oriented code and reference counting. There have been articles written about wrapping C++ classes into PHP extensions, which seems like a possibility in terms of working with C++ libraries. You physically can build extensions with C++, but for wider distribution on PECL writing your extensions in C is probably the smarter way to go.

I found a Pear project to do the code generation for PHP extensions. This project takes an xml descriptor including code blocks, which generates all the code especially the boilerplate code. It seems to be promissing, It seems it’s best to  continually doing edits in the .xml file and generating new sets of code whenever possible as it makes it easier adding new functions. This approach also adds the necessary support for unit tests. Certain aspects of it seems to not be as well flushed out as could be. In a more complex extension, going beyond what is provided with this project.

PHP uses the the GNU Autotools system, autoconfigure and automake to configure builds. It makes use of M4 macros to manage and extending the basic scripts. It provides a way to interrogate the system and determine the options needed to build a piece of code on a given system. Unfortunately this doesn’t work on Windows. Windows requires a separate build script system in JScript. Aspects of the M4 macros can be challenging to understand which may be a problem with more complex projects.

PHP uses a unit test system using files with snippets of code, expectations, etc, that once one completes make on the extension make test will execute the test and show test results. You write these tests through the .xml described above.

Redis, the more Powerful NoSql Alternative to Memcached

The NoSql Paradigm has proven to be an interesting alternative to rdms systems, particularly where having a system that is more flexible than one requiring a very complicated Schema to account for complex aspects of an application, particularly those that change quickly. Document oriented systems such as Mongodb are useful to fit this type of problem. It supports highly scalable sharding system. Mongodb can become complicated, when sharding is involved, but other systems can as well. If you want to store complicated model data, Mongodb is a good choice. It offers good performance and features. Memcached is a key value store which has had a following for caching website content and mysql queries. It is a purely memory based store. Mongodb, on the other side is a disk based store using memory mapping of the file, disk storage and disk I/O is always involved.

An interesting alternative to Memcached with more than just a get/set model as well as solving the problem that Memcached has to solve. This is Redis, a key value store featuring in addition to simple key value features, lists, sets, and hashes. Even in the plain key space, redis ads features such as in place string manipulation. With these new data types, it features atomic operations on these protecting the integrity of the data contained within. Memcached is a good product for what it is, a cache system and key value store but it’s limited in terms of the sematics it supports for more complicated uses, and the developer winds up writing more complicated code to deal with the limitations.

Redis is also fast. It is comparable in speed to Memcached. A writer did a benchmark comparison, though Salvatore Sanfililipo the lead developer of Redis found the benchmark problematical including it  being a tight loop which didn’t show how it behaved with many clients. This benchmark showed Redis slightly slower than memcached. A rewritten apples to apples benchmark showed Redis performing slightly better, particularly under more clients. Even with this comparison, it seems like comparing apples to oranges in a way, the comparison doesn’t show a comparison to a product with comparable features.

Redis is a newer product, though the developers focus on a high quality product with fast performance. The newest version is in release candidate status, with new features to manage multiple keys in one command, and future clustering and sharding features coming. Personally I am not sure of the value of these, but I am user there are those who can use them. One challenge are the clients. There are clients for many languages, even the estoeric. There are a number of php clients. The most mature however only works with php-5.3 and requires namespaces, a feature that has value, but if you are supporting 5.2 servers it won’t work. There is a C based php module, but it is very new and not in the Pecl collection yet. One I like, Rediska, written by a russian group which is well designed, performs well, and integrates very well with Zend Framework.

Problems with Early Android Tablets

A full range of tablets have been developed using the Android operating system. The new 3.x Honeycomb versions such as the Motorola Xoom (below) represented a major change for tablets. This is an operating system with many features to help provide a base for a powerful and highly interactive solutions. Initially Android was not built for tablets, only smaller devices such as phones. Eventually support for large screens was added but it was really minor changes and the Ui was not built for tablets. I have several android applications, which later I will have honeycomb specific versions which will make use of the new user interface features. In the mean time I was working on support for the older larger screen devices like the Samsung Galaxy tab (left), which is a non-standard aspect ratio 600 x 1024 dpi, people have reported problems with applications on this device. A developer can rework a layout for specific Android software versions or device features such as aspect ratio. One still is relying on the operating system scaling the layout to fill the space. Android has predefined screen sizes, which one can use and the emulator knows how to use these predefined sizes, but when device manufacturers built tablets from the older, the sizes didn’t exist. A developer dealing with this situation may say, skip the older tablets and spend the energy on the newer tablets, which may be the best solution.