In this new post to the PHPClasses.org blog Manuel Lemos talks some about the recent introduction of PHP into Google's App Engine offerings.

During Google I/O 2013 event a Google manager said PHP runs on 75% of the Web sites. So they decided to finally support PHP as in their AppEngine hosting service. Read this article to understand why this puts an end to years of false claims that PHP was losing market, as well what it means to Web developers using PHP or other languages.

He looks at the App Engine PHP offering and looks at whether or not its a good platform to use for hosting your application. He points out some advantages and disadvantages (including no local file system access and no remote resource access). He also includes five reasons why the "web platform war is over" and why PHP has come out victorious:

• Google Knows Because They Crawl the Whole Web
• Google Does Not Influence Web Developers so much
• Wordpress is the Dominant Blog Platform (not Blogger)
• Programming Does Not Have to Be Beautiful
• PHP Detractors Have the Wrong Focus

He admits, though, that PHP may not be dominant forever - it's not perfect, but there will always be a need for something that does what it can do (and does it well).

Sameer Borate has a new post to his site that shares how he converted a RETS database to MySQL with the help of a PHP library, PHPRETS.

A recent project of mine entailed replicating a RETS database on a local MySQL database server. The client had a new real-estate mobile search app in development and wanted to have a local copy of the RETS database for search queries instead of a remote RETS server. [...] Replicating RETS data rather than using the live version is slightly complex, however. In order to replicate the RETS data into your own local database, a series of processes are needed in order to make sure the data you have is both updated and in sync with the server.

He breaks it down into three main steps with some sample code for each:

• Grabbing the complete database once
• Keeping the data in sync
• Ensuring the cron job is executed on regular intervals

In this new post Josh Adell looks at working with PHP sessions and how you can manually encode data to look as if it came from the normal session handling.

If you have ever popped open a PHP session file, or stored session data in a database, you may have noticed that this serialization looks very similar to the serialize function's output, but it is not the same. Recently, I needed to serialize data so that it looked like PHP session data (don't ask why; I highly suggest not doing this if it can be avoided.) It turns out, PHP has a function that encodes data in this format: session_encode.

Unfortunately, this method doesn't take arguments - it just outputs the encoded version of the current session data. So, he came up with his own encode/decode methods that use the PHP session, extract the serialized string and return it.

On Mike Dalisay's site there's a recent post showing how to use the Phpass tool to salt, hash and store passowrd data in your application.

I think the main reason why we have to hash passwords is to prevent passwords from being stolen or compromised. You see, even if someone steal your database, they will never read your actual or cleartext password. I know that some PHP frameworks or CMS already provide this functionality, but I believe that it is important for us to know how its implementation can be made.

His sample application stores the user data in a MySQL database and does the salting+hashing at the time of the request. It uses a hard-coded salt and a value of 8 for the hashing/stretching. Screenshots of each page in the example application are also included.

On PHPBuilder.com today there's a quick tutorial showing you how to build an RSS aggregator that can pull in RSS content and drop it into a MySQL table.

RSS stands for Really Simple Syndication. It is a Web format that allows website owners to distribute their latest and frequently updated content in a standardized way. RSS feed is actually an XML document that can be easily read by using RSS reader software or built-in functions in programming languages, such as PHP or Java. In this article, the focus will be on building a RSS aggregator in PHP.

They introduce the basics of an RSS feed - a specially formatted XML document with values for individual posts (like "title" and "link". They provide the SQL structure for the "article" and "feed" tables and the code to pull out each "feed" record, parse it and drop that into the "article" table for later consumption. They show two different methods for getting the content - one using file_get_contents and another using cURL.

On the "Learn Computer" site there's a recent post that wonders if the web development standard of the LAMP (Linux, Apache, MySQL and PHP) stack is "still strong" and will still stand up with new technologies.

This year in tech (like almost every other year) has been filled with buzzwords. Many of them this year, however, are based around big data processing and web content: NoSQL, Hadoop, BigTable - the list goes on. With all the fuss around these new technologies, one might be tempted into thinking that these are the technologies of the future, and that from now on our servers and websites will be built upon, leaving technologies like LAMP in the dust.

They talk about some of the things the LAMP stack doesn't do well like difficulties with scalability on both the web server and database side. There's also mention of the things that it does do well, like getting things up and running quickly and with a solid structure.

That being the case, the LAMP stack is still going very strong, and it's definitely still extremely viable in small and medium-sized deployments; there are no signs of it waning in that regard, and I'd expect it to be a standard deployment for many companies and organizations for quite some time to come.

PHPMaster.com has posted the second part of their "avoid the original MySQL extension" tutorial series (part one is here). In this new part, they share more about another alternative - the PDO extension.

The PDO extension supports twelve drivers, enabling it to connect to a variety of relational databases without the developer having to learn a number of different APIs. It does this by abstracting the database interaction calls behind a common interface, enabling the developer to utilize a consistent interface for different databases. This of course gives it a major advantage over both the MySQL and MySQLi extensions who are limited to only one database.

Included in the post are examples of some of the basics - connecting, executing queries, getting the results - as well as more compelx things like binding parameters and transaction support. There's also a bit about changing the default behavior of the PDO object through config options. He finishes off the article talking some about some of the issues that could come from using an abstraction layer like this and the need to still write good, compatible SQL depending on the database.

On PHPMaster.com today there's a new post, the first in a series, about avoiding the original MySQL extension in favor of what mysqli has to offer. The cover some of the basics of the extension and include code showing its use.

Experienced developers eschew the original MySQL extension because of its abandoned status in PHP. Nascent web developers, however, may be completely oblivious to its dormant past and dying future. [...] It is therefore the intention of this two-part article to raise awareness among developers who still use the MySQL extension, inform them of its problems, and to help them switch over to an alternative extension.

They start with a brief look at the "what's wrong" with the MySQL extension (including its upcoming deprecation). The article then gets into the basics of MySQLi and how to do things like make a connection and run a few queries. There's also a bit about prepared statements and the built-in ability to do "multi-queries" (complete with rollbacks).

On PHPClasses.org today they've posted the latest episode of their "Lately in PHP" podcast, Episode #32, "Zend Optimizer+ Cache in PHP 5.5 and MySQL 5.6 Performance Improvements".

MySQL 5.6 speed improvements and how it affects PHP applications was one of the main topics discussed by Manuel Lemos and Ernani Joppert on the episode 32 of the Lately in PHP podcast. They also commented on the eventual adoption of the Zend Optimizer+ as the PHP code caching extension that may be shipping with PHP 5.5 as alternative to APC, the implications of this to the PHP community.

They also talk some about the switch of OpenSuSE/Fedora Linux to MariaDB MySQL, TDD in the Zurmo PHP Open Source CRM and using HTML5 animations. You can listen to this latest episode either through the in-page player, by downloading the mp3 directly or watch the video of the recording on YouTbue.

Sherif Ramadan has a post looking at creating a better operator precedence parser in PHP. His example is a fully PHP implementation that takes equation strings and evaluates them to create the result.

Operator precedence parsers are very simple on the surface. So don't feel in the least bit intimidated, because by the time you've read through this I hope to have you walk away with a solid foundation on how to write your very own operator precedence parser. The goal is to understand how to solve the problem of operator precedence parsing, and not necessarily to write your own parser. Learning how the problem can be solved is the most important thing to take away from this article.

He starts with an introduction to the concepts behind "operator precedence" including processing order and grouping. He also mentions infix and postfix (RPN) notations for handling different formats of equations. He used the "Shunting-yard Algorithm" and how it relates to handling the different parts of the equation, one at a time, in the correct order. He rest of the post is dedicated to the details of the execution in the tool, including code examples and the tokenization of the strings passed into it.