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

SitePoint PHP Blog:
What Are the Workflows of Prominent PHP Community Members?
Aug 11, 2017 @ 12:19:52

On the SitePoint PHP blog there's a new post from author Shahroze Nawaz that shares the results of a survey performed with several "prominent PHP community members" about their usual development workflows.

Workflow refers to both the process and the tools that are used in this process. Almost every developer comes up with a process of creating and finalizing the project deliverables. This process is implemented through a set of tools that the developer comes up with through trial and error. Once a workflow has been perfected, developers follow the process almost religiously because of a simple reason: following workflows reduces most of the management problems that developers have to face during a project.

[...] Here are some of the PHP ecosystem’s most popular developers and designers, and their tools and/or workflows. Note that these workflows will by no means be comprehensive, but even mentions of tools used by some of the more prominent members of our community should be enough to warrant checking them out.

PHP community members on the list include:

  • Taylor Otwell
  • Phil Sturgeon
  • Nicolas Grekas
  • Manuel Lemos
  • Josh Lockhart
  • Cal Evans
  • Kat Zien
  • Laura Elizabeth

Each person on the list describes their tools of choice for both development related tasks and how they keep organized. There's plenty of links to these tools and services too for you to check them out on your own.

tagged: workflow community member survey tools practices

Link: https://www.sitepoint.com/workflows-prominent-community-members/

SitePoint PHP Blog:
Poka Yoke – Saving Projects with Hyper-Defensive Programming
Jun 29, 2017 @ 10:55:11

The SitePoint PHP blog has a new tutorial posted that introduces the idea of "Poka Yoke" - basically defensive programming - and how to apply it in your own development processes.

When working in a medium to large team on the same codebase, it can sometimes become hard to understand each other’s code and how to use it. [...] It can be quite hard to remember how particular classes were intended to work, both on their own and in combination with each other. At that point, it becomes easy to accidentally introduce side effects or bugs without realizing it.

These mistakes might get caught in quality assurance, but there’s a realistic chance they might slip through. And even if they get caught, it can take a lot of time to send the code back and get it fixed. So how can we prevent this? Enter “Poka Yoke”.

The article then introduces the basic ideas of "poka yoke" and the two main parts: mistake prevention and mistake detection. It then gets more practical and suggests some PHP-specific things that can be done to prevent mistakes such as:

  • the use of type declarations
  • using value objects
  • making use of effective validation
  • returning null objects

For each there's a brief explaination and some sample code to help make the example more practical.

tagged: pokayoke project defensive programming practices tutorial

Link: https://www.sitepoint.com/poka-yoke-saving-projects-with-hyper-defensive-programming/

35 programming habits that make your code smell
Apr 25, 2017 @ 11:11:47

The Tech Beacon site has posted a list of thirty-five programming habits that make your code "smell", little things that you might do every day without knowing they could be causing issues with the long term maintenance of your code.

Bad habits are hard to break and even harder if you don't realize that what you're doing is undermining your work. If you know but don't care—that would be the worst. But you're here, aren't you?

As a programmer, I've seen a lot of poor practices, not just around code, but also around teamwork skills. I've been guilty of practicing many of these bad habits myself. Here are my top 35 bad programming habits, organized into four categories: code organization, teamwork, writing code, and testing and maintenance.

They've broken up the bad habits into different categories to make it a bit easier to consume:

  • Code organization
  • Teamwork
  • Writing code
  • Testing and maintenance

I think just about any developer out there as, at one time or another, fallen into the trap of one or more of these bad habits.

tagged: thirtyfive habits bad practices developer programming list

Link: https://techbeacon.com/35-bad-programming-habits-make-your-code-smell

DaedTech Blog:
Avoid these Things When Logging from Your Application
Dec 06, 2016 @ 11:53:48

On the DaedTech blog Erik Dietrich has written up a list of a few things he suggests avoiding when using logging functionality in your application. The suggestions range from the actual contents of the message out to some logging best practices.

It seems almost strange to talk about avoiding things while logging. After all, logging is your last line of defense or your salvation in many cases. [...] Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems. You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it. You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.

So what are these problems, and how to avoid them? Let’s take a look at some things that can come back to bite you.

He points out the following (common) bad practices he has seen during his time developing:

  • Forgetting Context
  • Cryptic Codes
  • Spamming the Log File
  • Unsafe Logging Calls
  • Mixing Application Logic with Logging

He ends the post with a suggestion of "sensible logging" - capturing as much meaningful information as possible while not overdoing it. Logs can be a powerful ally when hunting down an issue or trying to provide documentation of a security issue. Log wisely, log on purpose.

tagged: logging practices recommendation avoid list

Link: http://www.daedtech.com/avoid-things-logging-application/

Andreas Creten:
Does code need to be perfect?
Nov 11, 2016 @ 09:55:57

On his Medium.com blog Andreas Creten has written up a post that tries to answer the question "Does code need to be perfect?" As developers we have a drive to take pride in our work and want it to be the best code possible. However, that can lead to some bad practices...

In the past months I have asked myself a lot why we always strive to write perfect code. Picking up coding again for an internal project made me realise our team (and probably a large part of the rest of the software development world) spend a lot of time on writing perfectly formatted, ordered, patterned and tested code. But is this really necessary?

[...] The engineers want to write perfect code using the latest techniques, make sure that the code is well documented so they can fully understand how everything works and that it has tests so they can easily update things later. Product owners on the other hand just want things to be done, fast and cheap, so they can ship new features or convince new clients. How can you make these conflicting views work together?

He offers a few different suggestions for those developers wanting to craft the perfect codebase including coding for "now" not the future and the fact that "perfect code" just doesn't exist. He offers some suggestions for dealing with that "non-perfect code" you come across in your codebase, when starting from scratch makes sense and thinking about how "perfect" the code needs to be at the outset.

tagged: perfect code opinion development practices

Link: https://medium.com/we-are-madewithlove/does-code-need-to-be-perfect-a53f36ad7163#.jdqre42fu

Peter Petermann:
Composer – What You Should Know
Jul 26, 2016 @ 12:56:21

Peter Petermann has shared a few of his thoughts about right and wrong things to do when using Composer in your PHP-based applications. He offers suggestions based on some of the more wide-spread (but wrong, in his opinion) practices he's seen in several projects.

Last year I wrote a piece called “a few thoughts about composer and how people use it“. In that post I had a list of things which are problematic about how composer is used. That post got widely recognized, linked an visited, but in general those issues still exist.

However lately I’ve had even more people asking questions (either on related forums, irc or even irl) about problems that stem from issue number 2: people are using composer as an installer (and sometimes Number 3 because of Number 2). In that Post I already gave a quick opinion on how workflows with composer should look like, In this post I’ll try to give a few more pointers on how to use composer without creating a mess.

He then breaks up the remainder of the post into various practices he's seen and calling out developers for doing including:

  • starting a project vs installing
  • globally installed composer packages
  • tagging and building

With each of his points he makes suggestions about what's wrong about the practice as well as some suggestions about how things could be done better.

tagged: composer opinion bad practices suggestion correct

Link: https://devedge.wordpress.com/2016/07/23/composer-what-you-should-know/

Ted Blackman:
Lug-Nut Driven Development (LuDDite)
Mar 21, 2016 @ 11:53:27

In his post on his Medium.com site Ted Blackman looks at something he calls "Lug-nut driven development" (or, shortened LuDDite). He breaks it down into a few different suggestions including "build the whole thing badly" out to "automate stop and start".

These are practices that I’ve applauded myself for doing at the beginning of some projects, and kicked myself for not doing early enough in other projects.

The full list suggests things like:

  • Building a system that goes through the whole flow first (not perfect) then come back and refine
  • Testing as you go instead of coming back at the end and retrofitting them
  • Log everything you can then cut back and refine
  • Plan out the error handling before hand to help make it consistent
  • Be able to "stop" and "start" the system easily

While not all of these are specific to web applications there's some definite helpful advice in here, especially to those starting out on new projects.

tagged: lignut development luddite software suggestion practices

Link: https://medium.com/@belisarius222/how-to-start-a-software-project-ad51373c1510#.nfx206q5v

Book Review - Modern PHP: New Features and Good Practices
Mar 24, 2015 @ 11:29:28

On Slashdot today Michael Ross as posted a book review of Josh Lockhart's recently released O'Reilly book "Modern PHP".

In recent years, JavaScript has enjoyed a dramatic renaissance as it has been transformed from a browser scripting tool primarily used for special effects and form validation on web pages, to a substantial client-side programming language. Similarly, on the server side, after years as the target of criticism, the PHP computer programming language is seeing a revival, partly due to the addition of new capabilities, such as namespaces, traits, generators, closures, and components, among other improvements. PHP enthusiasts and detractors alike can learn more about these changes from the book Modern PHP: New Features and Good Practices, authored by Josh Lockhart.

In the rest of the review Michael provides an overview of the topics covered in the book and how it's divided up. He then covers each of these three sections, commenting on the contents and making a few recommendations for those not immediately familiar with the topics. He does point out that he felt there was some critical information missing on some topics that "would allow one to begin immediately applying that technique or resource to one's own coding." Overall, though, he found the book a good resource and recommends it to those looking for a source to learn about new trends and tools in PHP.

tagged: book review modernphp joshlockhart features practices

Link: http://books.slashdot.org/story/15/03/22/1447230/modern-php-new-features-and-good-practices

Worst practices
Sep 04, 2013 @ 11:35:52

In this recent post to Reddit.com, people have been sharing some of the "worst practices" they've seen during their PHP development (or may even be guilty of).

For shits and giggles some colleagues and I are trying to write the crappiest PHP script we can think of, using as many bad practices as we can find. Alas, it's much harder then we thought, because we all have been trained to not do stupid stuff.

Things on the list so far include:

  • Multiple class definitions in a single file
  • Saving passwords unhashed and unencrypted in a database
  • Using a global variable inside a class to get a database connection
  • One letter variables
  • Pointlessly setting the signup method to being static
  • Using GET or POST vars directly from user input
  • Mixing HTML and PHP like there's no tomorrow.
  • make liberal use of extract() after running 'SELECT *'
  • Define a custom exception class for each class and only throw it from that class.
  • Make sure your DB connection is a singleton.
  • Throw ugly constants everywhere

What are some of the worst things you've seen? Share them here.

tagged: worst practices opinion examples list

Link: http://www.reddit.com/r/PHP/comments/1lpgqk/worst_practices

Matt Frost:
Agent of Change: Part 2 Presentation
Feb 05, 2013 @ 09:20:35

Following up on his previous post about being an "agent of change" in your organization (work, open source project, etc) Matt Frost has posted his second part of the series focusing on the presentation of your ideas.

In Part 2 we're going to talk about presentation of the pitch you put together for this change. It's important that your pitch be well researched and in some regards provable, as the Agent of Change the responsibility lies with you to prove the value of your idea. As we touched on in Part 1, a well thought out plan is going to go a long way in breaking down the barriers that make change difficult to take hold.

He makes a strong point that you need to identify the problem you're trying to solve (and what solution you're wanting to propose) clearly before trying to present it to a listening audience. He recommends quantifying your solution in terms everyone can understand like "hours of work" or cost. He recommends coming up with a short "elevator pitch" version to entice and the longer version to fill in the gaps.

You've got slides, documentation, statistics and loads of other good information that is going to benefit your development process, sales people in particular are looking for that jewel that helps set your organization apart; you've got that jewel!
tagged: agent change series practices development presentation