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

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

SitePoint PHP Blog:
Defensive Programming in PHP
Jul 21, 2015 @ 11:49:07

In an article from the SitePoint PHP blog author Jeff Smith walks us through some advice he has about defensive programming in PHP, that is good practices for writing code that more gracefully handles potential error points.

Defensive programming, simply put, is programming with the intent to anticipate likely failure points. The goal is to circumvent those likely problems before they occur. You see the problem, right? There’s something inherently difficult with the advice “expect the unexpected” and it’s made many times worse when one alters it to “expect the unexpected and try to prevent it”. Let’s look at some practical examples.

He touches on a few of the most common places where errors could be introduced with unexpected input or functionality:

  • Conditional Statements
  • User Input (and trusting it....hint: never)
  • Assumptions [Made] About Your Code
  • Tunnel Vision (or not using good development practices)
  • Consistency in Syntax and Naming

Each point in the list includes a brief summary of what to look out for and things you can do to prevent the problem. It's by no means an exhaustive list, but it is a good place to start.

tagged: defensive programming tutorial opinion advice

Link: http://www.sitepoint.com/defensive-programming-in-php/

Lorna Mitchell:
So You're Thinking Of Submitting A Talk
Jul 17, 2015 @ 09:21:40

With another round of "conference season" and Call for Papers starting up, there's some timely advice from Lorna Mitchell with some suggestions about submitting a talk to the conference of your choice.

I've been a conference speaker for a lot of years now, which doesn't make me an expert but it does mean that people ask me for advice pretty regularly! With the Call for Papers open for PHP North West at the moment (awesome conference, first weekend in October, CfP at http://conference.phpnw.org.uk/phpnw15/call-papers/), I've taken this question a few times. Here's my advice in a nutshell.

She shares five tips that she feels can help you make for a better abstract and submission including writing it down before submitting and asking for peer reviews before hitting that submit button. She also links to a few other helpful resources that can provide even more tips to help you even once you've been selected.

tagged: submit conference talk advice opinion callforpapers technical

Link: http://www.lornajane.net/posts/2015/so-youre-thinking-of-submitting-a-talk

Are ORMs Inherently Limiting?
Jul 09, 2015 @ 11:43:37

On the /r/php subreddit on Reddit.com, TheSkilletHead wonders if ORMs are inherently limiting in PHP development. Their main point is that, in abstracting and simplifying the interface the developer has to work with, some of the power of the complex database handling is lost.

I don't feel like I'm asking too much from an ORM. I'm not asking for the ORM to manage database-side functions. I'm not asking it to manage database-side variables. I'm not asking it support every type of INSERT (like INSERT DELAYED). I'm OK that it doesn't support LOAD DATA INFILE. I'm even OK with the overhead. However, when I look up why Doctrine doesn't support UPDATE ... JOIN and the response is "it's too different across database engines", then I'm a bit disappointed because that seems to be why one would use an ORM in the first place. [...] Can an ORM be a useful tool to abstract the database or is it just a crutch for people who can't be bothered to learn SQL?

There's quite a few comments on the post already, most confirming his opinion that ORMs are limiting. Some, however, note that they don't have to be. There are some (like the CakePHP 3 ORM) that do have some more advanced features and are still easy to use. Despite this, most of the comments are about developers moving away from ORM use towards more specific, customized solutions that are a better fit for their needs and database systems.

tagged: orm limiting opinion database complexity doctrine

Link: https://www.reddit.com/r/PHP/comments/3cla9l/are_orms_inherently_limiting