Matthias Nobak has continued his series of posts covering software architecture and class structure. In a previous article he talked about using interfaces and in this latest tutorial he covers the reuse of "domain code", the main logic of your application (rather than the structure).

Last week I wrote about when to add an interface to a class. The article finishes with the claim that classes from the application's domain don't usually need an interface. The reason is that domain code isn't going to be swapped out with something else. This code is the result of careful modelling work that's done based on the business domain that you work with. And even if you'd work on, say, two financial software projects in a row, you'll find that the models you produce for each of them will be different in many subtle (if not radical) ways. Paradoxically you'll find that in practice a domain model can sometimes be reused after all. There are some great examples out there. In this article I explain different scenarios of where and how reuse could work.

He then goes on to cover three "reuse" situations, providing a summary for each:

• Reuse-in-the-small
• Reuse-in-the-large and software diversity
• Reuse-in-the-even-larger: reusing entire subdomains

He finishes up the article sharing some thoughts about which of the types seems more obtainable and, in his experience, useful.

Sebastian Bergmann has posted a guide to PHPUnit 4.7 and some of the changes/new features it introduces.

PHPUnit 4.7 introduces a couple of small improvements. For instance, PHPUnit's PHPT test runner now supports --INI-- sections, information about the PHP runtime used is now printed in verbose mode, and a warning is now printed when code coverage data is collected but no whitelist is configured.

He also talks about the support that's been added improving the output of the HTML version of the code coverage reports, showing different colors based on how well covered the lines are. He also briefly looks ahead to PHPUnit 5, the versions it will support and the plans for release.

The SitePoint PHP blog has a new tutorial posted showing you how to set up a simple small business website using the BoltCMS tool. This recent article will walk you through the full installation, configuration and setup for a simple site including database interactions.

As the web continues to mature and the demand for the efficiency of content delivery increases, more and more slim and trim CMSs are coming into the fray. Developers (front-end and back-end) are branching away from the heavy-hitters like WordPress and Drupal, and into the likes of more streamlined, tailor-made solutions. Bolt CMS is one of these CMSs, and prides itself on being a dream for designers, developers, and content editors alike.

He starts with a brief overview of what the BoltCMS has to offer and some of the technology that powers it. He then goes through each of the steps to get the application up and running:

• Requirements, setup and installation
• Main configuration and theme set up
• Splitting up files into templates
• Introducing and creating content types
• Retrieving content from database records

Each step along the way includes the code, configuration changes or template updates you'll need to make to end up with a simple site allowing you to view a page of content and list/add related testimonials.

Lee Blue has posted his next article in a series covering some of the real costs and considerations around using PHP for your applications. In this latest post he talks about frameworks and what kind of effect they could have on the overall profitability of your business.

Last week we talked about application shelf life an aspect of PHP development that often goes overlooked. This week let's talk about how the web development framework you use contributes to the shelf life of your app and the profitability of your web application. [...] The main goal of all web frameworks is to improve the developer's ability to get ordinary things done so we can focus on the primary goals of what we're building.

He talks about how PHP was "made for the web" and why there are so many different kinds of frameworks out there (though most are generally MVC-ish). He talks about one of the standard arguments, learning curve vs efficiency, and how it compares to the "no framework framework" ideals. He then gets into some of the dark side of using frameworks, specifically how they can shorten the shelf life of an application and how difficult migration can sometimes be. He points out the irony of large frameworks: the bigger the app/framework, the harder it can be to migrate (and cost more). He encourages sticking with smaller, lighter frameworks instead and suggests coding standards, common packages and using custom libraries only where needed to create your application.

On the Dutch Web Alliance blog today Stefan Koopmanschap talks about making technology choices, how flexibility comes into play and suggestions on what to do when things go wrong. He uses some of his own experience (and problems) to illustrate his points.

The amount of times I come into an organization that says any of the above is impossible to keep track of on one hand. Or even two. Most development shops for some reason have decided that they have a single tool that will fit the job. Always. I have to admit the current market is good for developers. There are many projects available, and not enough developers or agencies to work on all of them. [...] But too many times have I encountered projects where the used tool actually was not optimal for the project. I would like to make a case against starting with a full stack from the start. Obviously, this approach does not work for all projects, but too many projects start out small but with a full stack. I’m going to take an old project of mine as an example of how to start out small and not grow until you need to.

He talks about the project first, a transcoding tool that used a third-party service and generate a playlist once the process was complete. He shares some of his thinking about the technology involved (Symfony2 without the full Symfony2 stack) and the decision to go with Cilex. He also talks about database choices (PDO over Doctrine) and how starting with small pieces like this makes it easier to change things in the future (or when a roadblock looms ahead). Then comes the "what went wrong" part of the development - debugging the system without the direct access needed to view the logs. Instead he worked around it, made a simple endpoint to show the logs and output it via Twig templates.

The result of all this work, including changes and extensions, was still a very small and lean application that combined the power of the commandline with a simple but effective web interface. I am sure I could have done a similar thing with Symfony2, but the code would’ve been overkill. [...] It is important to realize that there is not always a need for full stack frameworks or huge CMS’es like Drupal. Sometimes you need to start small and just let it grow.

On the Symfony blog today Fabien Potencier talks about some small things that matter - some of the smaller updates that have been made to the Symfony 2 framework recently that have helped to make it better and more flexible.

Every new Symfony release tries to brings some small but useful improvements. Let's dive into some of them for Symfony 2.3 (in no particular order).

Things in his list include:

• A text-based output of the exception handling stack trace
• A default configuration for the Serializer component
• The ability to run the framework in a production environment in development
• An update to make debugging configuration parameters easier
• Conversion process of short controller names
• Overload generated code in the bundle bootstrapping code

Check out the post for the rest of the changes on his list and check out the RC1 of Symfony 2.3.0 to see some of them in action.

If you've been trying to get your hands on one of the cuddly little mascots for PHP (the elePHPant) but haven't managed to yet, there's some good news! Another run of the fuzzy little animals is being done (the 6th) and this time they're offering something new - pink elePHPants.

As we are now out of every of the 5 first generation of the elephpants, it is time to start a 6th. You'll find here all information to include yourself. [...] Fill in your elephpants wishes. We do not need any payement now. We will contact you directly before starting the generation for the actual payement.

Their schedule hopes to end the pre-order process on December 20th (just three days away) and to strat production on these pre-orders by January 10th. The end results would be shipped out for delivery in April 2011. If you'd like to lay claim to some of your own, go over to the order form and select the size (large/small) and the color (blue/pink) and fill in the contact info. Unfortunately, because of production restrictions, single elePHPants cannot be ordered, so consider getting together with a local user group and all chipping in for a box!

From the Straw Dogs blog there's a recent post looking at some of the PHP frameworks out there have the same kind of philosophy behind them as the Sinatra framework for Ruby - a small, light framework that's easy to use.

I’m currently looking for a good PHP framework to do a new project. I recently used Kohana 3 at on a project for a client but I needed something lighter and having used Sinatra and Padrino previously but needing it PHP based I did the next natural step - searched for PHP Sinatra clones.

There's four frameworks that made the list - all in varying states of development:

• Limonade
• Fat Free Framework
• Slim
• Fitzgerald

In this recent post to the Jeez Tech blog they take a look at some of the small, lightweight frameworks out there.

They look at five different frameworks:

• Kohana
• Rapyd
• Epicode
• ELF PHP
• BaseApp

A few other frameworks are also mentioned in the comments like the micro-framework limonade and Madeam.

Martin Streicher has written up a new article for the Linux Magazine website looking at microframeworks - one in Ruby and the other in PHP (Limonade).

Indeed, the quality of Rails, CakePHP, Django, and Catalyst notwithstanding, some developers have rebuffed the large frameworks, citing bulk and complexity, to create smaller and simpler alternatives. Dubbed micro-frameworks—think microcomputer versus mainframe—the tools shape incoming requests into something manageable and leave the rest up to you. Choose your design pattern, object-relational mapper (ORM), and rendering technology, and off you go. As you’ll see, a working Web application can be composed in less than ten lines of code in a single source file.

He covers the Ruby framework first (Sinatra) and Limonade next. The framework takes incoming requests and maps them into the developed code. It works like a basic MVC-formatted framework - the request comes in with an action and is sent to a method by the same name. You can use wildcards in the URI, regular expression matching, views, templates and it includes error handling support and configuration option support.