Asmir Mustafic has posted the third part of his series covering the deployment of Symfony API applications. In this latest part (part three) of the series, he focuses on the infrastructure piece.

This is the third post from a series of posts that will describe the whole deploy process from development to production. The first article is available here and the second here.

In the previous two articles, I've covered the steps 1-3 from the schema here below. Before being able to discuss the steps 4-5 we will need to see how to configure the instances properly to be able to deploy our application to a docker-swarm cluster with rolling updates.

He starts off by describing the pieces that will make up the infrastructure: a PostgreSQL database, Docker swarm for machine/VM management and AWS instances to run the containers on. He then starts in on the instance type and setup you'll need to get the system up and running including manager and worker nodes. The post wraps up with a list of things he sees as improvements for the future such as using a custom AMI, use of elastic load balancers and handling node failure a bit better.

In a new post to his site Paul Jones shares some of his thoughts about microframeworks, suggesting they're more "user interface" frameworks. Basically he suggests that microframeworks work best for the UI level handling and that possibly a second, more robust framework should be used for the application backend.

When we talk about “full stack” frameworks, we mean something that incorporates tools for every part of a server-side application. [...] Examples in PHP include Cake, CodeIgniter, Fuel, Kohana, Laravel, Opulence, Symfony, Yii, Zend Framework, and too many others to count.

When we talk about “micro” frameworks, we mean something that concentrates primarily on the request-handling and response-building parts of a server-side application, and leaves everything else out. [...] If the user interface is the request (as input), and the response (as output), that means micro-frameworks are not so much “micro” frameworks, as they are “user interface” frameworks.

He suggests that, if these statements are true, then microframeworks should be considered "user interface" frameworks. He makes suggestions of splitting things out into "containers" of functionality with the microframework taking care of user interactions while a second handles domain and infrastructure concerns.

In a new post to his blog Giorgio Sironi has a (more balanced) comparison of Java versus PHP that them on topics like how they handle typing and their execution models.

If you exclude C and its child C++, the most popular programming languages in the world are Java and PHP, which power most of the dynamic web. I have working experience with PHP and for academical purposes I am deepening my knowledge of Java, thus I'd like to point out similarities and key differences between these two languages. Every language has its pros and cons, so there's no absolute winner here.

He briefly covers their history, java's static versus PHP's dynamic typing, how they both handle objects, their execution plans and how easy they are to deploy when it comes to general applications.

Continuing his series looking at models in Zend Framework applications, Matthew Weier O'Phinney has posted this new tutorial focusing on model infrastructure - figuring out what your models are really for and how to write to that.

The Model is a complex subject. However, it is often boiled down to either a single model class or a full object relational mapping (ORM). [...] When you think in these terms, you start breaking your system into discrete pieces that you need to manipulate, as well as consider how each piece relates to the others. This type of exercise also helps you stop thinking of your model in terms of database tables; instead, your database becomes the container in which data is persisted from one use of your model to the next. Your model instead is an object that can do things with either incoming or stored data -- or even completely autonomously.

He notes that he is a fan of the domain model method and uses this method as he works through the different topics of building out your most useful model:

• asking "What are you modeling?"
• setting up the "gateway" into your domain model
• working with value objects/record sets

All of this along with plenty of code to illustrate his points...

Lukas Smith has written up the FAQ for the emPHPower movement and has posted about them on his blog:

Well unfortunately due to timing issues the emPHPower BoF at OSCON fell through. So it goes. In preparation for the BoF I have however taken the time to write down an FAQ. So the submission of the OSCON BoF was at least a kick in the butt for me to get this done. Please have a look and let me know if anything is unclear or unanswered.

The FAQ includes answers to lots of questions including:

• How to I get involved?
• What is the target audience?
• Will emPHPower compete with existing community efforts?
• What is the purpose of the membership fees?
• Why should companies not be allowed to sponsor emPHPower directly?
• Who decides on what emPHPower does?

On the Ibuildings blog today Mikko Koppanen talks a bit about Open Source software projects and things that can help to make them successful.

An idea can be a tool or a library that you need and think others might find useful; a new technology innovation; or something you think you could implement better than the existing tools. Extra care has to be taken if you decide to create a new tool to replace an old one. In most cases, these projects end up reinventing the wheel without any added value. A wheel is wheel, right?

He recommends a team infrastructure growth as the application grows and the importance of documentation and maintenance after the project has been launched.

As mentioned in This new post by Federico Cargnelutti on the PHP::Impact blog today, the BBC website is about to get a pretty radical make over - a move from Perl and static files out to a fully dynamic site made with PHP and Java.

Like most organizations the BBC has its own technical ecosystem, the BBC's is pretty much restricted to Perl and static files. The good news is that they are planning to build a new infrastructure for bbc.co.uk and roll out a new Identity platform on it. This was announced on May during the XTech 2008 presentation that took place in Dublin, where BBC's plans to reinvigorate its technical platform were revealed.

The BBC wanted to upgrade their aging platform to something a bit newer and more flexible and wanted to be able to use things like the Zend Framework for the presentation layer and a MySQL backend to power the site.