In a post on his Medium site Joey Masip Romeu shares some suggestions about how you can organize your business logic in a Symfony application with some simple namespacing and service definitions.

I want to talk about namespacing services in Symfony, specifically Symfony3.

These are exciting times, Symfony 4 is just round the corner?— -coming out on November 30th? - ?so this blog post might be irrelevant soon! Nevertheless, concepts are still the same so let´s get into it!

He offers three "rules" that he and his team at SlowCode have defined to help with their own organization:

• using a folder for logic services
• using a folder for the domain name
• using . for folder separation and _ for word separation

Code and configuration examples are provided for each suggestion helping to illustrate the point. He ends the post mentioning public and private services and how they're changing in upcoming Symfony releases.

On the Laravel News site there's a new post sharing some improvements with "unique" and "exists" validation that will be a part of the framework starting in version 5.3.18.

Validating requests in Laravel is simple with its ValidatesRequests trait that is automatically included through the BaseController.

It’s powerful and provides a lot of useful rules for common use cases. Two rules, exists() and unique(), are used to validate against data stored in your database. [...] The style of this is not the easiest to remember and it’s something you almost always have to consult the docs on.

Starting with Laravel v5.3.18 both of these rules have been simplified with an introduction of a new Rule class.

They include some code examples of using this new Rule class and how to use it right along side the current validation rule format for more complex validation needs. There's also a mention of an extra "bonus" that comes with the functionality: a conversion method for translating new rules back into strings.

If you've considered submitting to a Call for Papers to speak at a technical conference but aren't sure exactly what the process is like, Stefan Koopmanschap has shared some of his experience in a new post to his site.

Having been a conference organizer as well as a speaker, I've seen both sides of the CFP process. Because of that, I've made some decisions as a speaker on how I handle CFPs. Since I've discussed this with several people in the past year but it keeps coming up, I've decided to document one of my decisions here.

He talks about a "first world problem" of not knowing if you're accepted to one conference before applying to the CfP for another at the same time. He also looks at the usual Call for Papers process from the perspective of an organizer and how to sift through the (usually) hundreds of submissions that come in. He also shares his own personal rule for submitting to a conference: only submit if you're absolutely sure you can attend.

In a new post to his site Phil Sturgeon talks about the "success story" around the PSR-2 PHP-FIG standard and his work to get the PHP CodeSniffer checks to be more correct for it.

I've had static analysis tools running in Sublime Text for a long time, but for most of that time I have had CodeSniffer and it's PSR-2 rules disabled. I couldn't for the life of me remember why I had done that, until I turned it back on again. All of a sudden it started complaining about code that I had always considered to be perfectly compliant. It reminded me of multiple conversations I've had with others in the FIG and the community in general, about how CodeSniffer often enforces rules in the PSR-2 spec that do not exist, or were not what was meant when it was written. Two months ago I set off on a mission, to get CodeSniffer in line with what PSR-2 really is.

He gets into a bit of the backstory around the checks and the addition of "Errata" to add to the specs that have already been defined. The goal isn't to alter what's been defined, but to help clarify some issues (or close some loopholes) that might have come up. After polling the PHP-FIG mailing list about it - and it passing unanimously - the Errata was added and the CodeSniffer rules were updated to match (PHP_CodeSniffer 1.4.7).

If you're interested in other unclear places in the PSR-2 spec and want to discuss it, check out this gist and the conversation that goes with it.

Hasin Hayder has a quick post to his blog today about how you can configure an AppFog instance to be able to run Zend Framework-based projects on them.

AppFog is quite a popular polyglot PaaS (Platform as a Service) provider and it comes with a generous free plan for the developers. [...] Recently, I was looking for a solution on how to host a Zend Framework based application in AppFog. The main problem was that the url must point to the /public folder inside the app and from there it is initialized. After searching for some time, I found the clue in AppFog's doumentation which is you'll have to redirect all the traffic from the parent domain to the /public/index.php file using the URL rewrite rules.

The rewrite rules are included in the post for easy cut-and-pasting. With the recently announced closing of their phpFog service (in favor of just supporting AppFog) I'm sure this tip could come in handy for a lot of developers out there.

Joshua Thijssen has a new post to his blog looking at a method for setting up ACL rules in fixtures for your Symfony2-based applications.

Doctrine’s DataFixtures are a great way to add test data to your application. It’s fairly easy to get this going: Create a fixureLoader that extends DoctrineCommonDataFixturesAbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2′s ACL layer. Since there isn’t a common way to do this, here is one way on how I implemented this.

His method uses the ContainerAware interface on the fixture loader instance to be able to get at the container for the fixture. This allows you to use the usual ACL handling methods of the framework to provide restrictions based on things like usernames and roles.

The PHP.net site as new post with some supplemental information for those users of the PHP CGI that might be effected by the recently announced bug, the reason for the most recent release. Unfortunately, this patch only fixes some of the cases of the problem, so they've amended their instructions to included a more effective mod_rewrite rule to help protect your applications.

PHP 5.3.12/5.4.2 do not fix all variations of the CGI issues described in CVE-2012-1823. It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues. Again, people using mod_php or php-fpm are not affected.

The rewrite rule is there in the post, ready for copy and pasting into your config. Even if you're running the latest PHP 5.3.12 and 5.4.2., be sure to use this rule as a stop-gap measure for now. Another release is planned for tomorrow to fully correct the CGI flaw.

The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the new versions) related to the CGI handling in certain server configurations.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

Anthony Ferrara has a new post to his blog today looking at something that's constantly a focus of user-facing applications, PHP ones or otherwise - application optimization. He specifically discusses handling it in PHP and some things to keep an eye out for.

When it comes to optimization, there are two competing viewpoints in the PHP community. Some say that optimization should only ever be an after thought and to avoid premature optimization at all costs. Others will say that this is impractical, and you should make your application fast as you write it, since then you won't have to go back and clean it up to make it faster. While I can understand the viewpoints of both sides, I am firmly in the former category.

He talks about the "90/10 Rule" of development (most of the work is done by only a small part of the code) and what that critical 10% could be made of. He also touches on the "60/40 Rule", "instinctual optimization" and the emphasis people put on benchmarks for their tool or framework of choice.

On the QaFoo blog today Manuel Pichler has written up a guide to help you write a custom rule to use with the PHP Mess Detector (PHPMD) as extended from some of the current rules (it's always easier to start from examples).

Let us start with some architecture basics behind PHPMD. All rules in PHPMD must at least implement the PHP_PMD_Rule interface. You can also extend the abstract rule base class PHP_PMD_AbstractRule which already provides an implementation of all required infrastructure methods and application logic, so that the only task which is left to you is the implementation of the concrete validation code of your rule.

He walks you through some sample code and talks about some of the common interfaces that are available to your testing. He takes one of them, IFunctionAware, and looks at it specifically, showing how to use it to detect and add violations for the validation. He includes an example of writing a rule based on an existing software metric (in this case, the number of public methods). There's also bit at the end showing how to write a rule based on the "abstract syntax tree" to be able to check just about anything in the code you're looking to test.