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

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/

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

Stoyan Stefanov:
How to write unmaintainable PHP code
Sep 24, 2015 @ 10:35:38

Stoyan Stefanov has reposted an article he wrote for the PHP Advent (now Web Advent) site with a tongue-in-cheek look at how to write unmaintainable code in PHP applications.

With the unemployment rates lately being at the levels that they are, everybody realizes that job security is important. And what's the best way to keep a job but to be irreplaceable, one way or another. The simple truth is that if no one can maintain the code you write, you have a job for life. Writing unmaintainable code is a special skill that, strangely enough, seem to come quite naturally to certain developers. But for the rest of you, here are some tips and hints to get you started.

He humorously suggests poor practices in your development such as:

  • starting your new job by being vocal about "shifting paradigms" and "enterprise" code
  • making it impossible for someone to change one thing without effecting another
  • ban coding conventions
  • don't write unit tests
  • not use templating

...and more. It's a funny piece that has a good message behind it. It's a perfect example of what not to do in development (and what to avoid if you're not doing them currently). The interesting thing is that this was originally published in 2009 and just about all of the points in it are still valid today.

tagged: unmaintainable humorous code opinion funny phpadvent

Link: http://www.phpied.com/how-to-write-unmaintainable-php-code-2009/

Source Blog:
Good Code Runs on Good Communication
Sep 18, 2015 @ 11:10:27

On the Source blog there's a great post that reinforces something that all developers should keep in mind when developing their applications: good code runs on good communication. "Tech language" barriers can make this difficult, but this post gives you a few suggestions on places to start improving.

When I started the interactive team at the Sun Sentinel in 2013, I thought the biggest challenge would be the code. I was wrong. [...] It wasn’t always easy. When you need someone on your side, but they don’t speak the same tech language, it can be very difficult. Investing (not necessarily financially, but emotionally and mentally) in creating a space where teams can work better together is key. Here are some strategies for overcoming the language barrier to make collaboration smoother.

They recommend things like:

  • having face-to-face conversations to work out the best solutions
  • avoiding assumptions about skill levels
  • pausing to check and ensure everyone understands the current state of conversation
  • agreeing on common terms and naming

Finally, they make a recommendation that could make some of the developers out their cringe a bit: "document the madness". As they point out, having good documentation of not only the result of the work but also the process along the way can be crucial for future work and others not directly involved in the process to review.

tagged: good code communication opinion recommendation language conversation

Link: https://source.opennews.org/en-US/articles/code-runs-communication/

Michael Mikowski:
RESTful APIs, the big lie
Sep 09, 2015 @ 11:19:31

Michael Mikowski has a post to his site that suggests that a RESTful API is a big lie and that the concept should "rest in piece" and be replaced with something he calls a "JSON-pure API".

If you have read an internet developer resume or job posting in the past 10 years, then you might be forgiven if you think that RESTful APIs are gifts bestowed from the heavens by The One True Web Developer Deity. RESTful APIs are everywhere. Even the marketing folks are pushing them in sales material intended for CEOs and Human Resources-type folks. So how good of an idea are RESTful APIs really?

He starts with a look at where the concepts for a RESTful API originally came from and defines some of the most common concepts around them (verbs, request/response, etc). He then suggests that they're "pretty awful" and lists some of the larger problems he sees with them:

  • Problem #1: There is little agreement on what a RESTful API is
  • Problem #2: The REST vocabulary is not fully supported
  • Problem #3: The REST vocabulary is not rich enough for APIs
  • Problem #4: RESTful APIs are very hard to debug
  • Problem #5: RESTful APIs are usually tied to HTTP

He suggests that the way to move forward is to migrate to the "JSON-pure API" methodology, fixing most of the problems he listed. He describes this kind of API and how it simplifies the entire process and makes it "more reliable, easier to use, easier to port, and easier to debug."

tagged: restful rest api jsonpure problem lie opinion

Link: http://mmikowski.github.io/the_lie/

Allan MacGregor:
TDD is not Dead
Sep 08, 2015 @ 10:30:01

Allan MacGregor has a post to his site with some of his thoughts on why TDD isn't dead and is still a viable option to help reduce bugs and improve software quality.

So, where does this whole TDD is DEAD thing came from? Well, it all started with let's say a provocative talk and follow up blog post by David Heinemeier Hansson (@DHH) where he expressed his frustration with testing and put into question the value of TDD. [...] TDD is not dead, not really. And it won't really ever be dead, it will change or be replaced with something better; in fact it already has, and in my Magento Extension Test Driven Development book we focus on Behavior Driven Development, an approach that emerged from the original TDD methodology.

He goes through each of the points that DHH mentions in his post and offers some of his own thoughts on the topic:

  • Developers make you feel like your is dirty if you don't practice TDD
  • Driving design from unit tests is not a good idea
  • TDD notion of "fast tests" is shortsighted
  • 100% coverage is silly.
  • TDD created test-induced design damage.

He ends with the most common misconception about testing in general too: i"t's too much work/it will make my development slower." He also looks at some of these kinds of comments specifically targeted at Magento 2.

tagged: tdd testdriven development dead opinion dhh

Link: http://coderoncode.com/testing/magento/2015/09/03/tdd-is-not-dead.html

Phil Sturgeon:
Avoid Hardcoding HTTP Status Codes
Aug 17, 2015 @ 12:55:53

Phil Sturgeon has a post to his site with a good recommendation for those working with APIs and those "magic numbers" that are HTTP status codes - avoid hard coding them in your applications and tests.

A lot of things in programming are argued to death, but one subject where people almost unanimously agree is that magic numbers can be a pain in the ass, and they should be avoided whenever possible. Sadly when it comes to HTTP status codes, people keep on hardcoding them, and it leads to all sorts of confusion. [...] What is 409? If you answer without looking it up on Dash or HTTP Status Dogs then you are a machine.

He shows two implementations of this idea, one in Ruby and the other in Symfony, where the status code value is represented by a constant rather than by a number. The constant correlates to the HTTP status code (number) but the constant makes it easier to read and understand the code. He points out two libraries that can be substituted into your current testing to replace those hard coded values with more expressive versions: lukasoppermann/http-status and Teapot.

tagged: avoid hardcode http status code opinion expressive teapot httpstatus

Link: https://philsturgeon.uk/http/2015/08/16/avoid-hardcoding-http-status-codes/

Kevin Ennis:
On Unit Testing
Jul 27, 2015 @ 11:48:31

On Medium.com Kevin Ennis has shared some thoughts on unit testing and how he's "done a 180%" on what kind of value he feels they bring.

There are a lot of really easy ways to rationalize not testing your code, and I’m probably guilty of saying each of them at one point or another. For some engineers, I think the reluctance to embrace unit testing is basically just FUD. Like so many other things, testing seems scary if you haven’t done it before.

But it’s also really difficult to fully understand the benefits of testing unless you’ve worked on a project that has good tests. So it’s easy to see why?—?without fully understanding the upside?—?many developers regard unit testing as an unnecessary step.

He goes through several of the common excuses for not writing unit tests and debunks them one at a time. He also includes a brief section at the end of the post with a recommendation on how to get started testing...essentially "just do it".

tagged: unittest opinion common rationalization fud

Link: https://medium.com/@kevincennis/on-unit-testing-1cc6798f81ee