On the Adobe Developer Connection site Richard Bates has recently posted a tutorial covering the integration of PHP and Flex as developed in Zend Studio/Flex Builder.

Tight integration between Flex and a server-side language means that your users will have an intuitive, engaging user experience with all the functionality they need. For developers, tight integration between PHP and the Flex development environments can provide big benefits by ensuring a smoother workflow for coding, debugging, and managing a project. You can make the most of such a unified environment by using Adobe Flex Builder and Zend Studio for Eclipse together.

He starts with the basics - installing everything and getting it all up and running, then making a sample "Hello World" application on both the PHP (backend) and the Flex (frontend) sides. Included in the tutorial is a look at sending XML out to the Flex application from PHP.

Abhinav Singh has posted a guide to PHP extensions - what they are and how to write a simple "hello world" one.

Assuming you have read the previous post, lets discuss on how to build our first PHP extension: every PHP extension is built out of minimum of 2 files, a configuration file (config.m4) which tells us what files to build and what external libraries are needed and source File(s) which will contain the actual functionality.

He builds up an example skeleton for an extension (the config.m4) and explains how the file will be phpized and configured. Next up is the php_sample.h header file where the needed modules are loaded and the sample.c file to define them. Last, but not least, comes the extension code itself that calls the printf function to output the "hello world" message.

In this new blog entry Marc Gear suggests a few things that you can do to help learn a new framework quickly and easily:

There are dozens of PHP frameworks around now, some attracting more attention than others. I am no expert on these frameworks and have not used a single one extensively so I wouldn't dream of recommending one over the other, nor do I want to enter the debate about what is or is not a framework (I'll work on the assumption that anything calling itself a framework is a framework). Instead I'm going to concentrate on how you can get started with a new framework as quickly as possible.

He suggests four examples that can help you get more familiar with each framework and how they're structured - a "hello world" as a first step, creating a simple calculator, making a guestbook and making a simple script to parse and paginate a remote RSS feed.

Since there was such a good response to his previous framework benchmarking post, Paul Jones has come up with a fresh batch of statistics for the latest versions of several frameworks including the Zend Framework, Solar and CakePHP.

By popular request, here is an update of my web framework benchmarks report. [...] In the interest of putting to rest any accusations of bias or favoritism, the entire project codebase is available for public review and criticism here.

Follows the same methods as before, creating "hello world" controllers in each and running the stats against them with the Apache ab tool. A baseline non-framework example is created and tests are run against different versions (including release candidates) of each framework.

I won't spoil the results - you'll just need to check out his post to see who ranked where.

Paul Jones points out a new system for the Solar framework that will help those new to using it get started - a sample application that you can grab from Subversion in the traditional "hello world" style.

In the spirit of some other framework projects, the Solar Framework for PHP 5 now offers a ready-to-use Solar system to get new users off to a quick start. It's not prepared as a tarball just yet, but it is available for checkout or export using Subversion from http://svn.solarphp.com/system/trunk.

The sample installation creates a front controller, an authentication system and a "bookmarks" application to give you an idea of how everything fits together. You can get more information on each of these parts and how they all work on the Solar manual/wiki.

The Avent Labs blog has done some basic benchmarking on some of the more popular PHP frameworks out there today. The post includes the tools they used and the full results.

In response to Wil's comment regarding the PHP framework performance comparisons I made in my previous post, I have decided to post the results I got. My decision not post them initially was due to the benchmarks not being done in complete isolation (a separate client and server machine) but the scores relative to each should still be accurate and that's what I am testing for.

He used a machine with a 1.8Ghz sempron chip (running Ubuntu) to run the tests through httperf. His method involved creating the same sort of "hello world" sort of controller to gauge the framework's performance and a baseline procedural version of the same as a guide. His full results are available as a tar file and as a zip archive.

On the Symfony blog today, Romain Dorgueil shows how to create tasks to help automate things in your application like database updates, console scripts or other "repetitive maintenance tasks".

Symfony 1.1 extends symfony 1.0 pake tasks to create a powerful and uniform command line utility for your projects, fully integrated with the symfony Command Line Interface (CLI).

This means that is has the abilities to automatically support a "help" parameter, to grab a current task list the app is using, correct handling of the input parameters, set up a good environment and make sure that the source is readable. The post shows how to create a new task for your application - their examples are a "doNothingTask" that, well, does a lot of nothing and the typical "doHelloWorldTask" that just echoes.

They show how to define the task (including a namespace for it) and how to run it, outputing the results of the execute() method ("I did nothing successfully!" in the first case and a string of passed in parameters in the second.

Focusing on PHP day in and day out is nice, but sometimes it's good to branch out a bit. Kevin Yank agrees and decided to give Python a try. He's written up this post to the SitePoint PHP blog as he explores the language from a PHP developer's perspective.

Like may SitePoint readers, I cut my teeth on PHP. I've become very comfortable with it over the years, warts and all. PHP continues to be a dependable choice, but PHP hasn't changed a whole lot lately. [...] Python has a lot in common with PHP: it's a dynamically typed, open source scripting language with excellent documentation and a thriving community around it.

He includes a few basic "Hello World" kinds of examples in Python just to introduce you to the language structure (indenting for code structure? that's crazy talk for us PHPers) and some of the handy features of the language like sequences and the language's automatic namespace support.

Padraic Brady has posted part three in his look at making a blogging application with the Zend Framework. This time get gets down and gets into the code.

It's almost obligatory when introducing a new programming topic, that the author present the simplest possible example. Usually this means getting a programming language or framework to print "Hello World" to the screen. I'm going to be no different. So much for originality...

He shows how to set up everything, down to the Apache VirtualHost directive and hosts file to get the web server and localhost working correctly. He includes the code for the boostrap file and how to create your first controller (along with its view, of course).

On the symfony blog today, there's a new article looking to dispel some misunderstanding that's come up surrounding the speed of symfony applications and what effect it can have in a real-world situation.

We regularly see framework benchmarks pop up somewhere on the net, comparing symfony to other frameworks, either in PHP or in other languages. The conclusion of some of them is "symfony takes more time than other frameworks to display a 'hello, world', which makes it unsuitable for real-world web applications".

If some benchmarks show that symfony is slower, jumping to the conclusion that symfony is not optimized is a big mistake. [...] If symfony is well implemented (or so we think), then its speed is just the sum of the individual speeds of all the features it includes. Or, to put it differently, Symfony's speed is the consequence of a series of choices that we made to decide whether a feature should or should not make it to the core.

They suggest that the speed of symfony applications does not come as a result of the main portion of the framework, but rather as a choice of the development team as to what parts they wanted to include in the core and what not to. They also point out that, while speed does matter somewhat, especially in larger applications, it shouldn't be highest on the list.