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

Larry Garfield:
Don't use Mocking libraries
Sep 21, 2018 @ 11:02:10

Larry Garfield has written up a post with a somewhat controversial headline, especially for anyone that's done any kind of unit testing on a larger codebase. His suggestion is to no use mocking libraries and some other techniques that can replace them.

I am all for testing. [...] There's a lot of opinions on what constitutes a "good" test, of course, and much is subjective to the type of code you're working on. However, since the release of PHP 7 I've found that while writing tests... I am never using a mocking library. In fact, I'm going to go as far and say that you should never use a mocking library in PHP 7.

Before all of you gasp, clutch your pearls, and send ninja hit squads after me, let me justify that position.

He starts off by defining what a "mock" is a more general sense and then, more specifically, how mocking libraries are mostly implemented in PHP. He covers the DSL (domain specific language) knowledge that's required to use most of them and how something already included in PHP 7 - anonymous classes - could be a viable alternative. He goes on to show examples of using this method rather than a mock for simple object handling and even recommends making an actual class (just for testing) if the need is there. He ends the post talking about the "upper bounds" of when this might not be as useful and how this can actually be good (using it as an indicator that you need to refactor the main code to simplify).

tagged: mocking mock library testing unittest opinion anonymous class

Link: https://steemit.com/php/@crell/don-t-use-mocking-libraries

Terry Chay:
Which has better packages, Python or PHP?
Sep 13, 2018 @ 10:27:50

Terry Chay has an interesting post on his site that wonders which language has better packages - PHP or Python?

It depends on the target utility. In the Python world, the most common package installer is pip; the PHP world didn’t settle on a dominant format/installation for packages until composer, and that was relatively recently (last 4 years).

[...] So which has better packages? The answer is it depends on the domain. In nearly any language you can find an adequate package for any of your needs, but overall you will find the packages are higher quality, more up-to-date, and sometimes just better overall in the domain the language seems to target well.

He starts off by talking some about PHP and Python's origins - PHP as a web-focused language and Python as more general purpose - and how this influenced their package implementations. He then shares his opinions on which kind of packages are a more natural fit for which languages:

  • for data science/AI/ML applications, Python
  • for DevOps, relying on other tools (Puppet/Chef/Ansible/etc) is better
  • For server-side web-based packages, I feel PHP and Composer [are the solution]

He also includes some thoughts about other languages - Ruby, Javascript, Go - and their own package managers.

tagged: package manager python comparison opinion usage

Link: http://terrychay.com/article/which-has-better-packages-python-or-php.shtml

Tomas Votruba:
5 Advices I Would Love to Get Before Starting to Maintain an Open Source
Sep 13, 2018 @ 09:48:23

In a new post to his site Tomas Votruba has shared a list of five things that he, as an open source package maintainer, had heard before getting started.

I wasn't always confident while making public every single line of PHP code I write. I had to take many blind paths, spend a night full of stress coding in unknown waters and make a lot of over-complicated code that backfired to me months later.

They say "experience cannot be passed and it must be experienced" and I agree with that, but still there are some shortcuts that would speed-up my path to joyful open-source coding I have today. Here are 5 of them.

He then shares his suggestions, each with a brief summary explaining what it means and how you can apply it:

  1. Be Open to Change any Package
  2. Don't Keep Every feature You Have
  3. Lock to LTS, Maintained Dependencies and green PHP
  4. All You Need to Maintain is 1 Repository
  5. Don't Take Advise as Granted, Experiment for Yourself

He includes some of his own backstory in several of the posts about his own development work and how he found out some of these "the hard way".

tagged: opensource advice maintainer package opinion top5 list

Link: https://www.tomasvotruba.cz/blog/2018/09/10/5-advices-i-would-love-to-get-before-starting-to-maintain-open-source/

Matthias Noback:
Final classes by default, why?
Sep 12, 2018 @ 12:08:54

In this post to his site Matthias Noback makes the argument that, during your normal development, classes should be final by default and only changed if there's a need to extend them.

I recently wrote about when to add an interface to a class. After explaining good reasons for adding an interface, I claim that if none of those reasons apply in your situation, you should just use a class and declare it "final".

[...] For a couple of years now I've been using the final keyword everywhere (thanks to Marco Pivetta for <a href="https://ocramius.github.io/blog/when-to-declare-classes-final/>getting me on track!). When I see a class that's not final, it feels to me like it's a very vulnerable class. Its internals are out in the open; people can do with it what they want, not only what its creator has imagined.

Still, I also remember my initial resistance to adding final to every class definition, and I often have to defend myself during workshops, so I thought it would help if I explained all about it here.

He starts off by talking about the alternative - non-final classes - and some of the issues that can come with it (and class extension). He makes the suggestion that "replacing is better than overriding" and creates less complexity overall. He also answers a question about the use of the "Template Method" design pattern that would allow for improvement from base "skeleton" logic designed to be extended. He covers "composition over inheritance", the use case of extension and how "final" is a better direction.

tagged: final class exposure extension opinion override template composition

Link: https://matthiasnoback.nl/2018/09/final-classes-by-default-why/

Matthias Noback:
When to add an interface to a class
Aug 28, 2018 @ 09:12:04

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.

tagged: interface class opinion structure top5 class tutorial

Link: https://matthiasnoback.nl/2018/08/when-to-add-an-interface-to-a-class/

Matthias Noback:
Improving your software project by being intolerant
Aug 21, 2018 @ 11:51:19

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.

tagged: software improvement intolerance structure ownership opinion

Link: https://matthiasnoback.nl/2018/08/improving-your-software-project-by-being-intolerant/

Stitcher.io:
Service locator: an anti-pattern
Aug 20, 2018 @ 12:47:01

On his site Brendt has shared some of his thoughts about why he sees the service locator design pattern as an anti-pattern and harmful to your overall application.

As a Laravel developer, I'm confronted daily with the service locator pattern. Every facade call and several helper functions are built upon it.

[...] During a discussion with my colleagues, I found it difficult to put into words what exactly is wrong with grabbing things out of the container - a service locator - so I decided to write my thoughts down, with an example. [...] I want to highlight three problems with this approach, directly caused by the use of a service locator.

He goes through a list of where he sees the use of the service locator functionality causing problems including:

  • getting runtime instead of compile-time errors
  • obfuscation of actual functionality
  • increased cognitive load

He ends the post with a quick suggestion on how to solve the issue: use actual dependency injection instead of "magic" locators.

tagged: servicelocator designpattern antipattern opinion error obfuscation cognitive

Link: https://www.stitcher.io/blog/service-locator-anti-pattern

Matthias Noback:
More code comments
Aug 16, 2018 @ 10:06:58

In response to a comment he saw on Twitter about comments in code, Matthias Noback has written up a post with some of his own thoughts.

Recently I read a comment on Twitter by Nikola Poša. [...] He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

Matthias starts with the suggestion that, when correctly written, code shouldn't need comments to be clear about what's happening. He encourages the use of the "refactor for clarity" method to remove comments and make the code more clear. He finishes the post by breaking down the types of comments (explanatory, todo and "wtf"), what they are/examples and in what situations they can be useful for.

tagged: code comment refactor opinion clarity types usefulness

Link: https://matthiasnoback.nl/2018/08/more-code-comments/

Larry Garfield:
PHP: Never type hint on arrays
Jul 30, 2018 @ 12:05:48

In a new post Larry Garfield makes an interesting suggestion related to the use of arrays in PHP. He suggests that you should never type hint arrays in your method definitions.

Let's be controversial: In modern PHP, you should never type-hint an array. Before you start throwing tomatoes, hear me out.

PHP allows you to specify the type of a function/method parameter or return value. These return values can be any legal PHP type. [...] PHP has a data type that it calls array, although it's not really an array as any other language would define it. [...] And you should almost never use array as a type hint. Why? Because there's always a better, more generic option.

He starts off talking about the use case where arrays are used as a "single complex value" and how,. more often than not, a class is actually a better option. He then covers the other main use of arrays: as an ordered sequence of values. To replace this he recommends a more structured collection that can apply some logic to its contents. With these other options out of the way, he then talks about what arrays are actually useful for and some other potential typehints to allow arrays and other potential inputs. He ends the post talking about array operations included in PHP and how, with a minimal amount of effort, they could be reproduced with simple methods for use on actual collection instances instead.

tagged: typehint array options class collection opinion

Link: https://steemit.com/php/@crell/php-never-type-hint-on-arrays

Tomas Votruba:
Why is Your Company Losing Money by not Open Sourcing: 1. Hiring
Jul 27, 2018 @ 09:22:36

On his site Tomas Votruba has a post sharing one thing he thinks is holding back your company from doing well: not open sourcing code.

Do you want to hire developers? Do you want to hire those developers who help your company in the long term? Do you want to save money for random picks of HR agencies? Do you want to hire developers who already know your code before even meeting you? Do you want to attract developers in the long term with zero investment?

Go Open-source!

He goes on to talk about some of his own experiences in the job interview process and how "old-school methods" aren't working as well as they used to. He then makes some suggestions about how to attract programmers "in a 2018 way". He uses a comparison between the traditional hiring process and a newer one ("open hiring"). He makes the suggestion of, when looking to fill a role, going to the contributors list of your or other popular packages and see who has contributed and reach out to them first. This allows you a preview into their skills and lets you evaluate it (and other contributions) against your needs for the role.

tagged: opensource hiring money contribution opinion

Link: https://www.tomasvotruba.cz/blog/2018/07/26/why-is-your-company-losing-money-by-not-open-sourcing-1-hiring/