On PHPMaster.com today there's a new tutorial - the first part in a series - looking at data structures. In this first post Ignatius Teo looks at the concepts of "stacks" and "queues".

Most of us are familiar with "stacks" and "queues" in normal everyday usage. But, what do supermarket queues and vending machines have to do with data structures? Let's find out. In this article, I will introduce you to two basic abstract data types - the Stack and the Queue - which have their conceptual origins in everyday usage.

He introduces some of the common concepts behind these two ideas and includes some sample code showing how to implement them. He also mentions some of the SPL functionality that's bult into PHP to handle some of this. The SplStack and SplQueue objects take some of the hassle out of it for you.

David Sadowski has posted an overview of some of the PHP frameworks out there to help you build REST APIs. Among those mentioned are things like Frapi, Laravel and Slim.

A number of articles on websites strive to give directions which framework(s) should be chosen whereas in fact there is no "one fits all" solutions for different purposes or technologies. Therefore, herewith a compiled list of some most popular and actively developed PHP REST API frameworks worth consideration and further evaluation on your project basis.

For each tool on the list, he includes a brief summary of what they are, some of the features they provide and a link to find out more about them. It's not really so much of a comparison post but more about putting them out there and letting you figure out which is the best.

Pádraic Brady has posted a 20 point list that wants to help you prevent cross-site scripting (XSS) issues in your applications.

Summarising knowledge has as much value as writing a 200 page treatise on a topic, so here is a list of 20 brief points you should bear in mind when battling Cross-Site Scripting (XSS) in PHP. Minus my usual book length brain fart . Chances are good that ignoring or acting contrary to any one of these will lead to a potential XSS vulnerability. It's not necessarily a complete list - if you think something needs to be added, let everyone know in the comments.

His tips include things like:

• Never pass data from untrusted origins into output without either escaping or sanitising it.
• Remember that anything not explicitly defined in source code has an untrusted origin.
• Always include ENT_QUOTES, ENT_SUBSTITUTE and a valid character encoding when calling htmlspecialchars().
• Use rawurlencode() to escape strings being inserted into URLs and then HTML escape the entire URL.
• Validate all complete URLs if constructed from untrusted data.
• Remember that HTMLPurifier is the only HTML sanitiser worth using.
• Ensure that cookies which must only be transmitted over HTTPS are marked Secure.

He points out that XSS is still one of the most "popular" (and easy to exploit) attack methods out there, so keep these tips in mind when writing up your code.

Thomas Buck has put together what he calls "Tom's PHP Commandments" (nine of them) that developers should follow when developing applications with the language. Among his suggestions are things like:

• ALWAYS do the simplest thing that will work
• NEVER trust anything that comes from the user
• NEVER use include for controlling logic
• NEVER create a file of useful functions, even if it's called helpers.php

There's also been some discussion about this list over on Reddit - you can comment on it over there if you agree/disagree with some of his points.

In this latest post to his site Rob Allen talks some about application structure and the different kinds of objects he uses in his applications.

I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

• Entities are objects that represent something in my business logic.
• Mappers know how to save and load an entity from the data store.
• Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

In this new post to his site Vinícius Krolow shares some tips he thinks will help to make your PHP code more readable in the long run.

What about code readability, from my point of view is one of the most important thing in the code. Who writes code that is easy to read, writes good code. Probably reading code is where you spent most part of your time, and not only your code, probably code of your team mates, or maybe code from the open source community, so write code that is simple and is easy to understand it's really important.

His tips (seven of them) are:

• Comment before write your code (DocBlock)
• Return frequently, Return early
• Break, Continue
• Code Standard / Name conventions
• Throw Exception
• Comment often, but not write stupid comments
• Methods can be always smaller than they are

It's a little difficult to read as the English isn't the speaker's native tongue, but it gets the point across. He also recommends reading this if you'd like more information about writing better OOP code that's easier to read.

In this new post to PHPMaster.com today Alexander Cogneau takes a look at what's different in version four (v4) of the Laravel framework as it has changed from version three.

Laravel is a PHP framework which uses the MVC pattern. Of course, there are many such projects and I'm not going to compare Laravel with other frameworks in this article. Instead, I'm going to share with you what's new in the newest version of Laravel - Laravel 4.

There's a list of things that have changed (each with a summary of what they are):

• Decoupled Components
• Creating a "Normal" Project
• Routes
• Better Code through Testing
• The Container and Its Bindings
• Improved CLI
• New Database Features
• Using Stand-Alone Components

Rob Allen, in his Zend Framework 2 development, has come up with a list of suggestions about the use of modules in your applications, mainly relating to the structure of the files inside of them.

I've been working on a Zend Framework 2 module within a larger project that doesn't have that many PHP class files. Specifically, it has a controller, a mapper, an entity, a service and a form. As a result, the traditional Zend Framework 2 directory structure for the Account module looks [overly complicated]. That's a lot of directories for not many files! As a result, I decided to flatten it to [something simpler].

He includes both the "before" and "after" directory structures and continues on with two more suggestions - the removal of the top level "Account" folder inside of "src/" and, finally, removing "src/" all together with a slight modification to the autoloading. With a simpler module, though, something like this might make it easier to maintain and "follow" later down the road.

The latest issue of the Web & PHP Magazine has been released - Issue 8 - The Power of Design. Articles in this latest issue include:

• Todd Lombardo on user context
• Stefan Priebsch on data and persistence
• Patrick Allaert about data structures
• June Henriksen on the human side of programming

You can find out more about this issue (and go download your free copy) on the Web & PHP site. There's also seven previous issues, all free for download (PDF format)!

On the Smashing Magazine site today they've posted a list of powerful CLI tools that every developer should at least know about to help make their lives easier - six of them ranging from SSH tunnels to HTTP testing.

Good tools are invaluable in figuring out where problems lie, and can also help to prevent problems from occurring in the first place, or just help you to be more efficient in general. Command line tools are particularly useful because they lend themselves well to automation and scripting, where they can be combined and reused in all sorts of different ways. Here we cover six particularly powerful and versatile tools which can help make your life a little bit easier.

The tools they mention are all things you'd install on a unix-based system:

• Curl
• Ngrep (network packet searching)
• Netcat (to work with network connections)
• Sshuttle (SSH tunneling)
• Siege (HTTP benchmarking)
• Mitmproxy (capturing proxy, both HTTP and HTTPS)