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

Ethode.com:
Fixing Spaghetti: How to Work With Legacy Code
Jan 27, 2016 @ 12:09:38

On the Ethode.com blog they've shared some hints for working with legacy code to help you more effectively refactor your way out of the "spaghetti code" you might have right now. These are more general tips and aren't really PHP (or even really web application) specific but they're a good starting place for any refactoring effort.

Legacy code is software that generates value for a business but is difficult for developers to change. [...] The longer this goes on, the more frustrated customers get with the software due to quirky defects, bad user experiences and long lead times for changes. Developers are afraid to make changes due to the "Jenga effect" -- as one piece of code is changed or removed, it often leads to new defects being introduced in the system in sometimes seemingly unrelated places. This compounds into what is known as "technical debt".

They continue on talking about what "spaghetti code" is, how it can happen and some of the warning signs you can use to determine just how far down the rabbit hole you and your code are. They talk about "The Big Rewrite" everyone dreams of but points out that this is almost never a practical path. Instead they offer some good things you can do to help fix the problem: quarantining the problem, refactoring relentlessly, keeping it simple and "doing the dishes" as you go rather than letting the changes pile up.

tagged: legacy code refactor opinion advice fix software development

Link: http://www.ethode.com/blog/fixing-spaghetti-how-to-work-with-legacy-code

7PHP.com:
Happy New Year 2016 Message From Phil Sturgeon To The PHP Community
Jan 04, 2016 @ 10:09:33

The 7PHP.com site is back with their first interview with a member of the PHP community in 2016. In this latest article Phil Sturgeon answers some questions from Khayrattee about his background, how is 2015 was and what he sees coming for the PHP community in 2016.

A little more than over 2 years ago (in June 2013), I did my 34th 7PHP interview with a young dynamic (can very much say as explosive as a dynamite as well – explosive in the good sense) named as Phil Sturgeon. I still remember at that time while I hit the “publish” button and tweeted above that interview, I unconsciously wrote Phil Surgeon instead of Sturgeon. We had a good twitter moment. Time flies and in Feb 2015, I was even able to meet Phil in person at SunshinePHP Conference in Miami.

Phil answers questions about his previous year (2015) and how the PHP community helped him through some issues he had between 2014 and early 2015. He also shares his thoughts on the current state of the PHP community and language. He mentions the difficulties happening around the PHP-FIG group and some of his predictions and advice for the PHP community in the coming year.

tagged: philsturgeon 7php community language interview opinion

Link: http://7php.com/newyear2016-philsturgeon/

James Lewis:
Composition over Inheritance PHP Style
Dec 28, 2015 @ 10:49:45

In this post to his site James Lewis makes the suggestion that you consider composition over inheritance when it comes to writing your object-oriented PHP. That is, using PHP's traits functionality to compose interfaces with only the functionality needed, not other possibly useless things.

So what does “composition over inheritance” mean? [...] Lets dive into an example written in PHP to help us better understand composition over inheritance. [...] Almost all modern programming languages have a way of dealing with composition, PHP has Traits. Traits where introduced into PHP at version 5.4 and the PHP docs describes traits as a mechanism for code reuse.

He starts with an example of using inheritance to create new "animal" types but points out that this can lead to extra functionality as sometimes your Robocat just doesn't need to eat. He then introduces traits as a way around the issue, creating traits for each piece of functionality and using PHP's use statement to include only the ones needed for that particular kind of object.

tagged: composition style inheritance traits opinion

Link: http://blog.jwlewisiii.com/composition-over-inheritance-php-style/

Jani Hartikainen:
Why is fixing bugs so slow? (and how to make it faster)
Dec 17, 2015 @ 12:06:32

On his CodeUptopia blog Jani Hartikainen has posted a great article with some of his thoughts about why fixing bugs is so slow and includes a few suggestions on how to make it happen faster and streamline the process for the future.

Have you ever wondered why sometimes fixing bugs seems to take much longer than it should? When you finally find the problem, it turns out all you need is one small change. Yet, it took a lot of time to find what’s going on. This happens to me more often than I’d like.

[...] Why is it that sometimes fixing bugs takes a lot of work even when the problem is simple, and other times, it’s really quick to fix the problem – maybe even when it isn’t so trivial? Is there something we can learn from the bugs that are easy to fix, so that we could spend less time fixing bugs in general?

He starts off by describing a typical bug fixing process after the initial discovery and reporting of the issue down to the actual fix being deployed. He then breaks down each of these six steps and provides more context around them:

  • Understanding the problem
  • Reproducing the bug
  • Finding the problematic piece of code
  • Identifying the root cause
  • Fixing the bug
  • Ensuring the bug is fixed

He then goes back and talks about the pain points in this typical process citing things like a lack of good information around the bug and the time constraints that often come with the "time to fix" allowance. He makes some suggestions about how to gather better information around the issue before the fix begins and points to effective logging as one possible source. He also talks about how unit testing can help verify the bug is actually fixed and help to prevent and locate future issues.

tagged: bugfix speed slow opinion process unittest faster advice

Link: http://codeutopia.net/blog/2015/12/16/why-is-fixing-bugs-so-slow-and-how-to-make-it-faster/

Reddit.com:
How do you see the PHP-FIG?
Dec 14, 2015 @ 09:48:49

There's been a big discussion happening over on the PHP-FIG (Framework Interoperability Group) mailing list recently about the goals and vision for the project. While the group originally started out as a way to define standards for frameworks and projects to work together, some have begun to wonder if it's a bit more far reaching than that. This discussion/poll on Reddit sums up the question nicely:

There are some ongoing discussions on the PHP-FIG mailing list about, among other things, how the FIG is seen by the wider PHP community. [...] Since an earlier discussion pointed out that perhaps the FIG, while well-known, don't do enough "active outreach", consider this an attempt to "reach out."

Do you think:

  • The FIG is a bunch of self-aggrandizing elitist jerks who couldn't write a competent or useful "proposed standards recommendation" if their lives depended on it, and should disband entirely.
  • The FIG, while aware that the wider PHP community is watching, writes PSRs primarily for itself, and others can adopt or ignore as they wish;
  • The FIG has become the closest thing to a userland standards group that the PHP community has, and should accept that role;
  • Some other opinion?

There's already 50+ comments on the thread with several of the options being supported. There seems to be a leaning towards either the second option or the third with advantages and disadvantages for both. The group has undoubtably helped to change the way that modern PHP is written and they want to keep the tradition going and be what the community and language need. Go over an voice your own opinion on the matter too!

tagged: phpfig organization opinion poll standards community feedback interoperability

Link: https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/

Larry Garfield:
Drupal 8: Happy, but not satisfied
Dec 03, 2015 @ 10:53:57

In this new post to his site Drupal developer Larry Garfield talks about why he's "happy, but not satisfied" about the release of Drupal 8 and the current state of the code in this major milestone.

Two weeks ago (hey, I've been busy and trying to sleep for once), after 1716 days of work by more than 3312 people the Drupal community finally released Drupal 8, the latest release of the best community-driven web software in the world. The blogosphere is already filled with congratulatory blog posts celebrating the immense accomplishment, and deservedly so.

A number of people recently have asked me how I feel about Drupal 8's release, especially around the PHP community. Overall, my answer has to be that I'm happy, but not satisfied.

Among the things on his "happy" list are the fact that you can "teach an old codebase new tricks", that there's a real framework underneath it and that more modern development styles are being followed. On the flip side, there are some things he's not entirely satisfied with including the current state of OOP in the project, the testability of the codebase, how Composer was adopted and the lack of layout support in core. He gets into reasoning for his points on both sides but ends the post on a happier note, pointing out the people he's thankful for and the work that's been done by each to make the project what it is today.

tagged: drupal8 opinion happy satisfied release

Link: http://www.garfieldtech.com/blog/drupal8-happy-not-satisfied

Matthieu Napoli:
Approaching coding style rationally
Nov 13, 2015 @ 11:51:07

In a post to his site Matthieu Napoli shares some of his thoughts about "code style rationality" including code formatting in general and some suggestions on one of the harder things in development - naming things.

Habits are sometimes making us blind. We think X looks prettier than Y but that’s just the habit speaking. In this article I’ll try to take a rational approach at coding style. That means leaving the “it looks ugly/better” at the door.

If at any point you feel like something “just doesn’t look good”, breath in, breath out, and try it! Nothing beats hands-on experience, not even some random article on the internet.

He looks at a few subjects specifically (there's way too many to cover them all in detail):

  • the use of trailing commas
  • alignment of values in docblock comments
  • keeping docblock comments minimal
  • using the "Interface" suffix
  • using the "Exception" suffix

He ends the post by reminding readers that the point is to think about code style logically and that no rules are written in stone.

tagged: code style formatting rational approach opinion comma docblock interface exception

Link: http://mnapoli.fr/approaching-coding-style-rationally/

Kinsta Blog:
10 Things Not To Do In PHP 7
Nov 11, 2015 @ 09:53:36

On Kinsta.com Daniel Pataki has posted a list of seven things not to do in PHP 7 when it's finally released. It's no secret that there's a lot of new functionality coming with this new version but that also potentially means some bad practices coming along with them.

I’ve already shared some of the upcoming features of PHP 7, in this article I thought I’d take a look at some of the bad patterns we should stop using as we switch to the lightning fast PHP 7.

Among the things on his list are suggestions like:

  • Do Not Use mysql_ Functions (removed from core)
  • Do Not Use PHP Close Tags At The End Of A file
  • Do Not Perform Queries In A Loop
  • Do Not Trust User Input

Some of the suggestions do have a direct relation to what PHP 7 has to offer but most of them are just good practices to follow during your development work. Quite a few good tips in there, especially if you're relatively new to the language and want to start with PHP 7 and go.

tagged: php7 top10 opinion development practice habits recommendation

Link: https://kinsta.com/blog/10-things-not-to-do-in-php-7/

ThePHP.cc:
On Hackathons
Oct 16, 2015 @ 14:32:34

In his post over on thePHP.cc site Stefan Priebsch talks about hackathons and why they should possibly be considered harmful. Here he's talking about the ones where a project is given at the start and a product is expected at the end, not just general time for developers to hack together on their own projects.

Last month, at a conference in Bulgaria, I participated in a hackathon for the very first time. The task was to build a small REST API for the tracking of shipping containers and a frontend to visualize a container's GPS position. I would like to share some of my thoughts and experiences (and this is neither going to be about the code we wrote, nor about the fact that we won).

He talks about the team that he was a part of and the different pieces they each contributed. He notes one unfortunate thing though: due to time constraints (3 hours), ramp up time and planning of the application, corners had to be cut to make the deadline.

Going back to the hotel, I realized that during the hackathon, the tight schedule had forced us to do pretty much everything that we all know you should not do. And that we had just experienced a "real" project situation: a tight deadline, not enough communication "because we have no time", rushed technical decisions like just using HTTP "because we have no time", doing things quick and dirty "because we have no time". Does that sound familiar to anybody? Exactly: most teams that I have met (and I have met many of them) experience just this on a day to day basis. And it is wrong.

He suggests that hackathons, in this particular format, should be considered harmful as they reinforce bad decision making and poor development practices. He offers some suggestions that could help to make future events better and an offer to provide guidance for those wanting to make a better event.

tagged: hackthon harmful project timelimit opinion

Link: https://thephp.cc/news/2015/10/on-hackathons

Loïc Faugeron:
Decouple from Frameworks
Oct 06, 2015 @ 09:48:23

In this recent post to his site Loïc Faugeron shows his support for a pretty common "battle cry" among developers that make use of one of the many PHP frameworks out there: decouple from your framework (including a few strategies how).

Frameworks solve infrastructure problems, for example how to create a HTTP or CLI application. While necessary, those concerns don't add any value to your project: the business need will not be fulfilled by creating an empty application. As always, different responsibilities mean also different reasons to change: frameworks have a history of Backward Compatibility (BC) breaks and they do so regardless of your project.

[...] Does that mean that we shouldn't use any frameworks? Should we just don't care and embrace fully frameworks? This article will explain how to avoid both extremes, by decoupling from the framework. It can be done by restricting the framework to its infrastructure responsibilities (HTTP, CLI), by only using its entry points (Controller, Command) and by using the Command Bus pattern.

He uses a simple application to illustrate his points, starting with a basic Symfony installation with PHPUnit and PHPSpec installed. He builds a listener to handle JSON encoded content input and sets up the initial "Quote" controller that will take in the new request. He follows the TDD mentality along the way, testing first then writing the code to match the test. With that system in place, he talks about the ideas of commands (from the "command bus" world) and how that could be used to refactor out the "submit" logic and make it less dependent on the framework it lives in. This lets the framework handle the low-level functionality (HTTP request/response, routing, etc) while the logic sits in a more abstract, contained location.

tagged: decouple framework opinion commandbus refactor encapsulate

Link: http://gnugat.github.io/2015/09/30/decouple-from-frameworks.html