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

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.

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.

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.

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.

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.

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).

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.

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.

As PHP 5.5 is getting ready to be released in the next months, the end of line for PHP 5.3 is being planned, while the original MySQL extension is being deprecated in PHP 5.5 to be killed in a later version.

You can listen to this latest episode either through the in-page player, by downloading the mp3 or you can watch the video of the recorded Google Hangout of the taping.