Unusual Site Speedup Techniques debate, Named parameters and Annotations - Lately in PHP podcast episode 6

By Manuel Lemos

manuellemos.net

<email contact>

.

Contents

Listen or download the podcast, RSS feed and subscribe in iTunes

Read the podcast transcript

Introduction (0:20)

Unusual Site Speedup Techniques (00:40)

The (non-)adoption of named function parameters and annotations in PHP (43:38)

PHP Programming Award nominees of August 2010 (1:02:36)

Conclusion (1:08:39)

Introduction (0:20)

Manuel Lemos: Hello, welcome to the Lately in PHP Podcast, this is episode number 6 of October.  As usual I have here with me Ernani Joppert, my regular co-host, hello Ernani, how are you doing?

Ernani Joppert: Hello, Manuel, I'm doing great.  Glad to be here again, welcome everyone.

Unusual Site Speedup Techniques (00:40)

Manuel Lemos: Well, this episode we will have a special topic that I believe it will be of great interest of most of the listeners.  I will be talking about a series of articles that I have been writing lately regarding unusual site speed-up techniques that I've been implementing in the PHP Classes site, and actually the server that runs also the JS Classes site.

And these articles focus on unusual techniques that I've been implementing to make things run smoother and have a greater perception of speed from the part of the users, and this will be a very interesting podcast. 

This podcast is also a thing that I'm going to start now which is having sponsored shows, and right in this first sponsored show our sponsor is NuSphere.

NuSphere is the company that develops PHPEd IDE for developing PHP applications.  As far as I know it's the first commercial PHP IDE that was ever developed, and it includes the DBG extension which is used for debugging PHP programs, and it was written by Dmitri Dmitrienko which is one of the co-owners of NuSphere.

Actually I met Dmitri many years ago at the International PHP Conference of 2001 in Frankfurt, and it was nice to meet him in person right in the moment that he was just introducing the DBG extension for debugging PHP programs.

But talking a bit more in detail about the PHPEd that NuSphere is making available for many years as I mentioned, it is one kind of IDE which I noticed that is very fast, even when it is managing large projects.

It is a Windows application and it runs on Windows environments and it is implemented as a native IDE, I mean it's not a program written in Java that is on top of a Java virtual machine and that actually makes it very fast. 

Despite PHPEd is a Windows application you can also run it on Linux and MacOS, you can use either VMware or Parallels virtual machines or use Wine Windows emulator which is probably a better solution because it will run integrated in your Linox or Mac desktops.

Another interesting aspect of this IDE is that as many other IDE's, it implements code folding and completion, not only on PHP but also HTML, CSS and JavaScript, which makes it pretty much complete for most PHP applications.

It supports all major PHP frameworks like Zend Framework, CodeIgniter or CakePHP, and this support in practice means that it can complete code that uses the classes of those frameworks, so it is well aware of those frameworks and if you are developing PHP applications using those frameworks it works quite nicely.

It provides a very advanced debugger like many other debuggers that let you run PHP programs and single step on them with breakpoints, it has a nice feature that at least so far I have not seen in other debuggers which is the ability to debug multiple PHP scripts running in parallel.

This may happen for instance when you have a PHP script web page that is for instance calling another PHP script that is running as a Web service, and this parallel debugging support of PHP is great because it lets you debug both scripts running at the same time. You can check variables and the state of the scripts on each side.

Other than that it features a very nice profiler. For those not familiar with what a profiler is good for, it's basically a program, method, that lets you run a script program and outlines sections of the program that are running faster or slower. And this is helpful to let you figure where you should focus your efforts to optimize your PHP code.

So it was great to have NuSphere as sponsor of this podcast, and they were also nice because they are providing to the listeners of the Lately in PHP Podcast to get PHPEd with a special discount, and to benefit from that discount you can go to phpclasses.org/sponsor/nusphere, and on that page you will find a discount coupon code that you can use to obtain a great discount if you are willing to purchase this PHPEd IDE, which I thoroughly recommend.  So, thank you again NuSphere for the sponsorship.

But now moving on with our podcast I am going to get back to our main subject of this podcast which is the topic of the articles that I have been writing, unusual site speed-up techniques.

Basically it is a series for now made of three articles, and on the first part I focus in the aspects related with the front-end, the web browser itself.  One aspect that I have focus is something that has been affecting the PHP Classes site perception of speed on the part of the users for many years.

Basically the PHP Classes site has several spots that present advertising, and that advertising is retrieved from remote servers of the ad agencies that negotiated the ads that are presented in the site.  So, to make those ads appear in the pages what I do is basically place some HTML tags with JavaScript that retrieve the remote JavaScript that generated the actual HTML that makes the ads appear.

Well, the problem with this is that it slows down the load of the rest of the page on each spot where the advertising appears. The browser actually stops and only proceeds rendering the rest of the page when it has finished loading the ads.

So this gives a bad feeling to the users that the site is slow, and actually the site is not slow, the pages are actually served very quickly, but since there are ads delaying the page, not just ads, there are other elements on the page like widgets, like Facebook widgets, Twitter widgets for retwitting the URL's of the pages themselves, and all of that delays the load of the page.

And unfortunately this has been a reason for many complaints from the users that have been unsatisfied with this situation.  So I have thought about the problem and I figured that it would be great if somehow I could move the position where the ads appear on the page to the end of the page which is the basic solution that I used to avoid that ads delay the load of the page.

And I used a JavaScript component that is actually published in the JSClasses site that makes all ads and widgets load at the end of the page in a hidden div tag, and when the ads are finished loading they move the DOM nodes, the elements that constitute the ad, to the original positions where they should appear.

And the result was awesome, it was great, and now the users can quickly see that the page loads immediately, it does not take much time to load, and it is a solution that actually is giving a greater sense of speed to the users.

I hope that the users will no longer complain about the speed of the loading of the pages as they used to so far.  Ernani, have you noticed this difference of the loading speed of the site from about one or two weeks ago until now?

Ernani Joppert: Oh, yes.  Basically when you hit the site today you don't get that waiting time and the feeling that the page is not completed in time, and once the page is fully composed then you can see the ads popping up.  So, it really improved the quality of the visualization and most likely it would also benefit the user and yourself as well, so I strongly recommend the users to adopt this technique.

Manuel Lemos: Yes, for those interested to actually adopt this technique, the article that I mentioned has a link to a tutorial in the JSClasses site that teaches users how to embed this JavaScript component that makes it easier to use this solution in a systematic way.

And other than that, one reason that I was concerned if this would be a good idea or not is that once the ads load faster I wonder if the users will notice them more or less. I was afraid they would notice the ads less and in the end they would not even click on the ads as much as before.

Surprisingly the result is quite the opposite. What seems to happen, although I'm not 100% sure that this could be the reason, is that the users are actually noticing the ads more and the click through rates have improved.

And this seems to be a good sign that it is possible to make things faster without compromising the possibility of the users noticing the ads and clicking on them.

I would also like to just make a side comment that the PHP Classes site puts ads on the pages obviously because it needs the advertising revenue that the advertising generates regularly. And it was never my intention to somewhat upset the users with the amount of ads that are on the page, but I hope the users understand that the ads are really necessary.

But moving on to the next article that I have written right after that first one about unusual site speed-up techniques, this article, this second article, talks about a different problem that I tried to solve that was happening in the PHP Classes site which is basically the fact that a web server does not just run processes that serve web pages.

There are a lot of other processes running in the background to perform other tasks that are important for the maintenance of the site, for instance, like delivering newsletters and alert messages that are going out practically all day, and this kind of background process competes for the CPU that is also shared with the processes that serve the web pages because it is currently all running in one server, a one-server machine.

And I looked at the problem that was happening because as the number of newsletters being delivered as well as other tasks like backup tasks that are generating backups to save the data to safe places, and as well another task that is going on for a long time during the day in the PHPClasses site which is the indexing the content of the pages for providing a good search system that provides updated results, that is another process that goes on in the background.

Apart from other types of simpler maintenance tasks all these tasks compete for the CPU, and if you have too many of these background tasks running there you can actually slow down the speed at which the pages of the site are served.

And as the site has grown over time these background processes become more and more significant in terms of load that impose in server, so I had to figure a solution to avoid this problem of slowing down the web server processes.

The solution I found out was basically to, actually I thought of two kinds of solutions, one would be to move those background tasks as many as possible to a separate server machine which would probably solve this issue but at the expense of increasing the cost of hiring more server machines, and so I would try to avoid that as much as possible or at least delay it until the site is getting a greater audience and generating more revenue that could offset the cost of additional servers.

So the alternative solution that I found was to somehow slow down those processes, those background processes, when the server load is too high, and basically this second article focuses on how I implemented that.

I would just like to comment that I've been using this technique not just recently, I've been using it for many years, for as many probably as I had the site running sending out newsletters to the site used, and just so you have an idea, each blog article that is posted in the PHPClasses site there is an alert message, a short newsletter that is going out to about half a million registered users, and that is quite a lot, it takes several hours to deliver those newsletters, but despite that it is not an urgent task to be performed.

So I thought it would not be a big deal if I somehow slowed down the delivery of those newsletters during the periods of the day, or being just a few seconds or few minutes of the day on which the server load is quite high because there are too many background processes running in parallel.

So to help in this task I have developed a class system monitor, a class which I also made available in the PHPClasses site for those who would like to use it, and once I started using it, it practically solved the problem.

The only thing that I had to pay more attention to over time is as the site grows certain background tasks that are running there tend to be more significant as the site audience increases, so over time I had to tune different background process scripts to implement this approach of slowing down.

And this approach works this way, periodically those scripts, those PHP scripts running on background check, or the CPU load, the average CPU load of the system during the last minute in the machine which on Linux systems is quite easy, there is this /proc/loadavg file on the system that you can check to get the load average in the system, and it basically returns a number that you can have an idea of how many processes on average are waiting to get CPU.

So, I implemented this class that monitors this load average, and every time that the average is above a certain threshold I suspend the currently running script. And in PHP there is this sleep() function which pauses the process for as many seconds as you want, and this way the currently running script gives up the CPU for the benefit of other processes running on the machine, eventually the web server processes that are serving the pages of the site.

Ernani, are you familiar with this new technique which I call CPU throttling which is basically lowering the speed of certain processes?

Ernani Joppert: Actually I wasn't.  As I am not a Linux user I wasn't aware of how you would be monitoring the average load of the CPU, but I was assuming you probably would be performing a top process or parsing some outputs on special UNIX commands and then gathering the specific process load and ensure that the script is not causing any harm to the box that you're currently using.

But other than that I've used a sleep() function for some chat systems that I've been coding in the past and it works really nice, and actually this other technique that you've implemented shows up the potential that PHP has without threading because as it's not a threaded script you cannot work between threads to make sure that the load is causing any harms.

But having this functionality basically it does the same task as a threaded application would do.

Manuel Lemos: Well, I understand what you mean. You are talking about starting parallel threads from the same script.

Ernani Joppert: Oh, yes.

Manuel Lemos: Well, actually in PHP it is possible at least if you run on Linox or any UNIX system, you use the PCNTL extension to start parallel processes. But now that you mention it the ability to monitor processes, I have an additional problem which was related with the site indexing in certain systems which is HtDig which is a very old system that I've been using practically since the beginning of the site, and it was written C++.

Ernani Joppert: Oh, you mean HtDig which is the search process, the site index?

Manuel Lemos: Yes, the indexing, the crawler that goes page by page and indexes the content to build the search index database. And that is something that runs once a day to keep the search index updated, and it takes several hours to conclude indexing the whole site.  It's not a very efficient process but right now it is the process that is in place.

Ernani Joppert: And does it do full text searching?

Manuel Lemos: Right, it does all that but it crawls, the whole page. It's like each page is a blob, there's no notion of what type of content is in each section of the page.  But it has some features like to mark some sections of the page that you want to index and the section of the page that you do not want to index.

It's not very modern but it's efficient. It works, the only problem is that I basically have to index the whole site practically everyday, and the number of indexable pages is about 50,000.  Actually I'm not indexing the actual pages. It's served by PHP dynamically.  There is a mirror site that contains static versions of the site pages, and that's what the crawler index is.

Ernani Joppert: And what generates that mirror, is it another process?

Manuel Lemos: No, actually that mirror is the base for all mirror sites. It contains static versions of all site pages that are mirrorable, and when the crawler accesses that... it's a special domain that does the same structure, and the crawler accesses that domain and if the page does not exist there is an error handling script that handles the missing page that actually retrieves the page from the main site and stores it in a file.

So, until the file page change it remains up to date from the viewpoint of the crawler.  The problem with all this is that it was taking a long time, hours, to crawl the whole site, and since it is a process that is running on the background it adds load to the site.

And the challenge here was to throttle that separate process that is C++ program started from a PHP script.  So what I did is to perform the same throttling principle of monitoring the load of the CPU, and then if the load is too high the PHP script that started the process to call HtDig, it will run in parallel, it will be a separate process to be a child process that will be running and that process will send a signal to the HtDig to suspend its execution, so effectively it will pause the HtDig crawler.  And when the load gets back to acceptable levels it will resume the execution.

Ernani Joppert: Okay, you mean the PHP script sends some signals to the process which will then halt the process until the CPU is back to the normal stage and then resume it.

Manuel Lemos: Exactly, and it turns out it worked quite well.  PHP has the proc set of functions that has all the necessary functions to start a parallel program, in the case I use proc_open(), and also functions to send signals, in this case its proc_terminate(), as I explained in that article to send either a signal to suspend or resume the execution.

And fortunately it worked quite well, I am quite aware that over time the whole process will take too much time and I'll finally have to move it to a separate server, but until then I will not have to deal with the burden of paying an additional server just to perform this task. And this is basically a way to save money and preserve the speed of the site.

Finally, we have a third article in this series which at the time we are recording I have not published it yet but I can tell you about it, what is it about, which is basically about running certain systems calls, certain PHP functions that support asynchronous programming.

So let me first explain what I mean by asynchronous programming, for instance, if you access a file or access a remote site you would open the file or open a connection to a remote server, and this process of opening connections or files and sending and retrieving data is something that will take time.

And the idea of doing asynchronous programming is to use certain options available with the functions that open files and connections that allow to tell the PHP script to not wait until the files or connections are opened.

Instead, when the connections or files are open or the data is sent or retrieved a callback function would be called, so the calling PHP script would know when the actual task that was executed was completed, being that opening a connection or a file or sending data, receiving data, reading data from a file writing, whatever.

This is most useful for any I/O operations, it could be applied to files, network accesses, but it could be also applied to databases accesses.  Currently in PHP only files and network I/O is supported in the possibility of making those calls to the PHP functions asynchronously.

Database access in PHP are always synchronous, this means that say for instance you perform a query to a database server, if it takes three seconds the PHP script would stop and wait until the query is finished and the results are returned.

And it would be great if, for instance, let's say you have a page that you have different sections with content that is retrieved from different database query results, and it would be interesting if, for instance, you could perform those queries in parallel.

So if you start on a query you do not have to wait for that query to finish to start executing the second query and retrieve the data in parallel.  And as I mentioned, this could be used for not only database access but also accessing files or remote network servers.

And this could be used for accelerating the execution of scripts using this technique that I call asynchronous programming.  Actually I never used this in PHP. Unlike the previous two articles in which I'm talking about something that I have already experimented, in this case I have not yet tried it.

I know that PHP has support for parallel asynchronous programming for file and network I/O but not database accesses.  But this idea of exploring the possibility of using asynchronous programming came from the fact that some time ago, actually last month, I've been studying Node.js.  Ernani, are you familiar with Node.js?  

Ernani Joppert: Yes, I've been looking into it. I've never actually used it but I've seen which features you can add with it, and by adding an asynchronous call to specific processing Node.js would really extend the power of it and interface PHP web sites with Node.js and probably you could then have function calls, remote calls, and sort of a model of multi-tier applications talking with JavaScript to server running under Node.js, right?

Manuel Lemos: Right.  Well, let me give more detail for those who are not familiar with Node.js.  Node.js is basically a framework for JavaScript server side programming, and you could use it also for non-server programming, but that's what it's mostly used for.

And this framework is built on top of the Google V8 JavaScript engine. Google V8 is the same JavaScript engine that is implemented in the Google Chrome browser. It's quite fast. It supports JIT programming optimized, and it makes JavaScript run very fast.  But Node.js has this focus of making every I/O asynchronous.

And in the Lately in JavaScript Podcast that I published in the JSClasses site last month I have talked a lot about the Node.js with Michael Kimsal, Michael our co-host and also Mário Valente our guest, about this Node.js approach of implementing asynchronous programming.

And I thought it would be interesting to implement it, explore it in PHP as PHP has some support for asynchronous programming but it does not have all the support that we could perform certain I/O operations asynchronously, namely for database access.

But there is one idea that we could implement asynchronous programming without actually depending on changes on the PHP database access extensions which would rely on using Gearman.

There was an article by César Rodas written a few months ago that talks about Gearman which is basically a middleware that can manage the execution of processes in the background that PHP could send a request to execute a certain process, and using Gearman you could actually perform any database queries from there.

And since Gearman supports asynchronous calls it would be possible to implement asynchronous programming for accessing databases that way. This means that PHP would not have to wait for the tasks that were called to finish in order to continue to perform any other tasks in parallel.

Ernani Joppert: So, Manuel, one question here.  So basically if I would like to implement let's say content publication system which from time to time performs some separated tasks which goes into the database and performs some queries, and when those queries are ready it would then call another function in the remote scripts which would generate some static HTML files and make them available for the content management tool to publish those HTML's, lets say, articles.

So it would have a static publication system by performing asynchronous calls between PHP servers let's say that way.  So basically we would have some sort of first tier which would be the static web site and the second tier would be the database layer which would rely on another system and would then perform those background operations and then proceed with the logic of that, let's say, idea.

Manuel Lemos: Yeah.  And let me mention also that those background processes that could be running in parallel could also be written in PHP because PHP could be a language that can be used either as a client of Gearman workers as well as a worker itself. So, in the end it could actually implement a whole architecture in PHP relying in Gearman as middleware.

And another thing that I remembered to mention is that for instance Facebook, I don't know if you have noticed, Facebook when you open a page of your profile, or whatever, you notice that the page skeleton loads first and then you see the body of each section of the page loading in parallel.

And from what I've heard it seems that Facebook uses a similar process for generating the different parts of the page, for instance, you have the part of your wall and then on the part of the chat, your friends that are in the chat, all that is retrieved in parallel and one part may load before or after the other.

And I don't know if they use Gearman or if they don't use Gearman they would probably use a similar process of implementing tasks.

Ernani Joppert: Yeah, perhaps an internal tool, right, who knows?

Manuel Lemos:  Well, actually they have documents published about what they use, I just did not check, but after recording this podcast I will try to find those documents and publish a link in the show notes so people can understand what exactly they are using and literally get some ideas to implement on their systems.

But basically these articles that I have written so far I have been having great success, have great interest from the community of users, the sort of surges of the accesses to the site when I publish these articles, and this seems to mean that they are useful, they interest a lot of people, and I hope this also helps PHP developers to achieve a higher level of maturity when implementing the architecture of their systems.

The (non-)adoption of named function parameters and annotations in PHP (43:38)

But moving on with our podcast, now one other section, now getting close to the end of this podcast, I would like to comment about the latest PHP developments. There are many small things going on in the development of PHP. I noticed a few that could be interesting to mention just to give you an idea of what is going on, or probably what is not going on because in this case I am mentioning things that it seems that is not let's say a great interest from the PHP core developers to have them in the core.

One thing that I'm going to mention first was actually a proposal that it seems to come back and forth, I think it's not the first time that somebody proposed it but it was the first time I actually noticed that it was being discussed, which is the implementation of named parameters.

PHP, as you know, the function calls may have a variable number of parameters, but sometimes you do not remember the order of the parameters. So somebody suggested that when you do not remember you could name the parameters right in the system, the function call, the place where the call is made, and so giving names you could specify the parameters in whatever order you think is interesting, and eventually you could miss any parameters.

This idea from what I've heard it was not greatly accepted, and what I've noticed as the main argument for not accepting this idea is that somehow you can implement this with associative arrays. PHP instead of getting a list of parameters, PHP would take an array and you would pass on it whatever parameters you want.

Well, this is not exactly the same thing, but until named parameters are finally accepted, if ever, that's the way that we have to do it when implementing these calls that are optional parameters or permitted, you don't know the order.

Ernani Joppert: Yes, and one point here, Manuel, I would think about is if you are sending an associative array it's not the best thing because first of all documentation would be quite hard to discuss, and also method signatures, if you're using object oriented approach it would also be hard to explain and to test to the let's say adopters of that API if you are providing some sort of API to a third party provider how would you document it and allow the user to understand it better how to adopt it.

Manuel Lemos: It's not just that, for instance, the existing functions of PHP you simply cannot change the arguments that they have to switch them to arrays because they are expecting a certain number of parameters and what you want is not having to remember the order of the parameters which in PHP unfortunately is quite inconsistent which is a common complaint regarding PHP.

But another feature that has been proposed and was not very well accepted, actually not accepted at all, it had lots of discussions and people complaining against and for it, was to support annotations.  Annotations are a feature that came from the Java world. Ernani, you are more familiar with the Java world, can you explain briefly what are annotations for those that are from the PHP world that are not familiar with the concept?

Ernani Joppert: Yes, annotations, this is the name of meta-programming adopted by Java and suggested on the RFC's of PHP as annotations as well.  But in C# there are attributes which is a similar approach of meta-programming.

And basically adopters of this functionality would benefit most likely when developing frameworks or using those frameworks that are already existing.  So basically when you have annotations facilities on your code it's much easier to document your code and actually to perform changes because sometimes some frameworks demand external configuration or let's say an object-relational mapping tool, you probably need to configure it.

So, let's say you are somehow using let's say MySQL as a main database, but then you have all your database layer mapped to an ORM solution, let's say as Doctrine is, then I suddenly want to change this to support let's say Oracle or DB2 let's say, and basically I would have to look into your mapping XML configurations or properties let's say it that way, and I would have to change it there.

But by using annotations this process could be documented in the same code that you have and you could basically just run a specific task to parse those annotations and it would then generate automatically the mapping files for your classes, and this would benefit a lot if implemented in my opinion.

And somehow PHP doesn't have this feature right now, and somehow some users are not focusing on it right now because it was never implemented in the PHP community.  Some claim that this is not a feature that would be used, but you know how the development world is, if you can use it and you have the way to do it then you will, and by making PHP more rich in those approaches would really benefit from the developers standpoint and for the maintenance of the solution as well.

And there are a lot of other frameworks that would benefit from it which would be PHPUnit and Zend Framework let's say it that way, and some other ORM solutions, as mentioned, Doctrine, but Symphony would also benefit from it which I can recall right now.

Manuel Lemos: Yes, I think Symphony uses Doctrine, but tell me one thing, Ernani, this proposal of implementing annotations was sent by Perrick Charron there is an RFC written by Perrick Charron and also Guilherme Blanco which is a well known figure that works in Doctrine and we had in a previous podcast here talking about ORM tool, and one claim that I saw from those that are opposing implementing annotations in PHP is that PHP already has PHPDoc and we don't need another meta information standard to support.

Actually I think this came from the Zend guy, I think Zend Studio supports PHPDoc and probably it will be complicated, more complicated for them to implement yet another metadata standard to use in these classes.  Ernani, do you think that maybe PHPDoc could be somehow extended to meet the features that annotations could provide?

Ernani Joppert: Yes, what PHPDoc basically does is basically in my experience, I've never had to document any sort of a PHP project to which I've coded, but in my Java background I've done a lot of JavaDocs and JavaDoc is an external task, so what it does it reads the whole source path of your application and it generates let's say a tidy documentation based off of HTML structuring all the object model of a specific application and would then provide better documentation from the object oriented standpoint it would generate a nice documentation for adoption.

So, if the annotations would be implemented, basically what annotations do is from the development standpoint any framework developer would then have their own set of annotations, and annotations would be written in object oriented approach so they could specify parameters and attributes on each annotation, because annotations are basically Java classes in the Java standpoint, so in PHP it would probably be implemented in the same way.

So each PHP class would extend an annotation, and by extending an annotation it would have special attributes that would be required for such specific configuration or generation of configuration files, so any framework developer would then provide their own set of annotations specific to their framework. And when developing a framework based solution you would then import those annotations and specifically document your code.

What PHPDoc does, it does have some specific metaprogramming that you can insert on your code, but they are not object oriented let's say that way. So they are standard stings, and what I can understand of it, it parses those specific strings and generates documentations, but those strings are not objects so it cannot traverse to those objects to understand better of what is required by that.

So by having the annotations approach it would be more useful for the object oriented approach in mainly frameworks that are object oriented would benefit from it.  But I believe that the whole PHP would benefit from it once it's implemented.

Right now it's a very hard approach to understand for PHP developers who don't have understanding of either Java or C# because it's something that was never seen for them, so basically this is what I would consider domain issue that is causing them to avoid implementing it in the PHP.

Manuel Lemos: Well, my question was actually if do think instead of implementing the actual format of annotations as we have in Java which you described as practically defining a new class with definitions that contain the annotation information, instead of actually doing that do you think it could also be useful as an alternative solution to extend the PHPDoc format syntax somehow to let's say implement similar features that annotations would provide?

Ernani Joppert: Yes.

Manuel Lemos: It would be different than Java but at least...

Ernani Joppert: Yes, it would be very different but any basically PHPDoc would be one different task and let's say for Doctrine, if Doctrine wants to implement their mapping meta programming solution it would be Doctrine Doc, let's say it that way, so they would have then their set of parameters and traverse to the parameters and generate the mapping files for those objects. But then it wouldn't be a general feature of PHP, it would be a specific feature of each framework.

Manuel Lemos: Well, I don't know, because the PHP syntax parser actually returns information where are PHPDoc statements, whatever they call that syntax that PHPDoc has, so it's not a process that is not so integrated in the language. My idea was probably to extend that syntax that PHPDoc supports and provide space for the necessary constructs that annotations would provide.

Ernani Joppert: Oh, yes, and one point is in the Java I'm not sure, I may be talking about things that I don't know here, and I'm assuming things on the PHP side, my experience with annotations would be in Java, and in Java you have a compiler, so basically when you are coding your application you have some specific compiler warnings that the annotations provides to that so that you can use that in that specific portion.

But in PHP without the compiler feature I don't know how much that kind of benefit would be transferring to the user, but maybe on an exception handling or error messages you could then document those error messages on specific documentation meta-programming and it could go from that way.

But I don't know, I really don't know, it would be really hard to investigate and I would have to understand better how PHPDoc was implemented and how PHP benefits from it to better talk about this.

But I know that Java uses it regularly and it's really important right now, and if the PHP user wants to dig into this I would recommend going into the Java annotations to better understand the feature and to better see the benefits it could bring to PHP in that sort of matter.

And as PHP 5 took a lot of features from the object oriented world, let's say C# and Java as well, it got what is good from those languages, why wouldn't it benefit as well from annotations which is also implemented in C# and Java?

Manuel Lemos: Right.  It's a matter of perception whether it is useful or not, like you just said, some people that oppose just claim that they do not see a use in their own applications so for them they just reject it, but as you mentioned they will never miss something that they do not know or understand.

But for now the feature is sort of rejected, but I suspect that sooner or later it will come back again with maybe some of those that are rejecting it now maybe they think again and start seeing its benefits, so let's wait and see.

Ernani Joppert: Oh, yes, and my suggestion is when you are using a specific application that is willing to talk to different database systems, and if you are using PHP 5 on your projects, I would really recommend using an object relational mapping tool, and Doctrine seems to be the mainstream line right now.  And by using that and by using annotations it will really, really make the developers life easier as well as the framework, it could be a richer framework by adopting that functionality.

Manuel Lemos: Well, as I said, let's wait and see.

PHP Programming Award nominees of August 2010 (1:02:36)

Manuel Lemos: But for now we are reaching the end of our podcast, there's one last section which is the one on which we comment about the packages, the classes that were nominated in the month of August, so they were voted in September and then in October we had the results.  Ernani, what packages do you think are worth highlighting more than others?

Ernani Joppert: Yes, basically the number two and number three here, well, the one who generates chords for guitars. When I started having guitar classes I used to try to document my own music using chords, and by having this it brings me to those memories and it also brings the creative process of PHP developers which can show to many other developers around the world how PHP can be useful for those kinds of solutions.

And you can see that given some knowledge and some creative ideas you can pretty much create very useful specific solutions for your own needs.  And the other one would be the Django implementation which is Haanga by César Rodas which it seems similar to the Django engine, and it has the same approach.

Manuel Lemos: It's the same approach.

Ernani Joppert: Yeah, right.  So basically a Django developer could understand better PHP by using it as well as it could provide backward compatibility with Django projects, if someone is trying to port from a Django based project into PHP they could seamlessly do that transition, and as well as one who isn't familiar with Django and wants to benefit from the framework approach but doesn't want to give up PHP, he could also benefit from this solution, so my vote goes to that one as well.

Manuel Lemos: Yes, before somebody misunderstands what you said, this is not an implementation of Django in PHP this is just the template engine that Django has that was ported to PHP. The way you mentioned it, it would seem like a Django port which is not that template at all, it's just a template engine.

And that's right, what this template engine does is probably different than others and the reason why it was nominated is that it was implemented as a template inheritance, it's basically a language that lets you embed some marks to define sections and control structures in the template.  And one of those control structures is the ability to inherit an existing template and modify it in a way that is useful to implement a new brand of a template without the whole effort of redoing the original template.

Ernani Joppert: Right. So basically I could write let's say a home page with a custom layout and extend that layout for inner pages, or let's say if I have some specific content pages and I repeat those in some sections of my website I could extend those and have some sort of inheritance approach to development on that design on the view layer of my application, right?

Manuel Lemos: Right.

Ernani Joppert: Very nice.  What would be yours?

Manuel Lemos: Well, basically there are many classes that probably would be worth mentioning, we just don't have the time, but I'd like to comment on a couple of classes that basically do serve for similar purpose which is to compare two images and give a result of how the image may be similar or different.  And it is interesting these two classes, one named Image Compare by Denis, and the other Image comparison class by Kai Ming Choy, I hope I'm pronouncing his name correctly

And they just provide similar, an implementation for a similar purpose but one displays it visually and the other evaluates the difference between images in terms of intensity of the pixels.  These are those that I would like to mention for this month, unfortunately we do not have more time to comment on others, and I hope the authors that I have mentioned would not mind, but keep sending more innovative classes and we'll gladly highlight them in the future month.

Conclusion (1:08:39)

Manuel Lemos: So now that we practically ended our podcast once again, Ernani, I would like to thank you for your presence and your insights and I hope everybody interested in discussing these subjects further would be interested in posting comments, questions, opinions or just by posting a comment to the article of the podcast on the PHPClasses site blog.  So for me for now that's all, thank you.

Ernani Joppert: Thank you, bye, bye.