PHP Classes

PHP 5.7 Release not approved - Lately in PHP podcast episode 55

Recommend this page to a friend!
  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog PHP 5.7 Release not a...   Post a comment Post a comment   See comments See comments (0)   Trackbacks (0)  

Author:

Viewers: 40

Last month viewers: 1

Categories: Lately in PHP Podcast, PHP opinions

The proposal to have an eventual PHP 5.7 release before PHP 7 is not going to happen because PHP core developers voted against it. That was one of the main topics discussed by Manuel Lemos and Arturs Sosins in the episode 55 of the Lately in PHP podcast.

They also talked about what PHP developers have been looking for in 2014 by analyzing the latest PHP Zeitgeist edition, the possibility to get a DOS attack against PHP applications that use json_decode function, as well several of the latest proposals for PHP 7 features.

Now listen to the podcast, or watch the hangout video, or read the transcript to learn about the details of these interesting PHP topics.




Loaded Article

Contents

Introduction (0:20)

PHP 5.4.36 and 5.5.20, PHP 5.6.4 released (1:36)

PHP Zeitgeist 2014 (3:43)

PHP 5.7 Release not approved (17:30)

Comparison Chain proposal (22:06)

RFC: Null safe calls (24:29)

Package private classes  proposal (29:43)

Case sensitive symbols proposal for PHP 7 (34:23)

JSON Hash PHP DOS Attack (38:31)

JavaScript Innovation Award Winners of October 2014 (48:29)

JavaScript Innovation Award Rankings of 2014 (52:44)

PHP Innovation Award Winners of October 2014 (55:54)

PHP Innovation Award Rankings of 2014 (1:01:31)

Conclusion (1:07:04)


Contents

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

Watch the podcast video, subscribe to the podcast YouTube channel

Read the podcast transcript


Click on the Play button to listen now.


Download Size: 54MB Listeners: 3644

Introduction music Harbour used with explicit permission from the author Danilo Ercole, from Curitiba, Brazil

View Podcast in iTunes

In iTunes, use the Subscribe to Podcast... item of the Advanced menu, and then enter the URL above to subscribe to this podcast.

Watch the podcast video

Note that the timestamps below in the transcript may not match the same positions in the video because they were based on the audio timestamps and the audio was compacted to truncate silence periods.

See the Lately in PHP podcast play list on YouTube and Subscribe to this channel there.

Show notes

Introduction (0:20)

Manuel Lemos: Hello. Welcome to the Lately in PHP podcast. This is episode 55, and we are here recording still from the cold. At least me, from the cold, because I have here, as always, Arturs Sosins from Latvia and cold is something... Every day he gets cold where he is, at least in the winter, right?

Hello, Arturs.

Arturs Sosins: Hello. Yeah, cold is something that I've known, but I can't imagine you being in a scarf in the house, yup, right?

Manuel Lemos: Yes, exactly. For me, this is cold because nowadays I'm more like a Brazilian, because I'm not used with so much cold. I haven't been living here, and exactly tomorrow, I'm going to return to Brazil and I was warned that there is hell out there in terms of heat. The weather is very hot, so it will be a total inversion of weather.

PHP 5.4.36 and 5.5.20, PHP 5.6.4 released (1:36)

Manuel Lemos: OK, we are here to talk about PHP. We have many interesting topics to talk about, and we are going to start exactly from the latest PHP releases. OK, let's share the screen here.

As usual, we have releases for the three last versions that are being maintained for PHP 5.4.36, which is mainly fixes about security, exactly, because this is a release that is being maintained just for security updates.

Now, for PHP 5.5 and 5.6, that was 5.5.20 and then 5.6.4, these are releases that are being maintained. They have some security bugs also fixed, but they also had other fixes for bugs that were not security-related.

Well, I do not see anything really worth mentioning because these releases are just maintenance releases, no new feature seem to be added. Let me just double check here about it. They're just bug fixes, and well, there are some feature requests here, but they don't look like they are very very important, at least the way I see it.

So I guess, anything else you would like to comment, Arturs? Maybe we could move on to the next topic.

Arturs Sosins: Yeah, probably, nothing much to comment.

PHP Zeitgeist 2014 (3:43)

Manuel Lemos: Well, the next topic, we are going to start talking about one regular initiative that is organized by the PHPClasses site, but is interesting for the whole PHP community because it talks about the trends of the PHP community in the last year, what PHP developers have been looking for.

This is the PHP Zeitgeist initiative, which consists of gathering statistics about the keywords that are being searched on the PHP Classes site. Obviously, the PHP Classes site is visited only by a fraction of the PHP community. It's not exactly all the PHP developers go there. Many developers go there. It's still a sample of the whole PHP community, but it is interesting just to analyze what are the trends in terms of what PHP developers had been searching for the past year.

So, this initiative works, first gathering the statistics of the top searched keywords that were entered in the PHP Classes search page. Then, it builds a ranking and it takes out the keywords that were not ranked in the top 1,000 in the past year. From those keywords, we just gather the first 100.

OK, so as we may see in the PHP Zeitgeist page, where you can see all the rankings for the last 15 years, starting from the year 2000, we can see the ranking here with all the top Zeitgeist keywords. These are not the top searched keywords. These are just the new keywords that were not added in the past year. And you can see 100 of them. These are very diversified keywords.

In this article, I have gathered these keywords by topics, and I could found pattern like 8 topics that I could group these keywords. The first one was basically APIs and Web services, which seems to be something very interesting for many PHP developers especially those that are developing mobile applications that require APIs.

On the other hand, there are also interests to call other site Web services using their APIs. Then, you can see lots of keywords related with those APIs. So this is probably the most important topic because it had many related keywords.

And then, there comes the topic about databases. Databases access seem to have been also very continue to have a great interest, especially those related with mysqli and PDO because MySQL extension is being deprecated and discontinued. So, in the future of PHP versions, developers will not have access to the old MySQL extension, so they need to update their code to move on to mysqli and PDO.

Security also continues to be very a important topic. This is great because sometimes there are developers of other languages that complain that PHP is not being... The PHP community is not very concerned with security which is totally wrong.

There are some developers that are not so much security aware, but the PHP community as a whole is very interested and concerned with security matters. As you can see by many of the keywords entered... that become relevant, more relevant in 2014.

Then, there are other topics with less interest, but still are of interests like file manipulation and format conversion, which is always a topic of great interest especially to manipulate documents generated by Microsoft Office and others.

Then, the topic about new frameworks is also interesting. In particular, I noticed a great interest on frameworks about JavaScript, like Angular, because it seems that those frameworks are being used more and more by mobile application developers. That is very interesting.

Arturs Sosins: Well, it is interesting because AngularJS is like a JavaScript framework, so why would people actually look for it PHP Classes?

Manuel Lemos: I think because they are looking with some special integration because AngularJS would only do the browser-side end, and maybe they are looking for something that can help them, and it's not just one keyword. You can see here 'angular', and then 'angularjs'.

Arturs Sosins: It probably meant the same, but interesting that AngularJS is actually used to create a single-page Web apps. So... looking for additional framework to allow them to retrieve...

Manuel Lemos: Yeah, that's true. I don't know if it would make... Since I have not been using it for the application development, I don't know if they will also use them for developing those types of mobile applications.

What is your experience? Could the AngularJS be useful in that context or maybe some other libraries would be more appropriate?

Arturs Sosins: I haven't worked with AngularJS specifically. I did with Backbone.js, which seems to be doing similar stuff but in a different approach. Yeah, basically, what they would require is an API that allows you to fetch data from a databasebase or any other storage, basically for AJAX requests... integration there.

Manuel Lemos: Right. Well, one way or the other, you need to do the server-side integration because the live application layer is between the client-side and to the server-side. I don't know if developers are looking for something specific to take advantage with Angular because it's all AJAX. Maybe it's not just Angular.

Anyway, this is just a reminder for the fact that other JavaScript frameworks you mentioned , Backbone, could be jQuery or some other, do not appear here because they did not become relevant this year. They're already relevant in past years.

The PHP Zeitgeist only denotes interests that became relevant in the past year. In the previous years, they may be not being as relevant or were not relevant at all. Because I remember that AngularJS is not exactly new. Maybe it's just trending this year more than the previous years.

Ok, well continuing, there is also the topic related with e-Commerce and business matters, with a just few new interesting topics.

Then, there are two final topics that I like because they were not trending in the past year. One is related with hardware. We can see some keywords like raspberry, ibex... I think it is related with USB, if I'm not mistaken... and then, php printer. Well, these are all different types of hardware.

Other types of hardware-related keywords also featured in previous years but this seem to become more trending more this year than in previous years.

Yeah. Maybe because all these interest drones and other autonomous devices, robots and everything. Now, developers are more interested about this. Maybe they want to run PHP on Raspberry Pi devices. I don't know, maybe that's why they are being searched here.

Then, finally, there is one topic that is related with PHP installers in general and mainly Composer. Well, Composer is not exactly new but at least in PHP Classes site, it became more visible because in 2013 Composer, PHPClasses had the support to install packages. So PHPClasses acts as a Composer repository.

Then, later in 2014, there was support being added to Composer to import packages from private repositories with some automation to enter any passwords. This made the Composer even more useful.

So this is all to mention that the PHP installers, in general, are topic of great interest for PHP developers, and this just confirms there is this trend among PHP developers that more and more interest about this.

Other than that, I don't know, Arturs, if you have any other comment you like to make.

Arturs Sosins: No, just that actually, it seems quite distinct and interesting groups, I would say that maybe hardware group misses keyword 'Arduino'. But I don't know if it's even possible to integrate something with PHP through the Web service or something like that.

Manuel Lemos: Yeah, well, I'm not sure. I didn't look, but maybe Arduino was already a trending topic in the previous years. Let's take a look, Arduino. Yeah, exactly, last year, Arduino was a trending topic, so it makes sense. It's not that Arduino is not a trending topic in 2014, it's just it's not a new trending topic. That's what the PHP Zeitgeist initiative tends to highlight.

OK, about this, the only thing that I would like to mention is that the PHP Zeitgeist initiative is always useful to help developers that are looking for ideas to implement innovative components because they can look at these trending keywords which reflect the fact that there are many users looking for them. And if there is no package for some of these purposes, they can get ideas for innovative packages. So, that's basically it.

PHP 5.7 Release not approved (17:30)

Manuel Lemos: So given this, we are going to move on to the next topic, which is something that has been having great discussion in December, but already in January, the discussion continues, which is related with the proposal to have PHP 5.7 released before PHP 7.

There was a proposal for this before, but now there was a final proposal for this new release was issued in December. There was a great discussion, and there was already a vote to have this PHP 5.7 released with some improvements that probably would still be consolidated with PHP 7.

But the proposal was practically rejected by now. So this means that unless something somewhat unexpected happens, there will be no PHP 5.7, despite there was this proposal.

Actually, we talked about this proposal for this intermediate version like a few months ago... I think it was September or something... but since it was rejected, there will be not a PHP 5.7 release, which means that the next major release will be with PHP 7. So, all the proposals that targeted between 5.7 will only make it to PHP in PHP 7.

There had been lots of discussions about why this happened. I'm not sure if we got it right, but I think they were somehow concerned with PHP 7 being delayed further because then, they do have more intermediate versions to maintain, and more work for the developers working on those features.

So the features that will now move on to PHP 7 only will give developers less work to maintain them. I guess that's the reason why they rejected this proposal. And it's OK, just to update whoever is concerned about these versions and was not aware that PHP 5.7 will not happen after all.

OK, I don't know, Arturs if you have anything else to comment.

Arturs Sosins: It's just that if I would be a PHP core developer, I would probably just skip also many versions as possible then the new version, and not make maintaining any versions anymore because we already have PHP 5.5, 5.4, for security reasons, to maintain that.

Manuel Lemos: I think it make sense to jump right to PHP 7, although that is a major release, probably with much more backwards incompatible changes. I don't know, well, let's wait and see if that will be a better solution or probably for users it would be more problems, because major releases, users tend to not jump on that bandwagon at least right away. Often, they wait some time to see how much backwards incompatible changes will break their code.

So, OK, let's wait and see. I think the schedule for PHP 7 still maintains its being targeted, if I'm not mistaken, to October 2015. There's still plenty of time to implement plenty of remaining work that needs to be done.

Comparison Chain proposal (22:06)

Manuel Lemos: OK, so let's move on to the next topic, which is about some new proposals. Some are formalized, others are not. Let's start first with this one about comparison chain. So, this was not really a formal proposal, or at least I did not find an RFC for this.

The idea is to allow to have expressions like this that allow to have conditions in if statements or others that have conditions that can, for instance, evaluate if a variable is within a certain range which in practice would translate to two comparisons. But it would look more elegant, I think, in my point of view, that you can just tell PHP to evaluate if these two conditions are true.

It's also saying it would also be possible to have multiple variables being compared in a single expression. But I don't know, this did not have much discussion. There is no RFC so far that I have noticed. But maybe I've missed something.

Arturs, what do you think about this proposal?

Arturs Sosins: I don't know. I think just sugar syntax and my processor right here can better process boolean expressions and operations like and/or, either than working on that in the internals. So I don't usually allow it, yet it may be just me.

Manuel Lemos: Yeah, it wouldn't allow you to do anything that you could not do before. It's just syntactic sugar, and you'll look at it probably more like you look at those expressions in your mathclasses.

Arturs Sosins: Exactly. Well, maybe.

Manuel Lemos: Yeah.

Arturs Sosins: One thing to remember every time that I would have to use it for conversion or something like that.

RFC: Null safe calls (24:29)

Manuel Lemos: Yeah. OK, now moving on another proposal. This one is about Nullsafe calls. Because if for some reason, you have a chain of calls in a fluent... some class that you have provides a fluent interface that you call a function, and it performs some action, and it returns the object itself so you can pass that object to the next function call that is chained.

The idea here is to allow null to be passed as object, so they have this ?-> operator, that you could use with your expressions. I'm trying to look at it. It would look more or less like this, and I'm not so sure... Here is a better example.

You put a question mark here, it would allow the object to be null. And if the object is null, nothing would happen, it will just return a null because that's what the object is. And this would avoid the case of having the language throw an exception for calling a function on the null object.

Well, I don't know if this already being voted. No, I thought it's so, but well, this is the proposal. I'm not sure. Probably I cannot give a personal opinion on this because I don't... It's not my style of programming, of using chained method calls. This is a trend that started a few years ago. I don't know if for those that apply it, it would be useful.

Arturs, what do you think about this proposal?

Arturs Sosins: I can't remember what was the language. Once I use the language... as an object, so basically to save format because any method could be called upon in that operation. It was an interesting approach to make it so that really make some things easy.

At least, basically, it would be something the same, only the object is fluid, following the method call, so there is that. But, for example, with JavaScript, I think the language, especially with jQuery... and I think how jQuery looks at the approach, but it looks at the DOM element and it doesn't exist. It does not return any result. It returns a jQuery object, which is empty which then it can dictate further.

Manuel Lemos: Yeah.

Arturs Sosins: So that was another approach. But like you, I probably did not have a need for something like that on PHP. If many folks need it, then yeah, that this return the interest. What I would want to point is actually, the first time that I see something like that, that define it, then they are referencing... That was something...

OK, either way, basically that would be really hard to implement something like that, and I don't know if it would pass or not.

One mention here with this. All right, I remember, right, something about it being quite difficult to implement because it would not result to a... or something like that, and it would be weird.

Manuel Lemos: Yeah.

Arturs Sosins: We'll see if that would bring more advantage than it is there.

Manuel Lemos: Yeah, well, there is always complications when trying to implement things like this. Well, I do not see this as a really important feature. It just seems to be yet another of those features that will pile up, but probably only a few developers will benefit from it.

Arturs Sosins: Yeah, it's an interesting point. In Prior Art, it says, "Hack has already implemented a proposal identical to this one." So it...

Manuel Lemos: Oh, I see.

Arturs Sosins: Hack. That's what I found that is interesting. It's a first instance of referencing to a Hack feature in RFC, so it was that I see.

Manuel Lemos: Yeah. So they're basically playing catch up on features. Yeah. As I mentioned before, the Facebook Hack language is the greatest competitor of PHP, which is still almost PHP, but OK.

Package private classes  proposal (29:43)

Manuel Lemos: OK, now moving on to another feature being proposed by Guilherme Blanco. Well, he proposes a thing that I think is somewhat inspired in Java language and other languages, which is to have a package-level for determining the access protection to functions and variables.

The idea here is to... let me share the screen here... so we can look more at the message. The idea is to have classes inside a certain namespace, that they would not be visible to other classes or calling code outside that namespace. This makes sense because sometimes you only want to have utility classes that are just for the purposes of those packages that are declared inside a certain namespace.

I think this makes sense. It probably would help organizing better your code. But I have seen several people complaining that implementing this in PHP would bring a lot of complication, difficulties to maintain. Well, I don't know. Anyway, I only see a pull request. I did not see an RFC, unless this is an old proposal.

It says here that an "RFC will be created together with voting once I'm able to gather some considerations." But there is already a pull request to implement this, so I think the RFC should appear now. This way, I'm afraid, this proposal would not go far.

Arturs, what do you think? Did you get the same idea?

Arturs Sosins: I don't know, I don't really see maybe much use or... If you have a library that you try to wrap in a class, but maybe it has some other functionality that you use it to pull request, or you use a structure as a class, and then, you might want to keep it private for some reason. The most notable with the scope but here you have a namespace, so you would use it, limiting it there so others won't be able to use it. I think that you need it maybe, basically, the video in your library, then...

You mentioned that something like this comes from Java, for example. Yes, in Java, there is logic for private classes and public classes, but I think it comes due to the limitation of Java's namespace, because the package name's always related to a file structure. So the local file is named, then the public class should be named the same, and all the other classes in the file should be private. They can't be exposed, the file structure and namespace recommendation. So there is a specific case why this is there, not because it's nice to have.

Manuel Lemos: Yes, I think so. Well, having those access protection levels private and public and what is the equivalent of friend classes or something.

It doesn't matter. What matters is that if you use this in PHP, it will help preventing the inadvertent uses, accesses to classes and objects, variables that were not intended to be exposed outside this certain scope.

The idea is to have a certain improvement package level scope that is defined by a namespace. But I really don't see many, many cases on this to be really essential to have. So given the sort of lack of acceptance of this proposal for now, probably it will not go any far. That's my opinion for now.

Case sensitive symbols proposal for PHP 7 (34:23)

Manuel Lemos: OK, moving on to the next topic, let me share the screen here. There is this proposal to have case-sensitive symbols in PHP 7. This is yet one of those proposals that aim to make PHP more like other languages on which variables and functions are... I mean their names are case sensitive, and if you use different case, you refer to different variable.

I'm not really sure if this is useful. It will break the compatibility of the code that runs in PHP. So far, I know that many people are able to put function case-sensitive word they would like. They will have code that will break in the future if they implement this future.

So, I don't think this will go very far. What do you think Arturs?

Arturs Sosins: If we are talking about PHP 7, that would not be the only feature that would break compatibility. But from my point of view, I don't know, maybe it's some kind of OCD or something like that, but I think I'm keeping all my function and class names in the same case, and I just can't use them in different cases. I don't know, it breaks me inside.

So even if this feature would pass, I probably would not have any problem with it, so I don't mind it. I'm mostly sure that most of my code would work either way.

Manuel Lemos: Sorry, I muted myself. I was asking do you think that in your code, do you always use the same case convention and it would not break any parts of your code if this case-sensitive proposal would pass?

Arturs Sosins: Yeah. I'm basically sure about it because, I don't know, I just... Even though, it's somebody else's code, I just can't stand when I see that they defined function in one way and use it in the other case. I don't understand why.

Manuel Lemos: What about the code that calls the core PHP functions? Because at certain points, the documentation used to show certain case conventions and then others, people looking at it would use the same conventions in the documentation but when it change, they'll also change.

Or they would prefer some under convention of their own and not probably have mixed case conventions in their own code that would work. But with this proposal, it would not work anymore. Would you still have coded that like that?

Arturs Sosins: I think all the PHP internal functions are used only in lower case, as that one thing, lower case and underscore between words.

Manuel Lemos: Well, I mean not in your code, but the code that calls the core PHP functions. You always use the same case conventions? Or did you always have used the same case conventions over time?

Arturs Sosins: Yeah, I think I've always used the, as I've said, lower case-underscore... and it's mostly in the PHP documentation is now.

Manuel Lemos: Yeah, well. I think this proposal will not pass, so probably it is not even an interesting discussion.

JSON Hash PHP DOS Attack (38:31)

Manuel Lemos: We are going to move on to one final topic among this regular topics, just the things that happened in PHP community, which is related with an article that is not exactly new.

Let's see if it's... I think it is, which is November. OK, let me share the screen here instead of just talking. Well, this is about PHP Denial of Service Attack implemented at the level of JSON data structures. JSON is now being used by many, many Web services, to take requests. In this article here, it mentions that if you have a JSON object...

Arturs Sosins: Well, I think JSON is used as an example, but this vulnerability will probably work on anything that use hashtable, so if it uses hashtable would also probably work on it. What it actually does, it provides the worst case of the hashing that it has, that's why it consumes lots of CPU cycles to work on it, and basically hangs, freezes, your computer server.

Manuel Lemos: Yes, I was looking here because I was trying to see what is a more clearer example of the problem. Basically, in the past, there was already this problem regarding the request parameters.

An attack that could craft a security based on special keys for an associative array that would make it collide in the implementation of the hashtables that store those keys. There was some measures implemented in, I think, PHP 5.3.9 or just about that version number, and that would allow to limit the number of keys that an array could have.

However, this time, despite the problem that key collision is the same, because it pertains to the way that hashtables are stored for PHP, this would attack json_decode function. In json_decode, I don't know if it would make sense to limit this to 1,000 entries of the array. So I think this can be a problem that could sort of, if not out your server, at least make it very, very slow.

Looking at the discussions of these topic, let me see the exact message. I think it was Pierre Joye that mentioned this issue has been reported on the security@php.net, at least which is being discussed and analyzed. But this is private mailing list that is only accessed for a few members of the PHP Core Team. They are still analyzing and discussing an eventual solution for this problem.

Personally, I don't know if there can be a solution that probably will get in the way, at least with certain API's work because they can take in a very large number of array elements and this could cause the eventual collision of parameters that could make your server work very slow.

I think this is the problem that they're trying to figure a solution. Maybe if they implement... maybe an option the parameter that limits the number of entries that a JSON encoded object could take. It would solve for now, but the application developers would have to set that parameter accordingly to their needs or else they could experience some odd errors. I don't know.

Arturs Sosins: It would not solve the root of the problem, and something again other would... that uses the same hashtables. So it's really hard to come up with anything because it doesn't matter what hashing algorithm you are using.

So I don't know what it is you can find special keys to make the collision. Either it would utilize some kind of salt request, random salt, having backend performance, but actually would not have the predefined keys to attact and would have to randomly try to find them, which would be kind of impossible. And the author would be... a mother algorithm....

Manuel Lemos: Yeah. Well, the way I see it, what they could do is to have a parameter that applications could configure, maybe even configure at runtime. So when you call json_decode function, if it finds an object that has a very high number of elements, it would just fail json_decode.

Then, your application would have to handle the failure of json_decode like returning false or whatever is a more appropriate value. Then, your application would treat it as if some Web service call just sent some invalid parameters.

It's better than having json_decode to being well, take your server down like make it very slow and suck the whole CPU. That's the way I see, it would be better than having what we have now.

Basically, we all say that practically all PHP servers are vulnerable to this eventual attack, if they take json_decode parameters supplied from user data, from requests, from eventual Web service calls. I don't know if what you mentioned was contemplating this possibility.

Arturs Sosins: Basically, it would also kind of JSON API in PHP. I don't know it's very hard maybe to reuse because, basically, json_decode probably would not actually provide any error and you would have to post... with status code. Either way, you need to, but that would probably again another classification for the having newer status code to compare with everything or something like that.

Manuel Lemos: Well, the way I see it, this can be serious to many PHP-based Web services. Probably not just PHP, other language may also be vulnerable. If you have an API, there are many heavy-duty Web services out there that request JSON format if you do not treat this with a certain protection level, it may just bring your server down. At least if not, at least make it very slow.

I don't know. Right now, that's what seems to happen. I don't know if that parameter in PHP determines the time limit of the execution of a script would stop json_decode to stay there forever.

I'm not even sure if the problem just at the level of json_decode or the hashtable implementation that would access the elements. Probably it's both, I don't know, and this needs to be analyzed by security experts that are more experienced than I am. I'm just giving my opinion here. So anyway, we have discussed this extensively.

JavaScript Innovation Award Winners of October 2014 (48:29)

Manuel Lemos: Let's move on to another section of this podcast now. One regular section on which we talk about the Innovation Award winners and nominees.

So for the JavaScript Innovation Award, we are going to talk about the nominees of October. They were voted on November. Then in December, the results came out. So we can talk about them.

Arturs, which ones would you like to comment?

Arturs Sosins: Let me share the screen. The first one I would like to comment is a package named jQuery Dialog AJAX Content developed by Andi P. Trix from Romania. What this package does, it retrieve the contents to display the dialog from a server.

Basically, a dynamic queries retrieves it via Ajax request. This could be used also like loading the template or dialog from other remote source or something. That's why I like this one. Andi got one book of choice by Packt for this package.

The second one I wanted to comment is a package named JavaScript Holiday Dates by Pierre FAUQUE from France. Basically, this package extends the Date object, the JavaScript Date object, where it provides, as an example, where it basically calculates the holiday dates...

Let me see the code here. You can see getEaster, getPaques, and now, with once, getHolidays. Basically, there are some holiday names where you can provide them how to calculate them.

Manuel Lemos: Yeah, because those are holidays. They always happen, but there is some kind of formula to calculate them because they are related.

Arturs Sosins: Like first Sunday for that month and something like that.

Manuel Lemos: Yeah. So there is a way to calculate them, but not exactly a fixed day in the year.

So that one was from Pierre FAUQUE. On my behalf, I would like to comment on an interesting package. Let me share the screen here. An interesting package from Pierre-Henry Soria... he developed a way to retrieve data from GitHub profiles and repositories. So it sends HTTP requests to GitHub API to retrieve some of the captured information.

This is interesting because GitHub is a very popular project. Many developers host their projects there, and with this package, you can retrieve information about those projects.

Arturs Sosins: Or a developer can implement in their web sites or display all the repositories they maintain and stuff like that.

Manuel Lemos: Yeah, exactly. So on my behalf, that's all for now because there are only three packages.

JavaScript Innovation Award Rankings of 2014 (52:44)

Manuel Lemos: So let me comment now on the Innovation Award ranking for 2014. We have already ended the year, but there are still some votes to compute.

But so far, the leader is Thomas Bjork from Sweden, followed by David Castillo... sorry Thomas had 4 packages and 15 points, David Castillo with 2 packages and 13 points, Pierre FAUQUE 3 packages and 12 points, Jimmy Bo 4 packages and 11 points, Andoitz Jordan Marmolejo with 2 packages and 10 points, then several other authors with 1 or 2 packages and less points.

In terms of countries, so far, France continues to lead. It is in pretty good shape to win the Innovation Award of the year by country. They have 5 packages and 21 points. Then, they're followed by Sweden, 4 packages and 15 points, but perfectly all by Thomas Bjork. And then, Mexico, with 2 packages and 13 points, Spain 3 packages and 12 points, Canada 4 packages and 11 points, Italy 2 packages and 8 points, Hungary 2 packages and 7 points, India with 2 packages and 6 points, then Colombia with 1 package and 5 points, and Brazil, 1 package and also 5 points. They are tied.

We still have one month to go. I mean, for computing the results because the nominees of December announced just a few days ago, and they'll be voted during January. Then, in February, the results will come out, and then, we will have finally the final list of winners by author and by country for 2014.

Arturs Sosins: But what to do thereafter? Will there be the similar countries this year?

Manuel Lemos: What do you mean?

Arturs Sosins: Well, should they start submitting for the new year - the countries?

Manuel Lemos: Sorry, I did not listen.

Arturs Sosins: Like will there be the Award winners by country of 2015?

Manuel Lemos: Yes, of course. Actually, it has already started because all packages will be nominated by the end of the month. So, if they are published already in January, they'll be nominated, of course.

PHP Innovation Award Winners of October 2014 (55:54)

Manuel Lemos: So, now, let's talk about the Innovation Award of the PHP site, PHPClasses site. The page is up here, but it's a bit slow.

So we are going to talk about the winners of October who were nominated in November, then in December, the results come out. We have there 11 nominees. It's quite a lot. It's great to see all this action.

Arturs, which one would you like to comment?

Arturs Sosins: The first one that I would like to comment on is a package named PHP Check Resource Usage by Pooya Sabramooz from Iran. There is a ...

Manuel Lemos: Can we increase the zoom level?

Arturs Sosins: More? Like that?

Manuel Lemos: Yeah, that's fine.

Arturs Sosins: Okay. Basically what it does, it queries this usage of the server where PHP runs like CPU, hard disk. There is also a demo, for example. Here, you can see what kind of information is provided. It probably uses some kind of native components because you can't do that with that. I think that is fine in PHP.

Do you know more about it, Manuel? No?

Manuel Lemos: Yup, sorry?

Arturs Sosins: Do you know more about how it actually does it? Because it can't be done with only PHP, right? You can query some server load or something like that.

Manuel Lemos: Well, I think it may be using some external programs. Well, in Linux, I think there are some virtual files that you can query and obtain those CPU values.

Arturs Sosins: I see. Yeah, that makes sense.

Manuel Lemos: Yeah, you don't need an external program because you can open those resources as files.

Arturs Sosins: And Pooya received a PhpStorm IDE for this package.

The second one I wanted to mention is PHP Webcam Fetch by Maik Greubel from Germany. What this package does, it fetches the images from remote webcam. It is quite uncommon for PHP but it also makes sense that it's a remote webcam to fetch from other server, probably.

Here's an example how you can use it. Probably, basically, it's a webcam that has an image, and which is then queried and delivered to the website, to the server. But still, it seems kind of interesting.

Mike got one downloadable e-book of choice by O'Reilly.

Manuel Lemos: Well, for my part, I also wanted to mention several packages. Let me share the screen here.

The first one I'd like to mention, this PHP Word Frequency Analysis by Alejandro Mitrou from Argentina. This package is very interesting. There are several other packages to extract frequent terms from packages, but this one is interesting because it could extract frequent terms... not individual words, but could be multiple words. It is interesting although there are similar packages but with other limitations.

For now, Alejandro did not yet picked his prize, but there is a delay. There's so many winners that the previous winners, positions are still picking the prizes. So I hope they can be patient, but their turn will come.

Another package I would like to comment is an unusual one called PHP Historic Timeline Generator. It can render images with a timeline of historic dates.

This is better shown with screenshots, as you may see here. It's quite neat. You have a timeline of different dates, and then it renders labels on diagonal. It's very interesting. You can build a nice timelines if you want to generate timelines for showing in articles or things like that.

This one was developed by Ihor Khomyn from Ukraine. Congratulations for his contribution.

PHP Innovation Award Rankings of 2014 (1:01:31)

Manuel Lemos: Now, let's talk about the rankings of the Innovation Award of 2014.

By author, Chi Hoang is leading. He's in pretty good shape to win the Innovation Award of the year because he has 8 packages and 42 points, and he still continues to send innovative package every month.

Second place is Orazio Principe from Italy with 3 packages and 24 points, Pooya Sabramooz from Iran with 2 packages and 22 points, Patrick JL Laso with 2 packages and 20 points, Jacob Fogg from United States with 2 packages and 19 points, wapmorgan from Russia 2 packages and 16 points, Andoitz Jordan Marmolejo with 2 packages and 16 points, Everton da Rosa with 2 packages and 14 points, Er. Rochak Chauhan 2 packages and 14 points, and Abius X, finally in 10th place, from Iran with 1 package and 12 points.

This is leading to a very interesting ranking by country because the lead country which is in pretty good shape to win the Innovation Award because there is only one remaining month to be accounted, and Italy is leading with 9 packages and 66 points.

But Iran comes right after Italy with 7 packages and 65 points. I think looking at the nominees of December, which is the last month to be accounted, there is only one nominee from Italy, none from Iran. So practically, Italy, have already won by country.

Although the results will only be officially announced next month, I think by country's pretty much decided that Italy will win. Still, Iran has made a great effort. Many authors participated to achieve this result, and they almost got ahead, but did not make it. Still, it's great because they sent many great innovative packages. Then, in third place...

Arturs Sosins: One thing that I... you can finish with the third place, it's about what I wanted to say.

Manuel Lemos: Yeah. Sorry?

Arturs Sosins: Basically, you see that France is in third, but if you look in the author table, then Chi Hoang basically rocks the top for this year. It was not enough to bring France to first place, so it's really a team competition. You need more members.

Manuel Lemos: Exactly. Precisely. That's a very good point that you bring in because the idea is the authors collaborate and encourage each other, so the more authors participate, the greater are the chances to win the Innovation Award.

I think Chi Hoang is in pretty good shape to win by author individually, but he sent 8 of the 11 packages that France got to be in this position. So as you said, it was not enough. Well, maybe next year, French developers, as well as other countries, can have get also good position.

Then, Spain comes at 4th with 47 points. Brazil with 8 packages is 42 points; United States 6 packages and 42 points, India with 5 packages and 31 points, Russian Federation with 4 packages and 30 points, Romania 2 packages and 17 points; Germany, finally, 4 packages and 17 points.

Well, this has been a very exciting competition this year. I hope next year, we will get even more interesting packages. Maybe authors can communicate, organize themselves and give them ideas to each other, also take advantage of the package recommendation system because sometimes there are some requests for packages that do not exist. They can take ideas for innovative packages.

From what I could gather, well, in December, it was sort of a weak month, because it's practical holidays, and there are not so many packages being submitted. But, right now, in January, there is a boost of new packages. Many of them are innovative, and it seems that 2015 will be very promising. Well, let's wait and see.

Conclusion (1:07:04)

Manuel Lemos: So basically, regarding this podcast, this is it. We have covered many interesting topics about the future, the security and also the past trends. Basically, that's all. I don't know if you have any other comment you'd like to make.

Arturs Sosins: The only one comment, happy New Year guys and wish all your projects to succeed this year.

Manuel Lemos: That's a great wish and I would like to also wish the same for everybody. So on my behalf, that is all for now. Bye.

Arturs Sosins: Bye.




You need to be a registered user or login to post a comment

1,614,280 PHP developers registered to the PHP Classes site.
Be One of Us!

Login Immediately with your account on:



Comments:

No comments were submitted yet.



  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog PHP 5.7 Release not a...   Post a comment Post a comment   See comments See comments (0)   Trackbacks (0)