In the initial entry in this series, we took care of the UI-aspect of our Twitter-clone, called Ribbit. Now, we'll begin coding the application in a number of languages. This lesson will leverage standard PHP (with homegrown MVC), but, in future articles, we'll review other implementations, such as with Rails or Laravel.

They provide all the code you'll need, the database table structure to power it (MySQL) and the examples of a model, router and basic MVC stack to handle the requests. They help you make a user creation and login system as well as a few other pages ("buddies", "make a post" and a few others). You can also download the source from their Github account if you want it all in one shot.

Sencha Touch models have the ability to work with a proxy. This feature allows you to save and retrieve model data from the server, memory or local storage, without depending on a Sencha Touch data store. Let's try it with a very simple scenario where the server side is a PHP page.

The article includes both the Javascript to create the models (along with its proxy and custom API methods defined) as well as the PHP that powers the backend. The PHP just reads from the "php://input" stream and echoes back out JSON, but it gives you an idea of what to expect to receive. For more information on Sencha Touch, check out their documentation.

Think about how you can change and manipulate the generated HTML using server-side PHP code. phpQuery is the ultimate solution that will come to your mind. If you haven't heard about phpQuery, you may be interested in this article since I am going to give you a brief introduction to phpQuery and explain how you can use it in real-world projects.

The tutorial shows you how to generate a simple table with alternating row colors (zebra) and column headers from an array of product information. They also talk a bit about why using something server-side like this is important (over something client-side like jQuery) - how it can make things easier by keeping the "business logic" all in one place, leaving your frontend to do what it does best.

This two-part article will guide you through the process of building an efficient PHP-based REST web service to be consumed by an Android-based application. Some of the concepts presented here are also applicable to other mobile platforms, such as iOS. I assume you already know the basics of PHP and Android development and that you have a suitable development environments set up for both. I'll focus mainly on showing you how to handle data serialization and compression in both environments.

In this first part, he starts from the client side, creating the code (Java) that's needed to create the connection to the backend. He stets it up as a background task so its execution won't block the main app from working. He shows how to execute it, running an "on create" method and checking to ensure the network is available for the request.

I have looked at the state of different messaging backends recently and i ran a little benchmark to see what is the rough comparison of message publishing throughput. Results that i got are quite surprising. What i wanted to achieve is some sort of reassurance before choosing a messaging bus for my PHP project.

Running both the PHP and the messaging test scripts on the same server, he pulled from a few different backend systems - RabbitMQ, MySQL, MongoDb, Memcached and ActiveMQ. The results were interesting, showing an interesting result in the time it took to execute versus the number of messages per second pushed in.

We were faced with an increasing number of data sources, including the coming addition of Elastic Search to the data storage system, and maintenance was becoming a problem. Thus, the decision was made to move our data layer to our REST API exclusively, removing all direct access to data storage from the web interface. This is the second such project I've been on where an external API has been used for the retrieval of all data in an application. It's a novel concept, but one that takes some getting used to to be sure.

He talks about some of the advantages of this approach including the ability to be more flexible with the actual technology used to create the API, the ability to write other applications on top of it and a glimpse into some of the process that's been going on as a part of the project.

In this tutorial, I will show you how to create an attractive, pleasant to look form for your website and then I will explain you how to dynamically validate them using Javascript. We'll also cover server-side validation with PHP to make everything 100% safe. This tutorial will help you to add more functionality to your forms which leads to better user experience and better quality of your website.

His sample form (name, password, email and gender) is made from some pretty simple HTML markup. The real trick comes with the jQuery validation on each field handled in an onKeyUp. Included are both a "password strength" method and an email validation method to check the format of the address. Errored fields have their background color changed to indicate that they've failed and some basic validation (length, password match, etc.) are also included. The PHP does much of the same validation once the form is posted and returns any error messages that might have come up.

You can download the code or try out a live demo to see the scripts together in action.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage. [...] How much would you expect it to be? [...] Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that's 13.97 MB - eightteen times more than we estimated.

He goes into the details of PHP's memory management and breaks it down into the different totals (for 64 bit and 32 bit OSes) and details on each - zvalue_value, zvalue, cycles collector, Zend MM allocator and the buckets used to isolate one array (hash table/dictionary) from another.

What does this tell us? PHP ain't C. That's all this should tell us. You can't expect that a super dynamic language like PHP has the same highly efficient memory usage that C has. You just can't.

I'm pretty new to server-side programming, and actually started out with Python/mod-wsgi. From the ground up, mod-wsgi made a lot of sense. The server gets a request, you route the request. It feels like that's where I should start, so that's pretty much what I'm trying to create with PHP (a REST router - for learning purposes, I know frameworks exist). I'm trying to think of a situation where I wouldn't use a REST interface, but I can't seem to think of one (even for simple cases). Would it be safe to say that using REST is a pretty safe bet, most of the time?

There's some good discussion and answers to his question touching on things like Service Oriented Architectures, some implications of having a web service power an entire application (or applications) and a few comments with some personal experience.

A comment about SOA sums it up well:

You learn to write for your platform in the way developers/partners will have to, so you produce a good quality usable API which encourages development and consumption of your platform.

Unfortunately even such a system [using MySQL and InnoDB tables] has limits and unfortunately replication is no good solution here to scale further as we will always need a master for writing the updated session data. By using replication we can take some load from it and we can configure a slave which can be promoted to master to keep session alive if the primary master machine fails but at some point in time we need another solution ... but, happy news, again: One doesn't have to look far as MySQL cluster will be happy to help. MySQL Cluster "is a high-availability, high-redundancy version of MySQL adapted for the distributed computing environment," as the MySQL documentation states.

He describes the setup (after pointing to this post about installing MySQL Cluster for memcache) and includes some sample code/SQL/ini settings you'll need to use to get PHP's memcached functionality to cooperate with it.