On the TechBeacon site they've posted an article about choosing the right testing tools for your codebase and why making the right choice matters.

Fast end-to-end tests are the next big thing. The tooling has improved tremendously, and the productivity and insight gains are too good to ignore. Modern tools such as Cypress and >TestCafe are becoming quite impressive and can give you confidence in your product's quality.

As with most facets of software development, there is a balance to be strived for between speed and test confidence. The leverage point depends on the project, and the two most common types of software project these days are web services and enterprise software.

They talk about some of the differences between the testing of web services versus enterprise software as well as some of the practical advantage of fast tests. They also cover the advantages of broad tests and cover some of the current tools for testing including Cypress.io and Laravel Dusk.

Matthias Noback has written up an article where he suggests "being intolerant on your software development" as it relates to being stubborn about the quality/structure/etc. of your project's code.

During the holiday I read a book mentioned to me by Pim Elshoff: "Skin in the game", by Nassim Nicholas Taleb. Discussing this concept of "skin in the game" with Pim had made me curious about the book.

[...] Something that's controversial, yet interesting for me as a developer in a team - from Chapter 2, "The Most Intolerant Wins: The Dominance of the Stubborn Minority": "Society doesn't evolve by consensus. [...] All one needs is an asymmetric rule somewhere - and someone with soul in the game. And asymmetry is present in about everything."

He relates this back to software development, pointing out that many of the important decisions about a project aren't made by committee. Rather they're made by a single source, either a individual on the team or an outside source of "truth". He makes some suggestions as to how this kind of structure can be put in place by doing more than talking and "having skin in the game" as it relates to the impact your decisions make on your software.

In a new post to his site Junior Grossi shares some of his thoughts about Open Source and how it's less about "free software" and more about sharing and giving back.

Maintaining an open source project – even a small one – is not an easy task. The open source ecosystem is about sharing and contributing, about giving and receiving. You scratch my back and I will scratch yours.

He suggests that working in Open Source is less about the actual software that's being written as it is a lifestyle. For him, the goal is to make someone else's life better by working on something you're sharing (instead of working on something commercial). He includes a quote from Fabien Potencier (of Symfony) about Open Source developers being exploited for their free software and how, despite the gift of time and work spent on the code, some people don't appreciate the work and just complain.

Instead of complaining about features or bugfixes, do it yourself, and show your gratitude for people that spent their free time working on something to help your life. They could be with their family but no, they were doing open-source. And you should thank them for that.

He finishes with a few thoughts about giving back to the projects you use and enjoy. It doesn't always have to be about code too - you can submit bugs, contribute to documentation or even just write up a tutorial to share your own knowledge of using the package.

The Kinsta blog has published an article they call the Definitive PHP 5.6, 7.0, 7.1, 72. and HHVM benchmarks providing a comparison between these different versions running different popular PHP software (including WordPress, Drupal and Magento 2).

Each year we try and take a deep dive into performance benchmarks across various platforms and see how different versions of PHP and HHVM stack up against each other. This year we went all out and benchmarked four different PHP engines and HHVM across 20 different platforms/configurations; including WordPress, Drupal, Joomla!, Laravel, Symfony, and many more. We also tested popular eCommerce solutions such as WooCommerce, Easy Digital Downloads, Magento, and PrestaShop.

[...] The results this year have drastically changed from our previous benchmarks where HHVM was the winner. We now are excited to see PHP 7.2 as the leading engine in terms of speed. [...] This is great news for developers and end-users alike as it means more of a focus back on PHP and providing faster websites and web services for everyone.

The post then starts with a look at the system setup (well, Google Cloud instance) that's used for the testing and how it is configured. From there it goes into the test results from each of the different types of software:

• WordPress
• Drupal
• Joomla!
• Magento 2
• Grav CMS
• October CMS
• Laravel
• Symfony
• PyroCMS
• Pagekit
• Bolt
• AnchorCMS
• PrestaShop
• CraftCMS
• ForkCMS

As you can see there's more of a leaning towards content management and e-commerce solutions in their list. It's good to see base frameworks in the list too, however. For each item in the list they provide a graph of the results showing requests per second.

Jeff Madsen has a post on his site where he shares his opinions about Open Source software and companies giving back to the projects they use and love. His basic idea is that they're "screwing themselves" if they're not contributing for a few different reasons.

This will be a short piece, so I’m not going to go down [the] rabbit hole right now [of project timing], but tell me one thing: When a construction company is handed a one-of-a-kind blueprint of a new house, do they respond, “Well, golly gee! This has never been built before? - ?I have no idea how long it would take”?

[...] If you are good at creating software estimates, you probably already know the Joel Spolsky guide to making (somewhat) accurate ones. Break it down into small bits that you can understand. [...] Now…here’s where we start honing in on my point. I may have lied to you a little bit above?—?that construction team may not know how long it takes to build a stud wall with wiring [...] because they use bloody pre-fab for everything these days!

Relating this back to Open Source, he links these "pre-fab" items back to Composer packages, Node modules, etc and how they can help make things more efficient (more than writing it all yourself). A lot of companies see OSS as a way to get free software they don't have to create or maintain. Unfortunately they don't take into account the work behind them and how nothing ever fits 100% so you end up making modifications. If you contributed those modifications back to the project that could mean never having to do it again in your own work.

He ends with a few recommendations for companies looking to contribute these fixes and suggestions back to projects including providing monetary support or looking at paid versions over free ones.

In a post to his site Keith Mifsud shares his recommendations around a good workflow for developing PHP applications. Composer and GitHub play a part in the process as does the use of Git and your IDE of choice.

Continuing from the previous post Developing a Command Bus in PHP, we will look into how to get started in setting up our composer library project. Although my PHP software development workflow does vary slightly from project to project, most steps are more or less the same. Whether your project is the result of a successful proposal or you want to build an open source composer package like we’re doing here, this post will guide you in working with PHP the right way. If you are learning PHP from scratch and find that I am missing some intermediary steps or making assumptions, please feel welcome to comment below and I’ll be more than happy to explain in more detail.

He then walks through the steps in the process, each with explanation (and screenshots where appropriate):

• Getting organized and planning the application features
• Creating the GitHub repository and setting up the Kanban board
• Defining a release milestone
• Setting up a local Homestead instance for development
• Setting up Git and your IDE

The final step is to create the composer.json configuration file that defines the basic information about the project, any dependencies and the autoloading paths.

On the Toptal.com site they've posted an article from Fernando Martinez with some suggestions about how to attract and retain software developers. The ideas cover the full range - all the way from the job posting/interview process out to how to keep them with the company and help them thrive in their role.

Management is all about people. Whether managers or employees, both are thinking about how to achieve their personal and professional goals. The combination of these goals and the personal traits of the people involved give shape to relationships that, in time, can be positive, productive, and fulfilling, or sometimes just plain stressful, demanding, and conflict-prone.

[...] This is especially true in managing software developers, because of their job’s technical complexity and creative nature, compressed into often narrow timelines for producing results. [...] In this article, we will focus on the main management aspects, rather than on the technical ones, that we think should be considered by anyone who wants to be successful in managing to retain software developers.

He starts with a look at how to attract and hire the right people for the roles you're trying to fill with suggestions about the interview process and the job offer. Next he gets into recommendations about managing the team itself and the importance of training, organization and communication. The article then goes on to cover other topics like conflict management, keeping up motivation and assigning objectives/follow up.

php[architect] has posted the latest episode of their podcast, hosted by PHP community members Eric van Johnson and John Congdon - Episode 3: Composing Software.

In this episode, we dive into the October 2017 issue and how to use Composer to build a modern PHP application. Do you have a thought on the topics covered? Do you use queues obsessively, or not? Let us know with a comment.

Topics covered by Eric and John include articles in the October issue of the magazine, new ways to use Composer, machine learning and more. Editor Oscar Merida also joins them and talks about frameworks versus "plain" PHP. You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the show for offline listening. Also, if you enjoy the episode, be sure to subscribe to their feed for updates when new episodes are released.

In this new post to his site Herberto Graca has posted the latest part of his "The Software Architecture Chronicles* series, focusing this time on event-driven architectures.

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Using events to design applications is a practice that seems to be around since the late 1980s. We can use events anywhere in the frontend or backend. When a button is pressed, when some data changes or some backend action is performed.

But what is it exactly? When should we use it and how? What are the downsides?

He starts by talking about the "what", "when" and "why" of using events to drive the architecture of the system, going into each of the topics in a bit more depth:

• To decouple components
• To perform async tasks
• To keep track of state changes (audit log)

He then goes on to talk about common patterns for event-driven applications including event notification, event-carried state transfer and event sourcing.

php[architect] magazine has an announcement on their site about the release of the latest edition of the publication, the October 2017 issue: Composing Software.

Articles in this month's edition include:

• Managing Private Dependencies by Andrew Cassell.
• Alain Schlesser writes about Uncommon Ab(Uses) of Composer.
• Read about Building Software that Lasts by Susanne Moog.
• Continue Building Software that Lasts by Edward Barnard.

The usual columns return as well - Education Station, Artisanal, The Dev Lead Trenches (and many more). You can pick up a copy of your own directly from the site, either opting to get the single issue or a year-long subscription. If you want to "try before you buy" and see what the content is like, you can check out this free article about managing private Composer dependencies.