Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

php[architect]:
June 2016 Issue Released - Decoupled by Design
Jun 02, 2016 @ 14:58:51

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.

tagged: phparchitect magazine june2016 decoupled design issue release

Link: https://www.phparch.com/magazine/2016-2/june/

Medium.com:
Don’t try to be too smart. Be boring, predictable and consistent.
May 11, 2016 @ 12:06:45

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.

tagged: api design boring smart consistency predictable arrayrand updatepostmeta

Link: https://medium.com/@GedRap/dont-try-to-be-too-smart-be-boring-predictable-and-consistent-d63ff2a8e5d1#.ihdjg6j99

Full Stack Radio:
Episode #35 - Jonathan Reinink - Fixing Common API Design Mistakes
Feb 24, 2016 @ 10:19:20

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.

tagged: jonathanreinink common api design mistake podcast ep35 fullstackradio

Link: http://www.fullstackradio.com/35

Ewan Valentine:
Designing Domain Specific Language
Sep 25, 2015 @ 11:56:54

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.
tagged: domain specific language design laravel injection transform json

Link: http://ewanvalentine.io/designing-domain-specific-language/

Scotch.io:
S.O.L.I.D: The First 5 Principles of Object Oriented Design
Mar 19, 2015 @ 10:30:47

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.

tagged: solid oop design principles introduction objectoriented

Link: https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

Full Stack Radio:
Episode 3: Ruby, PHP, OO design, testing & other crap with Matt Machuga
Nov 17, 2014 @ 12:15:57

The Full Stack Radio podcast has released their latest episode today - Episode #3: Ruby, PHP, object oriented design, testing and other crap with Matt Machuga, with host Adam Wathan.

In this episode, Adam talks with Matt Machuga of Think Through Math about being a Rubyist who still writes PHP and the differences between writing PHP like a Rubyist vs. writing PHP like a Java developer. They also talk about common struggles when learning new things, and trying to remain pragmatic while still pushing the boundaries of what you know.

Links in the show notes include Matt's personal website, DHH on dependency injection and a book on Domain Driven Design. You can check out this episode either using the downloading the mp3. If you enjoy the episode, be sure to subscribe to their feed.

tagged: fullstackradio podcast ep3 ruby objectoriented design testing mattmachuga

Link: http://fullstackradio.com/episodes/3/

Matthias Noback:
Packages: the case for clones
Nov 17, 2014 @ 11:55:21

In a new post to his site Mattias Noback makes a case for clones (in response to this post from Phil Sturgeon). In it he defends the creation of "clones" of tools, either slightly different version of pre-existing PHP packages or the functionality from a package in another language.

There is this ongoing discussion in the PHP community (and I guess in every software-related community) about reinventing wheels. A refreshing angle in this debate came from an article by Phil Sturgeon pointing to the high number of "duplicate" packages available on Packagist. I agree with Phil. [...] It doesn't make sense to do the same thing over and over again. At least I personally don't try to make this mistake. If I want to write code that "already exists", at least I don't publish it on Packagist. However, recently I got myself into the business of "recreating stuff" myself.

He talks some about one of his own projects (SumpleBus) and how, despite it possibly being a clone of other packages, it has slightly different goals than other tools, making it a different tool, not just a straight up clone. He also covers some of the package design principles he suggests in his book and how they can help to make an isolated package better. He also points out how recent PHP-FIG efforts to define common interfaces and structures can help reduce this kind of package duplication as well by reducing the possible implementations of any given process.

tagged: package reinvent wheel opinion duplication design principles phpfig clone

Link: http://php-and-symfony.matthiasnoback.nl/2014/11/packages-the-case-for-clones/

Anthony Ferrara:
Foundations Of OO Design
Oct 30, 2014 @ 09:36:24

In his newest post Anthony Ferrara looks at some of the things he calls the foundations of object-oriented design, as set of three things (and principles) to keep in mind when working on OOP applications.

It's quite easy to mix up terminology and talk about making "easy" systems and "simple" ones. But in reality, they are completely different measures, and how we design and architect systems will depend strongly on our goals. By differentiating Simple from Easy, Complex from Hard, we can start to talk about the tradeoffs that designs can give us. And we can then start making better designs.

He starts with the "simple vs easy" concept and how sometimes making the two meet can be difficult. He includes an example of interdependent interfaces and how they add complexity (and, in turn, make them less easy to use). He also talks about accidental versus essential complexity and how, sometimes, "accidental" isn't always a bad thing. Finally, he wraps it up with a few principles to remember in your development including recommendations to reduce (accidental) complexity and keeping the target developers in mind, making it easiest for them to use.

tagged: foundation oop objectoriented design complex simple developer opinion

Link: http://blog.ircmaxell.com/2014/10/foundations-of-oo-design.html

Mathias Verraes:
DRY is about Knowledge
Aug 04, 2014 @ 10:51:50

In this new post to his site Mathias Verraes approaches the concept of the DRY principle (Don't Repeat Yourself) as being more about knowledge. He includes two "real world" examples where the business rules can change around you.

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

In his examples, he shows how hard-coded rules (like "a product container can only contain 3 products") could just be around certain needs, not the entire range of requests. He covers some of the principles of Domain-Driven Design and how they apply here, pointing out that changing rules in one part of the application can have an effect on other parts depending on it.

tagged: dry dontrepeatyourself principle knowledge domaindriven design business goal

Link: http://verraes.net/2014/08/dry-is-about-knowledge/

Three Devs & A Maybe Podcast:
Designing for the Web with Kris Jeary
Jul 08, 2014 @ 09:45:45

The Three Devs & A Maybe podcast has posted their latest episode (#32) with guest Kris Jeary to discuss "all things design" in web development.

This week we are lucky to have Kris Jeary on the show to discuss all things design. Starting off with how he got introduced to the world of web design, we move on to discuss the process he uses to create websites. We then touch upon where he gets inspiration from, and how the emergence of responsive and SPA ideologies has changed the way we think about the web. Finally, we wrap up the show with some good advice to anyone looking into getting into web design.

The show includes mentions of cron expressions in PHP, Modern.IE and CodeKit. You can listen to this latest episode either by downloading the mp3 directly or using the in-page player. If you like what you hear, consider subscribing to their feed too.

tagged: threedevsandamaybe podcast ep32 krisjeary design web

Link: http://threedevsandamaybe.com/posts/designing-for-the-web-with-kris-jeary/