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

Community News:
Rogue Wave Software Acquires Zend
Oct 06, 2015 @ 14:57:39

Zend has posted a new press release about their acquisition by Rogue Wave Software, a company specializing in tools and services "making it easy to write, test, and run complex code."

Rogue Wave Software announced today that it has acquired Zend Technologies, the leader in end-to-end PHP web and mobile application development and deployment solutions. With 50 percent of the web workload running on PHP, including Magento, Drupal, and WordPress, Zend products drive PHP in the enterprise, from code creation through production deployment.

[...] “Today’s announcement expands Rogue Wave into PHP web and mobile application development, underscoring our goal to make developers heroes by accelerating their ability to create great code,” said Brian Pierce, CEO of Rogue Wave.

It's something that's definitely taken the PHP community by surprise and left many wondering what the future of the language my hold with Zend having been such a critical part of the engine that parses and executes the PHP code we write every day. Chris Tankersly has already shared some of his thoughts on the matter and why, as he puts it, this "doesn't matter" to PHP and it's community as much as some are thinking.

tagged: zend acquire roguewavesoftware roguewave company software tools code

Link: http://www.zend.com/en/resources/news-and-events/newsroom/press/3683_rogue-wave-software-acquires-enterprise-php-leader-zend-acquisition-broadens-enterprise-strength-across-top-five-development-languages

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/

Christian Scheb:
Introducing Tombstones for PHP
Sep 17, 2015 @ 12:49:23

Christian Scheb has posted about an interesting idea in this article on his site - creating "tombstones" in your application to help you determine what code in your application is "dead".

Earlier this year I took over that project at my new company. [...] The repository was cluttered by many files, that could assumed to be dead code. Unfortunately, you never know. [...] The mission was clear: Cleaning up the project, without breaking things.

[...] I searched the web and came across that interesting concept of tombstones. If you haven’t heard of tombstones yet, I highly recommend this article and watching the video of David Schnepper’s ignite talk. A tombstone is basically an executable marker in your code (in the PHP world: a function call), which is placed in fragments of code, that you’ve assumed to be dead. Then, everything is deployed to production and, when a tombstone is invoked, it writes some data to a log. After a while, the logs will enable you to identify dead and undead code (called “Vampires”) in your project.

Not finding a good tool to help with this in an existing codebase, he created a library that makes it simpler to both mark the "tombstones" in your code and another to analyze the results. He includes an example of what the report might look like, showing both the used and unused bits of code where the tombstone code was placed.

tagged: tombstones dead code library analyzer marker

Link: http://www.christianscheb.de/archives/717

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/

Check Point Blog:
Finding Vulnerabilities in Core WordPress: A Bug Hunter’s Trilogy, Part I
Aug 06, 2015 @ 11:44:14

The Check Point blog has posted the first part of a series from one of their vulnerability researchers about finding security vulnerabilities in the core WordPress code (and some of the results along with CVE numbers).

In this series of blog posts, Check Point vulnerability researcher Netanel Rubin tells a story in three acts – describing his long path of discovered flaws and vulnerabilities in core WordPress, leading him from a read-only ‘Subscriber’ user, through creating, editing and deleting posts, and all the way to performing SQL injection and persistent XSS attacks on 20% of the popular web.

In this first part he focuses on the concept of "identity" in a WordPress application. He focused on the "roles and capabilities" functionality to find bypass methods in operations like editing and adding new posts. As he works through his process, code is included from the WordPress core showing where the issue(s) lie and what would be needed to exploit the issue.

tagged: bug hunt wordpress vulnerability core code part1 series checkpoint

Link: http://blog.checkpoint.com/2015/08/04/wordpress-vulnerabilities-1/

Dylan Bridgman:
Writing highly readable code
Jul 30, 2015 @ 12:29:55

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

  • the overall style of the code
  • the structure of the application (directories, libraries used, etc)
  • naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

tagged: write readable code tips style structure naming convention comments

Link: https://medium.com/@dylanbr/writing-highly-readable-code-94da94d5d636

Rob Allen:
Checking your code for PSR-2
Jul 28, 2015 @ 08:17:20

Rob Allen has posted a guide showing you how to make your code PSR-2 compliant with the help of some handy tools, both in and out of your editor/IDE.

Most of the projects that I work on follow the PSR-2 coding style guidelines. I prefer to ensure that my PRs pass before Travis or Jenkins tells me, so let's look at how to run PSR-2 checks locally.

He looks at three different methods - not the only ones out there but three quick to implement ones:

  • Using the PSR-2 sniffs for PHP_CodeSniffer
  • Automating the checks with Phing
  • Editor integration (he shows VIM and Sublime Text)

There's links to the tools mentioned here and screenshots/configuration information showing how to get it set up too.

tagged: psr2 code style check phpcodesniffer phing editor vim sublimetext

Link: http://akrabat.com/checking-your-code-for-psr-2/

Acquia Blog:
Quick Tips for Writing Object Oriented Code in PHP
Jul 13, 2015 @ 10:58:14

On the Acquia blog Adam Weingarten has shared some tips for writing good (and modern) object-oriented code in PHP:

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

His tips touch on things like:

  • Using a code structure that can be autoloaded via PSR-4
  • Namespacing your classes
  • Working with types and type hinting
  • Using docblock comments for autocomplete in IDEs

There's also a few other quick topics he finishes the post out with: the lack of enums in PHP, working with associative arrays, no functional overloading and assigning responsibility to classes.

tagged: oop tips objectoriented code modern psr4 namespace typing docblock missing

Link: https://www.acquia.com/blog/quick-tips-for-writing-object-oriented-code-in-php/09/07/2015/3285651

SitePoint PHP Blog:
4 Best Chart Generation Options with PHP Components
Jun 26, 2015 @ 08:30:29

The SitePoint PHP blog has a new article posted sharing four of the best charting libraries they've seen for use in your PHP applications. Options include both server and client side tools, making finding one for your situation easier.

Data is everywhere around us, but it is boring to deal with raw data alone. That’s where visualization comes into the picture. [...] So, if you are dealing with data and are not already using some kind of charting component, there is a good chance that you are going to need one soon. That’s the reason I decided to make a list of libraries that will make the task of visualizing data easier for you.

He starts with a brief comparison of the server side versus client side options, pointing out some high level advantages and disadvantages of each. He then gets into each of the libraries, giving an overview, an output example and some sample code to get you started:

  • Google Charts (Client Side)
  • FusionCharts (Client Side)
  • pChart (Server Side)
  • ChartLogix PHP Graphs (Server Side)

He ends with a wrapup of the options and links to two other possibilities you could also evaluate to find the best fit.

tagged: chart generation option component top4 list example output code

Link: http://www.sitepoint.com/4-best-chart-generation-options-php-components/