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

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

Reddit.com:
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

Reddit.com:
Why experienced developers consider Laravel as a poorly designed framework?
Jul 03, 2015 @ 11:41:03

There's a huge thread that's been going on over in the /r/php subreddit on Reddit.com with opinions on why experienced developers consider Laravel as a poorly designed framework.

I have been developing in Laravel and I loved it. My work colleagues that have been developing for over 10 years (I have 2 years experience) say that Laravel is maybe fast to develop and easy to understand but its only because it is poorly designed. He is strongly Symfony orientated and as per his instructions for past couple of months I have been learning Symfony and I have just finished a deployment of my first website. I miss Laravel ways so much.

Currently there's over 200 responses to the question with a wide range of opinions, everything from support of Laravel and its ways to the other side supporting Symfony and its structure. As is par for the course, there's also a share of "troll" comments in the mix, so be sure as you're reading through them to weed those out. There's also some interesting and enlightening things about Laravel, its structure and what it has to offer that those that may not be familiar with it could learn.

tagged: reddit rphp experienced developer laravel poorly designed framework opinion

Link: https://www.reddit.com/r/PHP/comments/3bmclk/why_experienced_developers_consider_laravel_as_a/

Marc Aube:
Choosing your project's dependencies
Jun 02, 2015 @ 11:01:59

Marc Aube has shared some thoughts about picking your project's dependencies and considerations to think about when building your applications.

If you work on any non-trivial project, chances are you'll install one or many external dependencies at some point. [...] However, you shouldn't bring any library in your codebase. While Packagist has, at the time of writing, around 60000 packages you could use in your project, most of them are not production quality. Here's a list of things to look for when choosing a generic library for a mission-critical project, in no particular order.

Among the things he suggests, there's tips like:

  • Ensure it has a stable version
  • That it's extensible
  • It's active and maintained
  • The license permits the intended use
  • It has quality documentation

For each he offers a brief paragraph or two explaining the point and examples where appropriate of projects matching the topic.

tagged: dependencies project opinion list suggestion choice

Link: http://marcaube.ca/2015/06/choosing-dependencies/

Lorna Mitchell:
Code Reviews: Before You Even Run The Code
Jun 02, 2015 @ 09:50:01

Lorna Mitchell has posted a list of helpful tips to perform good code reviews on submissions before even trying to run the code for correctness.

I do a lot of code reviewing, both in my day job as principal developer and also as an open source maintainer. Sometimes it seems like I read more code than I write! Is that a problem? I'm tempted to say that it isn't. To be a good writer, you must be well-read; I believe that to be a good developer, you need to be code-omnivorous and read as much of other people's code as possible. Code reviews are like little chapters of someone else's code to dip into.

She offers several tips you can follow to make the reviews you do more effective including:

  • Ensuring you understand the change
  • Are the changes where you'd expect?
  • Does the commit history make sense
  • Evaluate the diff to ensure the changes themselves are valid

She only then recommends trying out the code. Following the suggestions above can help ferret out issues that may be hidden by just running the code and not fully looking into the changes.

tagged: code review suggestion list opinion before execution

Link: http://www.lornajane.net/posts/2015/code-reviews-before-you-even-run-the-code

QaFoo Blog:
Developers Life is a Trade-Off
May 27, 2015 @ 10:57:57

In a new post from the QaFoo blog they talk about a developer's life as a trade-off, the amount of work to put into one technology or approach before deciding it's not worth the trouble and moving on.

At Qafoo, we train a lot of people on topics like object oriented software design, automated testing and more. [...] There is no silver bullet and one of the most important skills every developer needs to hone is to assess possibilities and to find the best trade-off for the current challenge.

He uses personal experience to illustrate the point, a struggle they had with choosing a storage system for their application's data. While one technology seemed to be an ideal fit (Cassandra) the trouble it caused made them fall back to something more reliable. He also talks about another instance where he had to make a decision around using a state machine...or not, because of the overhead and time consumed around it.

One of the most important tasks of a developer is to make trade-offs. They occur wherever you look in your every day life. It is a highly important step to realize and accept this. And it is important to hone that skill. You need to open your mind for new technology and techniques, learn and try them wherever you can. But then you need to step back, analyze the current situation and then find the best trade-off between all possible approaches.
tagged: developer life opinion technology tradeoff decision

Link: http://qafoo.com/blog/075_developers_life_trade_off.html

Mikkel Høgh:
Drupal is still a gated community
May 25, 2015 @ 10:16:42

In a recent post to his site Mikkel Høgh makes the suggestion that Drupal is still a gated community, mostly as it relates to the process around the "Project Applications" process.

One of the things the Drupal community prides itself on, is how open the community is. And that is generally true, but there's one exception. And that is the Kafkaesque horror-show we subject any newcomers that would like to publish their code on Drupal.org to. It goes by the name of “Project Applications“. I know several people who've hit this wall when trying to contribute code. It's not uncommon to wait several months to get someone to review your code. And when it does happen, people are often rejected for tiny code style issues, like not ending their comments with a period or similar.

He talks about other factors involving reviews and delays that can also cause authors to abandon their work and feel "unwelcome and unappreciated". He mentions the "review bonus" system and how it's used to encourage participation (or "more hoops" as he puts it) from other authors. He notes that this situation mostly relates to those new to the tool and community and suggests that it just doesn't work (and really is unnecessary). He ends the post with a call to "end the madness" and move to a standardized role that would allow developers to publish without pushing people away and making them feel unwelcome.

tagged: opinion drupal walledgarden project applications review delay contribution

Link: http://mikkel.hoegh.org/2015/05/14/drupal-is-still-a-gated-community/