Michelangelo van Dam has a new post to his site sharing some of his ideas about the importance of documentation and how it relates to the overall security posture of a project.

In my previous post I described 10 steps we should take to improve security of web applications. In this article I'm going to describe the purpose of documenting a project and what information should be included.

He starts off with some thoughts about the purpose of documentation, how it can't ever really be considered complete, and the importance of its structure. He offers a few suggestions about effective documentation structure and how it can be formatted to make it easier to grow over time without getting too unwieldy. He then comes back around to the security aspect of project documentation. This includes information about the servers the system is running on, the services that are running and details about which secrets are used (but not the secrets themselves!).

He finishes up the post covering various technologies that can be used to help automate your project and make sure that it is well structured and easy to keep in sync with your documentation.

In a new post to his site Nikola Posa takes a look at naming conventions in code and makes some recommendations based on his own work.

In the last couple of months, I spent a lot of time studying Proophessor Do demo project that showcases features of Prooph components, all with the aim of mastering CQRS/Event Sourcing concepts. Along the way, something else turned my attention away from the main topic - unconventional, but clean and concise naming convention for class and method names.

This was a true eye-opener for me, I immediately liked the idea and after adapting it a bit I started practicing it at work. Excited and full of enthusiasm, I shared my findings and opinions with the rest of the world.

He tweeted about his excitement but found that there was more to say and a blog post was the place to put it. So in this post he covers several "anti-patterns" to avoid in code naming conventions:

• Anti-pattern 1: Prefixes/suffixes convention for Interfaces
• Anti-pattern 2: Archetype suffix convention for domain classes
• Anti-pattern 3: "get" prefix convention for property accessors

He finishes the post with some final thoughts and a "TL;DR" image showing a "right" and "wrong" way to structure your code.

In a new post to his site Tomas Votruba shares his opinions on project structure and when he sees it appropriate to use a "monorepo" and when to use packages to compose your application.

Recently I gave a few talks about monorepo in PHP and how to integrate it to companies in a useful way. I'm very happy to see many people already use it and know what problems it solves.

Before monorepo hype takes over private PHP projects, I think you should know about its limits: When is the best time for you to go monorepo? When you gain less complexity while integrating it? How can you make the transition better? Is it really needed?

He starts off by describing some of the most common application structures including the monorepo, many-repository, and local package approaches. He sees each as an evolution on the previous and shares when he thinks the evolution makes the most sense (hint: it's about value). He ends the post by sharing a few final thoughts about monorepos and when they make sense for private projects versus public, open source projects.

On the TutsPlus.com site today they're "getting back to basics" with a tutorial targeted at those just learning the PHP language. In this latest tutorial, they focus on control structures and loops such as if, else, for, foreach, while and more.

In simple terms, a control structure allows you to control the flow of code execution in your application. Generally, a program is executed sequentially, line by line, and a control structure allows you to alter that flow, usually depending on certain conditions.

Control structures are core features of the PHP language that allow your script to respond differently to different inputs or situations. This could allow your script to give different responses based on user input, file contents, or some other data.

They start with a flowchart showing the basic idea behind how flow control structures work and provide a more "real world" example of a user login. It then goes through each of the control structure types, providing a simple explanation of what it does, where it's useful and code examples of it in action.

Matthias Noback has a tutorial posted to his site sharing his thoughts on when adding an interface to a class is useful. Here he's talking about using interfaces as a structure for your application, making it easier to understand and more structured.

I'm currently revising my book "Principles of Package Design". It covers lots of design principles, like the SOLID principles and the lesser known Package (or Component) Design Principles. When discussing these principles in the book, I regularly encourage the reader to add more interfaces to their classes, to make the overall design of the package or application more flexible. However, not every class needs an interface, and not every interface makes sense. I thought it would be useful to enumerate some good reasons for adding an interface to a class. At the end of this post I'll make sure to mention a few good reasons for not adding an interface too.

He then offers five suggestions of cases where an interface makes sense:

• If not all public methods are meant to be used by regular clients
• If the class uses I/O
• If the class depends on third-party code
• If you want to introduce an abstraction for multiple specific things
• If you foresee that the user wants to replace part of the object hierarchy

For each item in the list he provides a summary of the suggestion and some code snippets to back it up. He ends the post with a recommendation about how to handle most other situations where you think an interface might be useful: use a "final" class instead.

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 post to his site Matthieu Napoli shares some recommendations about how to organize the code in your application using a "domain modules" approach. This is an organization method that relates the code based on functionality it relates to rather than the type of object it is.

We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code [and] how to organize teams.

Regarding “how to organize teams”, we were discussing Spotify’s Feature teams. In a “classic” organization, teams are usually formed by grouping people based on their job title. [...] But in a “feature team” organization, teams are organized… by features. [...] The pros of this kind of organization are numerous and I do not intend to go over them here. But what does this have to do with code organization?

He starts with the "classic" code structure - organized by each item's type (ex: Entity, Service, etc). He then suggests reorganizing it move by what it does in the application, namely which module it belongs in best. He briefly touches on dependencies, "agile design" and the differences between a normal "product" and a "product" in e-commerce. He then applies these ideas and shares a domain organized directory structure, trying to reduce the overall complexity of the structure and the overall cohesion of the codebase.

On the FormaPro blog Maskim has written up a tutorial introducing you to a new feature that's been integrated into the Yii2 framework: AMPQ Interop, a standard structure for the handling of MQ messages (queuing).

Great News! Queue Interop is one step closer to PHP world domination.

Yii PHP Framework is the first of major frameworks that has placed a bet on AMQP Interop. A corresponding pull request “Add AMQP interop based driver.” has been merged to yiisoft/yii2-queue repository.

With this integration, the Yii framework now natively supports many AMPQ packages without having to create a custom interface layer. This includes enqueue/amqp-lib, enqueue/amqp-ext and enqueue/amqp-bunny.

On the Zend Framework blog there's a new post from project lead Matthew Weier O'Phinney covering REST representations in Expressive and the release of two new components to help with their implementation.

We've been working towards our various Apigility on Expressive goals, and have recently published two new components: zend-problem-details and zend-expressive-hal.

These components provide response representations for APIs built with PSR-7 middleware. Specifically, they provide: Problem Details for HTTP APIs (RFC 7807) and Hypertext Application Language (HAL).

These two formats provide both JSON and XML representation options (the latter through a secondary proposal).

The post then goes on to talk about the idea of "representations" and how it relates back to the structure of the data returned and how the user knows what operations they can take on it. He also talks about the differences between normal responses and errors and gives example output helping to illustrate his points. The remainder of the post gets into the details of the two new components, their use and how to implement them in Expressive.

Paul Jones has a new post on his site sharing some of his thoughts about the placement of domain logic and email templates in an ADR (Action/Domain/Responder) structure. The post is an answer to a recent question he received asking how to organize emails being sent by service classes.

In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the HTML + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there.

He then provides what he sees as a good directory structure to help keep it all separated out. He also talks about the load sending emails can put on a system, when to move it to workers and how that impacts where the templating of the emails should be done.