Zend and Symfony are the two frameworks that are often compared. Which one is more functional? Which one is more preferable in terms of productivity? Which one is better for general understanding? Which of these two has a larger community? I've asked Zfort Group experts to help me with these questions, and here's what we have come to.

She first gives a high-level overview of each framework, pointing out a few of the features and tools they have built-in. She then goes on to answer the questions above, noting that she sees Symfony as coming out in the lead. Some of the questions are a little vague, so it's not entirely clear why one is different than the other. What do you think? Leave a comment here with your opinions.

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.

Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

He highlights some of the points that come along with this effort including less refactoring for the sake of refactoring, fixing more bugs/edge cases and writing more tests/documentation. He gets into some of the specifics of this kind of thinking and points out the things that can and can't be changed during this time. He talks more about stability and suggests that not only can it help enhance performance but it could also help motivate more projects/corporate users to start using the framework.

Today I'd like to play with ZeroMQ. ZeroMQ is a great tool to work with sockets. I will show you the problem that I want to solve: One web application needs to execute background processes but I need to execute those processes in order. Two users cannot execute one process at the same time. OK, if we face to this problem we can use Gearman. I've written various posts about Gearman (here and here for example). But today I want to play with ZeroMQ.

He uses React and some ZeroMQ bindings and Symfony's Process component to make a simple client and server for working with the queue and processes. A screencast is included in the post showing them making the connection and adding the new process. The full code can be found on github (or installable via Composer)

CLI applications are extremely useful for many, if not most web projects. The Symfony framework even goes so far as to include an extensible CLI console used for everything from running cache cleanup/warmup tasks, to user account management. Many CLI scripts for web projects consist of just a static .php file which works fine but grow unweildy over time. Thankfully, the aforementioned Symfony Console component is released as a decoupled standalone that can be installed and setup easily and provide us with structure and organization (and some powerful features).

He walks you through the installation of the component via Composer and includes the code to make a simple CLI script using it. He shows how to make new commands (like his "TestCommand") and how to attach it to the application. He talks about output and input handling with arguments and options. He also shows an integration with an existing application with a base command class that helps to set up and configure the command objects that inherit it.

The first commit to the Symfony documentation was over 3 years ago, and since then, we've grown to include a full book, lots of cookbook entries, and sections for most of the individual components. [...] But as we grow, we want to stay aggressive and continue to improve the quality of the docs. This means ensuring that code examples are accurate and pages are easy to understand, balancing the info you need with excess technical clutter. [...] And this is where we need your help! Whether you're a seasoned-Symfony veteran, a beginner, or even if you don't think your English is very good, we'd like you to join us on March 30th for our first ever Symfony Docs Hack Day.

The event is a virtual one - everyone will meet up on the Freenode IRC network in the #symfony-docs channel on March 30th from 9am through 5pm Central EU time. Everyone's invited, not just those who are experts in the framework. Documentation updates are a great way to learn more about a framework too! If you're interested in what kind of updates they're looking for, check out this list of open issues with the docs on Github.

Symfony is one of the most popular open source PHP frameworks on the market. The Symfony Components, however, are loosely coupled projects that can be reused as a library outside of an application based on Symfony. The component this article explores is Console (symfony/console on Packagist and GitHub), dedicated to quickly build console applications.

He goes on to talk about some of the "pros" of using the component (including built-in argument/input handing and multiple "commands") and some of the "cons" of is use (including its size and some of the built-in features you can't really work around).

I'm so happy to announce to all of you Symfony folks, the super exciting Symfony Live year that is waiting for you! This time I promise, this is going to be "Great News" for all of you!

Events mentioned for this year (so far) are:

• The Symfony track at this year's SunshinePHP conference (happening next week!)
• The US edition of Symfony Live in Portland
• Three other Symfony Live events to happen in Eurpoe

The largest announcement, though, is the SymfonyCon Europe that will be new this year, an all Symfony conference to be held somewhere in Europe later in 2013.

In application development, we try to create independent modules so that we can reuse code in future projects. But, it's difficult to create completely independent modules which provide useful functionality; their dependencies can cause maintenance nightmares unless they are managed properly. This is where Dependency Injection comes in handy, as it gives us the ability to inject the dependencies our code needs to function properly without hard coding them into the modules.

They start with a look at the problem with working with "concerete dependencies", ones that are hard-coded into your classes making them not only hard to test but potentially difficult to maintain. They include an example of this (a "SocialFeeds" class and friends) and then one of two ways to fix the situation. They start with using constructor-based injection, injecting the Twitter service into the main feeds object. They also talk about another method - setter-based injection - where the objects are injected via specific methods on the object.

As a third alternative, though, they get to using Pimple to manage the objects, making it easier to inject just the one resource into your classes and extract the objects you need from there. There's also a bit of "advanced" usage of Pimple showing the use of the "share" and "extend" methods.

Previously, on decoupling and dependencies, I said: "Some [Symfony] commenters were dissatsifed with my use of unit testing requirements to discover what a package really depends on, as opposed to what its composer.json file states." I'm willing to allow that the Symfony commenters here might be right. Let's try looking at Symfony's claims and see how they stack up.

Based on a list of components Symfony says don't have mandatory dependencies, he finds that - out of the fifteen given - four of them do have dependencies.

Does having mandatory dependencies make it a bad project? Not at all. It just means their statement of "no mandatory dependencies" (and related statements) is not true for all the components listed. Now, it may be that the Symfony folk have a different idea of what "decoupled" and "standalone" mean.