In a post to his site Andreas Möller shares a tool that he uses to get an application up and running quickly, providing a makefile for lazy developers.

Whatever the size of the software project, I believe in, subscribe to, and promote Continuous Integration. Personally, I rely on Travis CI as an automated build system. Regardless of whether an automated build system can be set up and used for a project or not, I prefer to be able to run build steps locally. This prevents stress testing the automated build system and taking away resources from other developers. Also, it gives me more confidence before committing and pushing changes upstream.

[...] For a couple of years now I have been using make, after having been introduced to it when working on a project in 2014. While it has its limitations, it’s short and simple, and most of all, it get’s the job done.

He then talks about the repository he's created to get up and running quickly that creates a simple Makefile to define several make commands and shortcuts for some common tasks. The make it task is the most used, executing all of the other tasks to ensure that all tests pass, the code is well-structured and generates a coverage report to ensure as much of the code is covered by tests as it should be.

The RIPSTech group has a post to their site with the announcement of the return of their security-related advent calendar. This year, however, it comes in the form of the PHP Security Advent Calendar with more of a "common security problems in PHP" approach than a list of vulnerabilities.

The end of the year is coming closer and the cheery advent time begins. We are looking back at a spectacular year and it is time to thank and give back to the great PHP, infosec, and RIPS community. Thank you for developing, auditing, and securing your PHP applications with us in 2017!

Similar to last years advent of PHP application vulnerabilities where we released a new application vulnerability each day, we will release a new calendar gift from December 1st to 24th this year again. This time, we will focus on nifty PHP pitfalls and release a daily code challenge for you to solve. Can you spot the daily security bug?

As today is December 1st, the first item has been posted to the calendar covering the use of whitelists versus blacklists. Keep checking back daily for new updates to the calendar and the daily code challenges.

On the Laravel News site they've introduced a package from Adam Wathan that cam help simplify the use of the popular Guzzle package for making HTTP requests. Zhttp is a wrapper around Guzzle and tries to make the code to make the requests simpler and easier to follow.

Zttp is a new PHP package by Adam Wathan that is a Guzzle wrapper designed to bring an expressive syntax and simplify common use cases. [...] Zttp simplifies the code to make the request and automatically returns the JSON response.

A few other examples of requests using the tool are provided: POSTing with parameters, sending a PATCH/PUT request, adding an Accept header and how to prevent the request from following redirects. You can find out more on the project's GitHub repository and grab the latest release to try out in your own code.

On the Toptal.com site author Donald Mudenge has written up a post that wants to help debunk the top 5 WordPress myths that are still floating around about this popular and common tool.

In the early days, people used WordPress only as a blogging tool. However, today WordPress covers more than 50 percent of the market share for CMSs, supporting nearly 60 million websites worldwide.

As a commonly used platform for building websites and other online applications, misconceptions have spread like a forest fire, keeping people away from WordPress. In this article, I outline and explain the five most common WordPress taboos and myths, clarify them and offer solutions on how to overcome them.

The five myths he tries to dispel are:

• WordPress is significantly more likely to be hacked.
• WordPress is just blogging software.
• WordPress professionals are designers.
• WordPress isn’t an enterprise solution.
• One WordPress requires one database.

For each item on the list he includes a brief summary of what's usually said about the myth and corrects it with his own description and links to other resources helping to prove his point.

On the Toptal.com site a new article has been published from author Ilya Sanosyan with his list of top ten development mistakes he sees PHP developers make leading to more buggy code.

PHP makes it relatively easy to build a web-based system, which is much of the reason for its popularity. But its ease of use notwithstanding, PHP has evolved into quite a sophisticated language with many frameworks, nuances, and subtleties that can bite developers, leading to hours of hair-pulling debugging. This article highlights ten of the more common mistakes that PHP developers need to beware of.

Included in his list are common issues like:

• Leaving dangling array references after foreach loops
• Confusion about returning by reference vs. by value
• Performing queries in a loop
• Assuming $_POST will always contain your POST data
• Ignoring coding standards

For each item on his list he provides good code examples and explanation of both why it's an issue and what can be done to prevent it.

On the QaFoo blog there's a post sharing some of what they've learned about the common bottlenecks in performance testing and some things you can to do determine the issues in your own tests.

Most developers by now internalized that we should not invest time in optimizations before we know what happens exactly. [...] This is true for optimizations in your PHP code but also for optimizations regarding your infrastructure. We should measure before we try to optimize and waste time. When it comes to the assumed performance problems in your system architecture most people guess the root cause will be the database. This might be true but in most projects we put under load it proved to be false.

So, how can we figure out where the problems are located in our stack?

They talk about some common testing practices using basic tools (like ab and siege) and having them perform common operations on the application. They then talk about testing for high load, monitoring the stack for the impact and a few tools you can use to gather statistics. They end the post with a quick mention that, despite popular opinion, the issue isn't always the database's fault. Sometimes other technology that's in play - like file locking issues or processing for server-side includes - and other things that may only show up under high load.

In the latest episode of the Full Stack Radio podcast host Adam Wathan talks with Jonathan Reinink about common API design mistakes and some recommendations on how to fix them.

In this episode, Adam talks to Jonathan Reinink of Code Distillery about common API design challenges and how to fix them. Topics include: when to use nested resources and when to avoid them, strategies for dealing with actions that don't seem to fit into REST and sing singular sub-resources and optional fields to simplify your responses.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly. If you enjoy the show be sure to subscribe to their feed or follow them on Twitter for news on when the latest episodes are released.

The Paragon Initiative has posted an article to their blog talking about how to build secure applications in PHP. Rather than try to get into the specifics of specific vulnerabilities, they stay relatively high level and stick with concepts to keep in mind and steps you can follow to ensure your development practices are secure.

Whether you're planning the development of a brand new application or trying to prevent legacy code from causing a costly data breach, if you're going to be writing PHP, where should you begin? That is the question we will attempt to answer, in detail.

The article starts with an "easy way out" for those that don't feel like they know enough or just don't have the resources they need: hire consultants. With that out of the way, the article mentions two root causes for insecure apps: lack of knowledge about security and bad development habits. They then get into some suggestions about how you can learn to understand and prevent vulnerabilities in your own applications. They focus in on a few key places for PHP developers to pay attention to, complete with some charts showing the parts of the flow. The post ends with some advice on what do to if your site is compromised anyway and how to move forward.

On Medium.com Kevin Ennis has shared some thoughts on unit testing and how he's "done a 180%" on what kind of value he feels they bring.

There are a lot of really easy ways to rationalize not testing your code, and I’m probably guilty of saying each of them at one point or another. For some engineers, I think the reluctance to embrace unit testing is basically just FUD. Like so many other things, testing seems scary if you haven’t done it before.

But it’s also really difficult to fully understand the benefits of testing unless you’ve worked on a project that has good tests. So it’s easy to see why?—?without fully understanding the upside?—?many developers regard unit testing as an unnecessary step.

He goes through several of the common excuses for not writing unit tests and debunks them one at a time. He also includes a brief section at the end of the post with a recommendation on how to get started testing...essentially "just do it".

The Blackfire.io PHP debugging service (from SensioLabs) has a new post to thier blog today talking about how the service makes use of Docker to build the environments for testing out their users' code.

As you may know, Blackfire was represented at the SymfonyLive conference in Paris. During this event, several people came to us and asked how we use Docker at Blackfire.io. One of our goals is to make profiling straightforward for anyone, and it means that we need to be able to easily test our product on a lot of different platforms. And Docker gives us the ability to spin up new containers in milliseconds.

Moreover, our website relies a lot on different tools, so containers can also help us reach an iso-production development environment. But Docker is only available on Linux and a big part of the Blackfire's team is using MacOS X. So how one using MacOS X can use the best of both worlds?

The post goes on to talk about their use of the boot2docker tool and how they can use it to help with the environment customization most developers want out of their testing. They show how it updates the network settings, works with file sharing, allows for multiple domain names/containers and solutions to some other common issues including no container access, no name resolution and a "bonus" section with a Skydock plugin for custom DNS naming.