In a new post to his site Tomas Votruba talks about the benefits of writing SOLID code and uses a more real-world example rather than talking about SOLID in theory.

Use SOLID to write Clean Code... Are you tired of theoretical post about how to do achieve some therm? So am I. Instead, let's dive into real problems I came across while coding and let the code speak the theory between lines.

Today we try to add own config option to YAML of Easy Admin Bundle (without pull-request to the package).

In his example, he works with a training platform he's creating for use by the Pehapkari community that makes use of the EasyAdminBundle. He starts off with what he's trying to accomplish ("the need"): being able to change only certain pieces of information. He then walks through the process he followed to customize the form and "getting creative" to be able to add items to the form without having to add each individually. He walks about his "wandering" through the code to look for a solution and, ultimately, how he found the answer using another configuration file.

Joe Watkins has a new post to his site that provides his opinions about answering the people that say "PHP wasn't designed for X".

Starting complicated twitter conversations should be avoided, I know this, and yet blurted this out on twitter recently...

This was met with a flurry of responses and I couldn't reasonably reply in tweet form. I'm going to respond to some of those tweets (indirectly) and further explain my original tweet.

He starts off by talking about how PHP isn't always the right tool for a certain job (some people's misinterpretation of his tweet). He also talks about why PHP isn't a "templating language" and has evolved so much beyond some of its original roots. He ends the post responding to the original comment, that "PHP wasn't designed for X". He talks about the opinions of those not as familiar with the current state of the language and, when they say "just because you can, doesn't mean you should" (meaning that they think you actually shouldn't).

When support emerges for a new problem domain, let's be pragmatic and observe that expanding the horizons of PHP in any direction is good for the community that relies on PHP (and maybe PHP alone) to make a living. Let's not rush to take new solutions to production tomorrow, but let's not dismiss anything out of hand because of some imaginary short coming in PHP.

Matthias Noback has a new post on his site with his thoughts about the design of value objects. He makes use of an example he recently saw in the code he was working with: the idea of "quantities" of items.

I recently came across two interesting methods that were part of a bigger class that I had to redesign. [...] What happens [in the methods] is: we have an order line, which keeps track how much of a certain product has been "ordered", and then how much of it has been "delivered" so far. It also keeps track of how much is currently still "open". Changes to these "delivered" and "open" quantities happens when we "process" a delivery, or "undo" a delivery.

I was reminded of a recent blog post by Nicolò Pignatelli where he quoted a question from another programming website. Adopted to the situation at hand: "Which variable type would you use for representing a quantity? Integer, Float or String" It's a trick question, because all the answers are wrong. Nicolò advises not to use a primitive type value, but to design a value object that can represent a quantity.

He then walks through the process for refactoring this quantity handling out into a value object replacing the current float handling. He recommends applying more thought to how the object will be used and how the different types (open, ordered and delivered) relate to each other. He also includes examples of how to replace the add/subtract operations in the original code while still using value objects as immutable constructs.

Christoph Rumpel has a post to his site sharing the process he followed in migrating his blog site from Jekyll to Laravel. Jekyll is a Ruby based static site generator rather than a dynamic solution like Laravel provides.

One of my resolutions for 2017 was to redesign my blog. One week before the new year I faced myself with the challenge and thought to myself if this was still doable. Somehow I managed it and here it is. In this article I will explain the process and show you how I redesigned the blog with Tailwind CSS and moved it from Jekyll to Laravel with keeping almost the same performance.

He then walks through the entire process, breaking it down into a few different sections:

• How to start
• The backend stack
• Toughest decisions are the ones about design
• Tailwind CSS
• Make it fast

For each of the sections there's code, screenshots and links to other resources included.

The TutsPlus.com site has posted the latest article in their "Building Your Startup with PHP" tutorial series today. In this latest tutorial author Jeff Reifman shows how to improve the home page for the application to make it more visually appealing and well-structured.

A web service's home page has many roles. Functionally, it must make it easy for people to sign up and get started with the application. But it must also aesthetically touch visitors and give them a professional impression that your service delivers what the home page tells them it does.

Since I've been so focused to this point building the scheduling functionality for Meeting Planner, I haven't had time to focus on polishing the home page—and frankly it was falling short, leaving first-time visitors unimpressed.

He shows the updates he's made to the home page for the service, adding in some additional formatting with Bootstrap and CSS to replace the current bland look. He starts by laying out the improvements visually then moving over to the code to make it a reality. Code is included showing how to implement the changes and add in other features like a mobile-friendly version and embedded videos.

php[architect] magazine has published their latest edition - the June 2016 issue, Decoupled by Design.

The June 2016 issue of php[architect] magazine is now available! Less tightly coupled code is easier to debug and re-use. This month we look at techniques to decouple different aspects of your code: including using asynchronous & distributed workers, transducers, middleware, and secure web services.

The issue includes articles like:

• "Security Architecture: Securing your Web Services, Part Two" (Edward Barnard)
• "The Middleware Awakens" (Ian Littman)
• "MySQL’s JSON Data Type" (Dave Stokes)

...as well as several of the usual columns sharing community and professional development tips. If you're not a subscriber and want a sampling of the content, be sure to check out the free article for this month covering video manipulation with FFmpeg. You can also pick up a subscription directly from the php[architect] site if you want to read more.

In this post on Medium.com Gediminas Rapolavicius provides a word of warning to those creating APIs (interfaces for tools, not like REST APIs) - "don't try to be too smart", favor consistency over cleverness.

When designing an API, it’s tempting to do a bit of extra work and surprise the developers using it. It might be returning some additional information that would require an additional call otherwise, or try to predict the intentions and handle some specific cases differently. The intentions are perfectly fine?—?provide a pleasant, simple interface.

The problem is that it requires making assumptions which, sometimes, are inevitably wrong. The worst case is when the API makes an assumption of what the developer expect to get back, gets it wrong, and returns something unexpected. More work with docs, more bug fixing.

He gives two examples of things he's encountered where the idea of the API was simple but assumptions made turned out to make things a bit more difficult: PHP's own array_rand function and WordPress' update_post_meta. He briefly covers each and explains that, while the intentions seemed good, the implementation was a bit confusing (and at times inconsistent), causing troubles when not functioning as expected.

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.

In a post to his site Ewan Valentine looks at some considerations to think about when creating a domain specific language in your applications. This kind of language helps define common terms, conventions and practices for developers to follow in their code.

When you spin up a framework such as Laravel, Symfony etc. The first thing you'll notice, is that they have their own 'feel'. I often joke that Symfony2 is like Java and Laravel is like Ruby.

But what gives an application or a framework a 'feel'? Domain specific language or 'DSL'. Domain specific language is almost like a syntax or a language specific to your application and ecosystem. DSL is what makes your applications code unique and more usable.

He gives a specific example of a Laravel application he was creating and how he wanted the interface to function, transforming the result of a find() into a JSON response. He shows how it could actually be done but that introduces more maintenance and more code to cover. Instead he worked backwards into the domain context the request was operating in and found an ideal injection point for transformation that would keep it out of the controller action itself.

So, to design usable domain specific syntax, start at the front. In other words the part you'll be writing the most, and then work backwards to abstract the logic and make it actually work.

On Scotch.io today they've posted a tutorial about SOLID, the "first five principles of object oriented design". SOLID is an acronym made from the first letter of several principles that can help make your OOP code well-architected and easier to test.

S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as Uncle Bob. These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development. Note: this is just a simple “welcome to S.O.L.I.D” article, it simply sheds light on what S.O.L.I.D is.

They start with a basic overview of what the letters in SOLID stand for and then work through each, providing basic code examples to help make the point clearer.