On Reddit.com there's a post sharing some opinions on where to look for PHP jobs and find "the good ones" out of the sea of positions.

I don't want to make this a "hire me" post, because that would and should get downvoted, but where would a person go to find interesting PHP related job ads in 2013? Some of the older big job sites like Monster and Dice are a barren wasteland of boring recruiters hiring for defense contractors, health insurance companies and low end agencies. Github has a small but decent section. Stack Overflow has some decent ones. Hacker news has a monthly thread, but a strong anti-PHP hipster bias. Reddit, at least from search has so few that I find 2 year old ones.

The responses range from links to specific companies looking for people out to some more general resources like LinkedIn, Craigslist, and yes, even recruiters (just be sure to pick a good one).

Samantha Quinones has a recent post to her blog about why you should consider continuous integration for your projects - some of the benefits and decisions that come along with it.

Last night at DCPHP, I gave a short "lightning" talk on Continuous Integration and Deployment in the context of PHP applications. I really like the lightning talk format as it forces you to focus on the meat of your topic- there's no time to get distracted by details. As great as that is, though, I wanted to expand a little on the subject and touch on some of the details that I couldn't include in my presentation.

She starts off by talking about what's wrong with a lot of the more traditional build and development practices, noting that "it sucks" because of the processes involved. With the help of continuous integration, some of the process can be automated and make for less human-related errors during a deployment. She talks about some of the things you'll need to do to prepare your codebase and a few things to think about your future setup like:

• what does a successful build look like?
• how much code needs to be covered by tests to deploy?
• should a build be successful if standards are broken or issues found?

On Reddit.com there's a big discussion happening around a question asked about Symfony2 versus Zend Framework 2 - My new boss is convinced Symfony2 is not suitable for big projects. He wants us to start developing with ZF2. Should we? Here's his story:

I have worked with ZF1 and Symfony2. To me, Symfony2 is not only more productive (with all the CLI thingies), but is much more robust, modular... better in almost all ways. I don't know much about ZF2. I've read some comparatives (here in this subreddit as well as in a few articles), but got nowhere. I either need reasons to learn ZF2 (and start the new projects with all difficulties a newbie would encounter, which sounds overly tedious, I must say) or arguments to provide my boss with. Even opinions from people who know both frameworks.

There's lots of different opinions shared in the comments ranging from pro-Symfony2, pro-ZF2 out to those that eschew both and opt for something lighter for their needs (like an advanced setup of Slim).

In her latest post Anna Filina proposes that full test coverage is an impractical way to measure the quality of your software. It can provide a false sense of security, even if the tests are poorly written.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

She looks at how it's impractical to expect that all tests will be written efficiently or even correctly. Even simple tests are enough to show up on code coverage reports but may only be painting part of the picture. She also notes that not all software can be tested the same way - things like APIs require different testing skills/methods than something like consumer software.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. [...] Focus on building great software. Tests are a tool to make it better. Just don't overdo it.

Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

I was wondering what people here preferred for setting up REST APIs. Specifically if they had a preferred PHP framework for setting them up. in the past I had used CodeIngiter but am looking at Laravel some recently. I don't anticipate extremely heavy usage but I'd like to easily update the framework when it has new releases without a real pain working around my models and controllers.

Several different options were mentioned in the comments including:

• Flight
• Silex
• Symfony2
• phalcon
• Laravel
• CakePHP

Do you have a favorite you use for your REST APIs? share it here!

Anthony Ferrara has a new post to his site today describing what he sees as a failure in our industry - letting security become an after-thought to the development process.

In the April issue of the PHPArch magazine (also published on her blog), Elizabeth Tucker Long wrote a really interesting editorial piece coining a concept she called Security-Driven-Development. She (quite correctly) identified a problem in the current development community where security has become an after-thought (if it's thought of at all). This isn't a new concept, in fact it's a concept that I and many others have been preaching for quite a while now. However I've been coming to realize that I've had it wrong the whole time. And I think the entire industry is getting it wrong today.

He talks some about the current state of web application development and how, even with more powerful technologies than ever, we still fall short in security testing. He suggests that the current way of doing things - treating security testing as a "throw it over the wall" or "someone else's job" problem - needs to stop. Security needs to be integrated with development and he suggests that managers and developers of open source projects should take the lead.

On Reddit.com there's a discussion happening comparing two popular and prominent PHP frameworks - Zend Framework 2 and Symfony 2.

For those that have used both frameworks, what one do you feel is a better overall framework? I tried ZF2 in beta and it seemed overly complicated to symfony but I don't know if its gotten better since then.

Opinions shared in the comments of the post include things like:

• "So if you are learning for job prospects, go Zend. I love Symfony 2 though, its a joy to work with."
• "It doesn't matter. Each has a strength and a weakness, and neither will go away. Pick one and use it, you'll be fine."
• "I don't think there is such thing as a best framework as you should use the best tool for the job. I don't think MVC is the solution to all problems."
• "Both are quite bloated but they have to be considering their target markets."

On the whole, the views are of the "best tool for the job" mentality - a good sign for the community and these two frameworks.

On Reddit.com a reader has asked the community what they think he needs to do to progress his PHP skills past the "little bit" he's learned so far.

Last summer I started learning a little bit of PHP, knowing HTML and CSS drove me towards wanting to learn some PHP for fun. I went through a pretty simple book, and made some simple websites (registration and message system, user submitted data, file uploads) using mostly tutorials which I tweaked a little bit. Since last summer I haven't learned anything new, but now that summer is coming along again I might be a bit bored, so I have been thinking of attempting to learn even more.

Suggestions included in the comments are things like:

• Learn about software architecture.
• Understand your environment.
• I very highly suggest learning a PHP framework.
• http://www.phptherightway.com
• Start learning industry tools for PHP. It will all influence your coding style, and illustrate why some styles are considered best practices.
• To add to the other suggestions, I recommend becoming a regular contributor to one or more open source projects.
• What helped me a lot was to write my own micro framework using OOP that I can now use for future websites and web applications.
• Come up with a 'complex' web site/application idea and get to it. Bonus points if you can launch it and make money off it (half kidding).

You can read the full set of comments for more good suggestions here.

About a month back Samuel Levy wrote up a post sharing some of his thoughts on PHP, mostly centered around one idea - that PHP is the right tool for the job (for all the wrong reasons).

When people complain about PHP being a horrible language, not fit for human consumption, they will often talk about how the features of their favourite language are far more refined; have been designed with elegance in mind; are consistent and secure. And you know what? They're right. But PHP is still a better tool. [...] And it shouldn't be. It really shouldn't. I want another language to knock PHP out of the way. [...] I can't, though, because PHP does one thing really well that no other language seems capable of doing. It works, out of the box, for people who don't know what they're doing.

He goes on to talk about the "installation" required with running PHP scripts and how it makes it mostly "idiot-proof" to use. He points out that PHP has a definite niche in the world of web development languages - one that has a larger need that some others.

This is the challenge for all the people who want to complain about PHP - if your chosen language is so much better (and I have no doubt that in many ways, it objectively is), then make it accessible in the way that PHP is. Until then, keep that double-clawed hammer in your shed in case you want to make... burgers...

Matthew Setter has a new article on his MaltBlue site today that suggests that one of the reasons a project is successful is because of effective testing.

Like many of us, despite being told repeatedly how great testing is, the benefits it will bring, the time it will save and how it will improve the quality of my applications, I too considered testing a second-thought. I saw it as something which was both expensive and time-consuming. If I was genuine with you, I'd say I believed it be be nothing more than a "nice to have", after the application was written. If you also feel (or have felt) this way - know that you're not alone.

He realized, though, that the usual false assumptions about testing were just that and starteed getting into testing, TDD and BDD on recent projects. He talks some about some general thoughts around testing like "testing can't be an after-thought" and the fact that it's no always easy. He includes a way of thinking about testing in your application and the confidence good, solid tests can bring.