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

Why Developers Should Not Code
Jul 19, 2017 @ 11:16:01

On thePHP.cc blog Stefan Priebsch offers up an interesting opinion about code, developers and understanding - developers shouldn't code.

The ultimate problem with program code seems to be that no human really understands it. Sure, we can look at a short piece of code and be relatively clear on what it does, but can we still do the same thing with programs that span tens or even hundreds of thousands of lines?

[...] Well, sometimes I get a strong feeling that there is a shortage of good programmers, because I often find myself looking at legacy code, being unable to tell what it does, at least with reasonable certainty. [...] Personally, I already consider code to be problematic when there is a reasonable amount of doubt as to what it does (and why it exists). To me, uncertainty and discussions are a sure sign of bad code. Call me picky, but years of experience have taught me that this level of strictness makes sense.

He suggests that the fact a developer cannot recognize what current code is doing doesn't make you a poor developer, but the opposite. He talks some about the meaning of the word "code" and how it is written for a machine to understand, not a human. He ends the post talking about testing your code to provide an "executable specification" and, despite having this, a human-readable spec is still a requirement (like it or not).

tagged: developer code opinion specification testing

Link: https://thephp.cc/news/2017/07/why-developers-should-not-code

Jason McCreary:
You changed the code, you didn't refactor the code.
Jul 13, 2017 @ 11:16:27

Jason McCreary has a post with an interesting perspective about code refactoring and what it means to refactor. He suggests that just changing code isn't refactoring and that it's more about changes in the observable behavior.

There was a good discussion on Twitter yesterday regarding a code contribution to the Laravel framework. It ended with some good questions about the distinctions between “refactoring” vs “changing” code.

While I want to focus on these distinctions, let’s first focus on the code change.

He gives an example of some code from the suggested change that reduced the number of lines in a before function call that still satisfied the requirements defined by the unit tests. He suggests that, while this change allowed the method to work as expected, it was more of a "change" than a "refactor". He suggests that because the code internal to the method changed that the "observable behavior" changed because of a special case with the return value. Existing tests didn't catch the change so it was assumed the refactor was successful even when it wasn't. Adding this test and fixing the issue then resulted in a true refactor and not just a change.

Given the symbiotic relationship between refactoring and testing, some consider the tests to be the requirements. So if all tests pass, you met the requirements. I think that’s a slippery slope. For me, the definition of “refactoring” again provides the answer through its own question - did we change the observable behavior?
tagged: code change refactor opinion unittest patch laravel

Link: https://jason.pureconcepts.net/2017/07/refactor-vs-change-code/

PHP Roundtable:
064: PHP 7 Source Code: A Deep Dive
Jul 12, 2017 @ 13:35:41

The PHP Roundtable podcast, hosted by PHP community member Sammy K Powers, has posted their latest episode: Episode #64 - PHP 7 Source Code: A Deep Dive. In this show Sammy is joined by Sara Golemon, a core language contributor and XHP.

We take a deep-dive into the underlaying structure of the the PHP source code and talk about the scanner, parser, the new AST layer (and the evil things we can do with it), and the Zend engine. Let's see how the PHP sausage is made!

You can catch this latest episode either through the in-page audio or video player, directly on YouTube or by downloading the mp3 directly. If you enjoy the episode, be sure to follow them on Twitter and subscribe to their feed to get updates when future shows are being recorded and are released.

tagged: phproundtable podcast ep64 php7 deepdive source code saragolemon

Link: https://www.phproundtable.com/episode/php-7-internals-scanning-parsing-ast-and-engine

SitePoint PHP Blog:
How to Build a Cryptocurrency Auto-Trader Bot with PHP?
Jun 15, 2017 @ 11:11:27

On the SitePoint PHP blog they've posted an article from author Joel Degan showing you how to create a bot to auto-trade cryptocurrency with a bit of PHP and this boilerplate code.

This tutorial will walk you through the full process of building a bitcoin bot with PHP – from setup, on to your first execution of an automated trade, and beyond.

[...] But, you say, I am a coder who likes to automate things, surely we can fire up some BTCbot and we can have it just do the work for us, it will make us millions in our sleep, right? Probably not. I don’t want to write a bot and publish it with a single strategy and just say “here, use this”, I don’t think that is helpful to anyone, I would rather give you the tools and show you how to write strategies yourself, show you how to set up data collection for the strategies and how to implement them in a trading system and see the results.

He then walks you through the installation of the boilerplate code and the list of commands/scripts that come with it. He shows how to set up the Redis/MySQL connections and each of the sites you'll need to set up an account on to either perform trades or get the latest currency information. With all of that installed and set up he starts in on the code and functionality, grab the latest data, write a bit of code to manipulate that data and create other handling to manage your own preferences and trading rules.

tagged: cryptocurrency autotrade tutorial boilerplate code

Link: https://www.sitepoint.com/build-cryptocurrency-auto-trader-bot-php/

Paul Jones:
“Action Injection” As A Code Smell
May 17, 2017 @ 11:53:16

In this recent post to his site Paul Jones suggests that "action injection" in PHP applications should be considered a "code smell" (that is, a bad practice that could indicate that the controller class is doing too much).

Circumstance has conspired to put Action Injection discussions in front of me multiple times in the past few days. Having seen the approach several times before, I have come to think that if Action Injection is the answer, you might be asking the wrong question. I find it to be a code smell, one that indicates the system needs refactoring or reorganizing.

He first covers what "action injection" is and provides an example of how it would fit in with the use of a dependency injection container. He also points to some of the frameworks that currently support this functionality natively. With that defined, he then moves into the main idea of the post - that using functionality like this is a "code smell" that could signal something that is in need of refactoring. He then provides some suggestions on things to change and mental shifts in thinking about how your application is organized. He finishes by pointing to the Action-Domain-Responder pattern as a way of implementing this and how single-action controllers can help.

tagged: action injection code smell actiondomainresponder

Link: http://paul-m-jones.com/archives/6589

Expressive Code & Real Time Facades
May 10, 2017 @ 11:13:54

On his Medium.com blog Laravel project lead Taylor Otwell shares some of his thoughts on expressive code and real-time facades and how they make things simpler, event for testing/mocking.

Recently, I worked on some code that surfaced my most common use-case for Laravel 5.4’s “real-time” facades. If you’re not familiar with this feature, it allows you to use any of your application’s classes as a Laravel “facade” on-demand by prefixingFacades to the namespace when importing the class. This is not a feature that is littered throughout my code, but I find it occasionally provides a clean, testable approach to writing expressive object APIs.

To illustrate he uses the code from the Laravel Forge service talking about service providers (like DigitalOcean, Linode, etc) and "service" classes to contain API methods. He then shifts over to the controller to see how he'd like to access it, making a generic Provider class with a make method to create the instance. This has an issue, however, with testing making it very difficult. Instead he shifts over to the real-time facades and a factory where the test can more easily manually mock the method into a stub provider (example included).

tagged: expressive code realtime facade testing factory tutorial

Link: https://medium.com/@taylorotwell/expressive-code-real-time-facades-41c442914291

Robert Basic:
Open source taught me how to work with legacy code
May 01, 2017 @ 09:36:29

In a new post to his site Robert Basic shares how some of his work on Open Source projects taught him how to better work with legacy code.

Contributing to open source projects has many benefits — you learn and you teach, you can make friends or find business partners, you might get a chance to travel. Even have a keynote at a conference, like Gary did.

Contributing to open source projects was the best decision I made in my professional career. Just because I contributed to, and blogged about Zend Framework, I ended up working and consulting for a company for four and a half years. I learned a lot during that time.

He shares some of the things that open source taught him about working with code and how it relates back to legacy code (including how to find his way around). He also tries to dispel the myth that all legacy code is bad and was "written by a bunch of code monkeys who know nothing about writing good software." He points out that, at the time the code was written, the changes may have been the best that could be done, it might be a necessary workaround or it could be an actual bug that needs fixing.

tagged: opensource legacy code opinion experience codemonkey

Link: https://robertbasic.com/blog/open-source-taught-me-how-to-work-with-legacy-code/

QaFoo Blog:
How You Can Successfully Ship New Code in a Legacy Codebase
Apr 21, 2017 @ 13:39:13

On the QaFoo blog there's a new post sharing some ideas on how you can add new code to a legacy application and ship it successfully without too much interruption to the current code.

Usually the problems software needs to solve get more complex over time. As the software itself needs to model this increased complexity it is often necessary to replace entire subsystems with more efficient or flexible solutions. Instead of starting from scratch whenever this happens (often!), a better solution is to refactor the existing code and therefore reducing the risk of losing existing business rules and knowledge.

[...] Instead of introducing a long running branch in your version control system (VCS) where you spend days and months of refactoring, you instead introduce an abstraction in your code-base and implement the branching part by selecting different implementations of this abstraction at runtime.

They then give a few examples of methods that can be use to get the new code in:

  • Replacing the Backend in a CMS
  • Rewriting a submodule without changing public API
  • Github reimplements Merge button

The final point is broken down into the process they recommend including the refactor of the current code, starting in on the new implementation and deleting the old code.

tagged: refactor ship new code legacy application tutorial

Link: https://qafoo.com/blog/101_branch_by_abstraction.html

How to Perform Extract Service Refactoring When You Don't Have Tests
Mar 22, 2017 @ 10:42:39

On the QaFoo blog they've posted an article sharing advice about refactoring to extract logic to services when there's no testing to cover the code.

When you are refactoring in a legacy codebase, the goal is often to reduce complexity or separate concerns from classes, methods and functions that do too much work themselves. Primary candidates for refactoring are often controller classes or use-case oriented service classes (such as a UserService).

Extracting new service classes is one popular refactoring to separate concerns, but without tests it is dangerous because there are many ways to break your original code. This post presents a list of steps and checklists to perform extract service when you don't have tests or only minimal test coverage. It is not 100% safe but it provides small baby-steps that can be applied and immediately verified.

The article talks about some of the primary risks when performing this kind of refactoring and how their extract method recommendations could case some of those issues. The tutorial then breaks down the process into the small steps:

  • Step 1: Create Class and Copy Method
  • Step 2: Fix Visibility, Namespace, Use and Autoloading
  • Step 3: Check for Instance Variable Usage
  • Step 4: Use New Class Inline
  • Step 5: Inline Method
  • Step 6: Move Instantiation into Constructor or Setter
  • Step 7: Cleanup Dependency Injection

While that seems like a lot of steps to take, they're all pretty small. They include a series of code snippets giving you an example to work from, making these small steps to refactor current functionality into a Solr service class.

tagged: tutorial refactor extract service tutorial unittest example code

Link: https://qafoo.com/blog/099_extract_service_class.html

Nicola Malizia:
Understanding Laravel’s HighOrder Collections
Mar 14, 2017 @ 09:11:59

Nicola Malizia has written up a tutorial that helps to explain Laravel's HighOrder collection functionality, a feature that was added in Laravel 5.4.

A new version of Laravel is available from 24 January 2017 and, as usual, it comes with a lot of new features.

Among them, there is one that takes advantage of the dynamic nature of PHP. Some out of there will contempt this, but I find it awesome!

He talks briefly about what the normal Collection class provides and provides an example of creating a collection and using the "map" function to return an average. With the new functionality the methods can be called directly on the collection with a simplified format. With the example out of the way he then dives into the source code for the feature, showing how it defines the "proxy" methods allowed and uses the __get and __call magic methods to map the method calls back to a collection.

tagged: laravel highorder collection tutorial introduction code

Link: https://unnikked.ga/understanding-laravels-highorder-collections-ee4f65a3029e#.uo1gmhbgu