Now that Google App Engine opens to the PHP world and that the 4th version of the Laravel framework is officialy launched, we wanted to test these two promising technologies together at Neoxia. This blog post is the result of our tests whose goal was to have a standard Laravel 4 application on the Google App Engine PHP runtime up and running Given that an application without a database is not very useful, we also tested the Google Cloud SQL service which is the Google flavour of the MySQL database in the cloud.

He works through some of the steps for his first attempt at getting it set up, but notes that the seemingly working setup wasn't actually cooperating like it should. Thanks to some log analysis (and debugging) he found a few issues - missing functions, the lack of the mcrypt extension and session/cache/logging problems. He shows how to correct each of these and then moves on to connecting the app to a Google Cloud SQL database.

Zend Framework 2's ModuleManager has the ability to cache the merged configuration information for your application. This is very useful as it allows you to separate out your configuration within the config/autoload directory into logical files without worrying about the performance implications of lots of files.

There's some ZF2 configuration options that tell it to cache this data once it's loaded the first time, but he notes one issue with this - caching in development. It can be annoying when you make a change and nothing happens because it's cached. To prevent this he shows you how to only cache if the application is marked as in production (based on the "APPLICATION_ENV"). Separate main configuration files are made for each environment, one that caches and one (for dev) that doesn't.

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.

With the recent release of Laravel 4, PHP developers have at their disposal one of the finest frameworks for application development. As with all new frameworks, it is always good to write some quick code to get a feel for the underlying architecture. The following post shows a simple authentication application using Laravel.

He walks you through the creation of the simple "users" table, the configuration the Auth class will need to connect and authenticate and the form for the login. He also shows the steps for the actual authentication process as well as the code for the routes to make it all work. Additionally, he shows how to restrict pages to only those with the "admin" level access via an auth filter. You can download the example code here.

Welcome to another tutorial. Today, I will be giving you a walk through of zftool, which provides basic tooling support in Zend Framework 2. If you're new to Zend Framework, or have been reading the introductory series here, it can come in quite handy. But unlike other frameworks, such as Yii (through yiic) and Symfony (via the Command Line tool), the tooling support in Zend Framework 2 is rather light on. These respective tools provide rather robust support for automatically generating models from database connections, checking logs and a host of other much required functionality.

He shows you how to do a few things with the ZFTool - create a new project, make some modules inside it, build an autoloader classmap and check the installation with some basic diagnostics. Command examples and configuration samples are included in the post to help you along.

Design patterns are built to standardize solutions for common problems faced in software development. [...] Facade is a design pattern used in almost every web application, but often without knowing. The term "design pattern" creates a mental image of something complex and difficult to understand. Even though this can be true sometimes, the Facade pattern is simple to implementation. Let's see what Facade is and what it does to help us write good code.

A simple example is given to help make the concept of a facade clearer - the process behind borrowing a book. As borrowing and returning a book could involve multiple library types, they use a facade to provide a common interface to all of them. With the concrete example in place, they then move on to the official definition of the pattern and two more "real world" examples: authentication against multiple social networks and working with WordPress meta functions.

The previous post was about how to use AngularJS resources with Silex. AngularJS is great and when I need to switch back to jQuery it looks like I go back 10 years in web development, but business is business and I need to live with jQuery too. Because of that this post is about how to use the Silex RestFull resources from the previous post, now with jQuery.

He includes the sample code showing the jQuery version of the application based on a "Resource" object. He also includes some samples of its use for the usual CRUD operations. You can get the full code from github.

There are many ways we can interact with other applications from PHP and share data; there's web services, message queuing systems, sockets, temporary files, exec(), etc. Well, today I'd like to show you one approach in particular, proc_open(). The function spawns a new command but with open file pointers which can be used to send and receive data to achieve interprocess communication (IPC).

He starts off explaining one of the fundamental concepts behind working with processes - pipes, both anonymous and named. He then moves on to the use of proc_open and the three attributes it takes - command, pipes and references for output. He includes a more practical example showing it in use - a script that converts text with wiki markup into HTML output (via this tool).

PHPUnit has hinted at parallelism since 2007, but, in the meantime, our tests continue to run slowly. Time is money, right? ParaTest is a tool that sits on top of PHPUnit and allows you to run tests in parallel without the use of extensions. This is an ideal candidate for functional (i.e Selenium) tests and other long-running processes.

ParaTest operates as a separate binary that can easily be installed via Composer. They walk you through the install and show you what kind of options it lets you provide (like number of processes and the path to the PHPUnit executable). They show you how to write some parallel tests, five of them, each that sleeps for a certain amount of time. They also look at another tool that could help run your tests in parallel, Paraunit. They finish off the post with a look at some functional testing examples using Selenium, handling race conditions and some of the future plans for ParaTest's future.

By default, Laravel is configured to create daily log files for your application, and are stored in app/storage/logs. All Laravel logging features are handled by the wonderful MonoLog library. Monolog includes various log handlers you can use - FirePHP, ChromePHP, CouchDB, Stream and many more. One of my favorites is FirePHP while debugging PHP apps.

Getting Monolog to write out to FirePHP is pretty easy and he includes the sample code to make it happen - basically pushing a "FirePHPHandler" into the Monolog instance and using it from there.