PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

In the first part of this series we talked about the development challenges we face and how Openbiz Cubi can help by providing a solid, ready-to-use web application framework. In this part we'll see how to build our own module and dive a bit deeper into the core architecture of the framework.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

On PHPMaster.com today they've posted the first part of a series spotlighting Openbiz Cubi, a PHP "framework" with a business focus.

Openbiz Cubi is a robust PHP application framework giving developers the ability to create business applications with minimal effort. In this two-part series I'll explain the concepts and steps necessary to create your own business web applications with Cubi. We'll look first at the challenges web developers face and how Openbiz Cubi can help, and then how to install Cubi. In part 2 we'll see how to create our own modules.

They start off by describing the tool and some of the features that come with it (including user management and the XML data object structure). Complete installation instructions are included and a screenshot is included of the end result. They include a "quick tour" of Cubi's features and some of the modules that come with it like the System, Menu and User modules. In part two of the series, they'll show you how to create a custom module.

Lukasz Kujawa has a new post to his site introducing you to deployment of your web-based PHP applications using the Phing build tool.

How many steps are required to deploy your software? Some people say it shouldn't be more than one. I'm little bit more relaxed about it so I would say two steps are still fine. If it takes more than two then most likely you need a build script. [...] Phing is a PHP project build system or build tool based on ​Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make. It use simple XML build files and extensible PHP "task" classes.

He shows how to get it installed via Composer and how to create a simple "build.xml" file with a few targets inside. He shows how to use the "build.properties" configuration file and how to set them from the command line if needed. He also includes details on doing database migrations using the "dbdeploy" tasks.

On his Systems Architect site Lukasz Kujawa has posted an introduction to Apache Zookeeper and how to use it in your PHP applications. Zookeeper is "a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services."

Apache ZooKeeper is the coolest technology I recently came across. I found it when I was doing a research about Solr Cloud features. [...] Running multiple application as one logical program is nothing new. In fact creating such a software was one of my first jobs many years ago. This type of architecture is confusing and very tricky to work with. Apache ZooKeeper tries to provide a generic set of tools to manage such a software.

He shows you how to get the PHP extension for Zookepper (along with needed libraries) compiled and installed in your server setup. He includes a sample class that shows you how to connect to the Zookepper server and add a "watcher" your PHP script will respond to when changes happen. The post also has a "Watcher" class example, showing how to use Zookeeper as part of a distributed application. There's some links at the bottom of the post that can also help you get more details on Zookeeper and the PHP interface.

On the iBuildings blog today there's a post from Boy Baukema about the use of the OWASP ASVS to help provide a framework of questions to ask about your application to help find any application security "pain points."

When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands. [...] And maybe some thoughts have been given to performance metrics, but security? Well… it "needs to be secure". [...] It is said, conveniently enough mostly by software engineers, that building software is perhaps the most complex activity humans have ever undertaken.

He notes that "security is not a checkbox, it's a dropdown" and should be continuously considered continuously through out development. The OWASP ASVS provides a structure that a development group can follow to test the security of their application. It defines 4 types of testing/validation and fourteen other topics to consider.

While ASVS is a wonderful addition, it has it's issues: verification and reporting can take a significant amount of time and validation rules are not specific enough to use the tools and techniques.

In his most recent post Lukas Smith suggests that good design isn't an excuse for wasting time. He's basically saying that Symfony2, because of how it's designed and implemented, isn't a RAD (rapid application development) framework and that it's about time for some layers to be added to help get it there.

Symfony 1.x I would put into a category of frameworks focused on RAD, aka rapid application development. [...] So for those people who were happy focusing on the 80% use case Symfony2 is a step back. Suddenly the same features take longer to implement, take longer to modify later on and on top of that the learning curve is steeper.

He suggests that work be put into "RAD layers" that can sit on top of Symfony2 and provide some of the more familiar features people are used to from things like CakePHP, Yii and CodeIgniter. There's been a few tries to accomplish this with only one getting the closest in his opinion - the KnpBundle.

On the Inviqa techPortal today there's a new post talking about the New Relic monitoring service and what it has to offer PHP developers and their applications to help them manage things like performance and resources.

The performance of a web application plays a critical role in how an application is perceived by its users. It is important to measure it, identify the causes if it changes and react swiftly to any unexpected changes. This article describes an industry leading tool, New Relic, and how it can be used to monitor and improve your site performance. [...] New Relic is a real-time application monitoring service, providing various metrics about the performance of your production site, covering everything from application database queries through to the time it takes for the end-user to view a page.

They walk you through a "getting started" with the tool and how to get it running on your server - for PHP this means installing an "agent" extension and a local daemon for it to feed information back to. They then get into some of the data New Relic provides including application performance details, browser information, throughput and an Apdex score.

Lorna Mitchell has a new post today showing you how to install XHGui to help with profiling your application for performance and processing issues.

If you're not familiar with XHGui it's a fabulously easy and friendly way to profile your application; to understand which method calls in a page take the time and how many times they are made, so you can improve the performance of your application. All these instructions are for my 32-bit Ubuntu 12.10 system, hopefully they will work for you or you'll be able to adapt them as appropriate.

She lists the dependencies you'll need to have installed before you can get XHGui working correctly including a MongoDB instance and the PECL xhprof extension. With those all set to go, you can go grab the latest XHGui from github and drop it into place.

Gonzalo Ayuso has posted a second part of his look at scaling Silex (here's part one). In this new article he shows how to use the RouteCollection functionality instead of defining the routes in the DI configuration.

In the post Scaling Silex applications I wanted to organize a one Silex application. In one comment Igor Wiedler recommended us to use RouteCollections instead of define the routes with a Symfony's Dependency Injection Container. Because of that I started to hack a little bit about it and here I show you my outcomes:

He includes example code for creating the application, setting up the main "routes.yml" file with some defaults and two other files for routes in other parts of the site - "api" and "blog". Then he makes the controllers related to these three sections with basic actions catching each of the routes. The source for the entire thing is over on github.

On PHPMaster.com today they've published a new article from Remi Woler about preventing "code rot" in your applications through the use of unit testing. He advocates that tests, when applied correctly, can help make refactoring easier and safer, allowing you to change your code and know things stlll work.

Unless you're working on a fresh project right now, the codebase you work with most likely has such code you take for granted. And the more challenging your current assignment (or fresh project) is, the more likely it will become a legacy part as well on short notice. Since it's infeasible to fully comprehend all problems that your codebases solve, as well as all their solutions, something else needs to be done to prevent code rot. One way or the other: the code needs to be refactorable to live happily ever after.

The breaks down the steps that a unit test should follow on its most base level - assemble the environment to test inside, act on the code and assert that the output was as expected. He walks you through each of these steps, detailing what's involved and including some sample code to illustrate. He also includes a few tips on the successful application of tests like:

• Don't forget to write integration/acceptance tests as well.
• Name your unit tests verbosely.
• Write unit tests for bug fixes.
• Never change the code under test.