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

Matthew Turland:
On Remaining Employable
Dec 09, 2016 @ 10:49:40

Matthew Turland has an interesting new post to his site sharing some of his own thoughts on how you can stay employable as a developer with some great suggestions both on the technical and personal side.

Following my post on changing jobs, I communicated with a friend who’s in the market for a job. His circumstances inspired me to write a post for a slightly difference audience. So, here’s some advice on remaining employable as a developer.

His suggestions touch on topics like:

  • length of employment at one company (sometimes based on the type of company)
  • the balance between being a generalist and fitting only into a niche role
  • constant learning (and spending time "off the clock" doing professional development)
  • networking with other people

There's a lot of good content in the post so be sure to give it a read, especially if you're a developer that's been in the same role for a while...

tagged: opinion employable advice tips personal technical

Link: http://matthewturland.com/2016/12/07/on-remaining-employable/

JoliCode.com Blog:
The journey of writing an API Client with PHP and some wise advices
Aug 25, 2016 @ 10:49:01

On the JoliCode.com blog there's a post sharing the experience of writing an API client with PHP including some advice to those out there considering doing the same.

My (love-)story with Docker started in December 2013, after having lost a 2 years long battle against Chef. I had been attracted to Docker for a couple of months, and I finally made the switch the day when I learned that it was built on a REST API. This meant that I could control all my infrastructure from PHP, which is the language I’m most partial to.

After some research, I found the library docker-php built by ubermuda, but, like all the things around Docker at that time, there was only a very limited support of the API. Like any decent developer (yes, it’s a troll), I started to write pull requests to fulfill my needs, and it was both the greatest and the worst thing that happened to me.

The post starts off with a brief history of PHP libraries working with HTTP requests (and the difficulties he had with Guzzle). This includes the fast pace that the library was changing at the time, making it difficult to keep the code maintained. He took a "step back" and decided to look more into HTTPlug and some changes to help bring it up to date. With that choice made, he got into the automation portion and using it work with the Docker API. He talks about some of the other technologies and tools he investigated along the way including Jane for working with JSON message schemas.

Maintaining an open source library is hard and takes time. However, these last years made me realize that we can control it, by moving features into other projects, trust people behind it, and by reducing the feature sets.
tagged: api client library advice http httplug jane json schema

Link: https://jolicode.com/blog/the-journey-of-writing-an-api-client-with-php-and-some-wise-advices

QaFoo Blog:
Common Bottlenecks in Performance Tests
Apr 22, 2016 @ 11:24:46

On the QaFoo blog there's a post sharing some of what they've learned about the common bottlenecks in performance testing and some things you can to do determine the issues in your own tests.

Most developers by now internalized that we should not invest time in optimizations before we know what happens exactly. [...] This is true for optimizations in your PHP code but also for optimizations regarding your infrastructure. We should measure before we try to optimize and waste time. When it comes to the assumed performance problems in your system architecture most people guess the root cause will be the database. This might be true but in most projects we put under load it proved to be false.

So, how can we figure out where the problems are located in our stack?

They talk about some common testing practices using basic tools (like ab and siege) and having them perform common operations on the application. They then talk about testing for high load, monitoring the stack for the impact and a few tools you can use to gather statistics. They end the post with a quick mention that, despite popular opinion, the issue isn't always the database's fault. Sometimes other technology that's in play - like file locking issues or processing for server-side includes - and other things that may only show up under high load.

tagged: common bottleneck performance test advice server monitor tool

Link: https://qafoo.com/blog/082_common_bottlenecks_in_performance_tests.html

Joe Ferguson:
User Group Advice
Mar 17, 2016 @ 12:38:36

If you've been thinking about starting a local technology user group in your area but have been looking for some guidance, you should definitely check out this recent post from Joe Ferguson with some good "dos" and "don'ts" around groups and organization.

When I introduce myself before I give a talk at a conference or a user group I mention I am a user group leader and very passionate about community. I happily receive questions from people starting new user groups or reviving old groups.

I wanted to share a recent response I sent to someone today who was asking for advice about their meetup group: Congrats on jumping into the world of running a UG. A lot of this is “in my experience” so your milage may vary

He starts with the "dos" (like keeping it small to start and making meetings consistent) and "don'ts" (not to worry about sponsors and making the talks "conference level" every month). He also includes an interesting section about "protecting" your user group, preventing things like over-zealous recruiters from coming in and giving people a bad impression of the group. He also links to lots of other resources you can read and participate in to make you a more effective user group leader.

tagged: usergroup advice organize do dont protect resources

Link: https://www.joeferguson.me/user-group-advice/

Paragon Initiative:
How to Safely Store a Password in 2016
Feb 16, 2016 @ 11:19:46

On the Paragon Initiative site they've posted a new article showing you how to safely store a password (in 2016) that discusses both the concepts around good password hashing and how to do it in several languages (including PHP).

The Problem: You want people to be able to create a unique user account, with a password, which they will use to access your application. How can you safely implement this feature?

He advises using libsodium for some of the best protection but points out that it's not widely supported yet. An alternative that is, however, is bcrypt (including PHP. He shows how to hash a password in:

  • PHP
  • Java
  • C# (.NET)
  • Ruby
  • Python
  • Node.js

Each of them is basically a one-line kind of change and doesn't require much effort on the developer's part to implement. He ends the post with a few FAQs around Argon2, PBKDF2 and why he's chosen to advise bcrypt over scrypt.

tagged: password hash libsodium advice bcrypt language tutorial

Link: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016

Alejandro Celaya:
How to properly implement persistent login
Feb 10, 2016 @ 10:55:37

In his latest post to his site Alejandro Celaya shares some suggestions about how to make a good, safe persistent login feature for your application. This is usually referred to as the "remember me" handling and is widely used to help improve the overall user experience.

I'm sure you are familiar with those "remember me" checkboxes in login forms. They are a common way to allow a user to keep his/her session in a web application for an extended period of time when he is in a trusted computer.

One could think that it is a small and easy-to-implement feature, but it has indeed a lot of considerations. [...] In this article I’m not going to show you how to implement a persistent login in one or another programming language, but what are the good practices that should be followed when you implement it in the way you want.

He starts off with some thoughts about the wrong way to handle the persistent login (like just making a long-life cookie) and what some of the consequences could be. Instead he suggests using a cookie (with a random generated token) that's long running, maybe 2 weeks. The difference here is that this token is then refreshed once the token is validated and reset. This reduces the risk of an older token being used on another source too. He also shares some other security concerns to think about in this setup including the use of one-time tokens, potential multiple persistent sessions and when it might be good to re-prompt for the password.

tagged: persistent login security rememberme implementation advice options

Link: http://blog.alejandrocelaya.com/2016/02/09/how-to-properly-implement-persistent-login/

Fixing Spaghetti: How to Work With Legacy Code
Jan 27, 2016 @ 12:09:38

On the Ethode.com blog they've shared some hints for working with legacy code to help you more effectively refactor your way out of the "spaghetti code" you might have right now. These are more general tips and aren't really PHP (or even really web application) specific but they're a good starting place for any refactoring effort.

Legacy code is software that generates value for a business but is difficult for developers to change. [...] The longer this goes on, the more frustrated customers get with the software due to quirky defects, bad user experiences and long lead times for changes. Developers are afraid to make changes due to the "Jenga effect" -- as one piece of code is changed or removed, it often leads to new defects being introduced in the system in sometimes seemingly unrelated places. This compounds into what is known as "technical debt".

They continue on talking about what "spaghetti code" is, how it can happen and some of the warning signs you can use to determine just how far down the rabbit hole you and your code are. They talk about "The Big Rewrite" everyone dreams of but points out that this is almost never a practical path. Instead they offer some good things you can do to help fix the problem: quarantining the problem, refactoring relentlessly, keeping it simple and "doing the dishes" as you go rather than letting the changes pile up.

tagged: legacy code refactor opinion advice fix software development

Link: http://www.ethode.com/blog/fixing-spaghetti-how-to-work-with-legacy-code

Jani Hartikainen:
Why is fixing bugs so slow? (and how to make it faster)
Dec 17, 2015 @ 12:06:32

On his CodeUptopia blog Jani Hartikainen has posted a great article with some of his thoughts about why fixing bugs is so slow and includes a few suggestions on how to make it happen faster and streamline the process for the future.

Have you ever wondered why sometimes fixing bugs seems to take much longer than it should? When you finally find the problem, it turns out all you need is one small change. Yet, it took a lot of time to find what’s going on. This happens to me more often than I’d like.

[...] Why is it that sometimes fixing bugs takes a lot of work even when the problem is simple, and other times, it’s really quick to fix the problem – maybe even when it isn’t so trivial? Is there something we can learn from the bugs that are easy to fix, so that we could spend less time fixing bugs in general?

He starts off by describing a typical bug fixing process after the initial discovery and reporting of the issue down to the actual fix being deployed. He then breaks down each of these six steps and provides more context around them:

  • Understanding the problem
  • Reproducing the bug
  • Finding the problematic piece of code
  • Identifying the root cause
  • Fixing the bug
  • Ensuring the bug is fixed

He then goes back and talks about the pain points in this typical process citing things like a lack of good information around the bug and the time constraints that often come with the "time to fix" allowance. He makes some suggestions about how to gather better information around the issue before the fix begins and points to effective logging as one possible source. He also talks about how unit testing can help verify the bug is actually fixed and help to prevent and locate future issues.

tagged: bugfix speed slow opinion process unittest faster advice

Link: http://codeutopia.net/blog/2015/12/16/why-is-fixing-bugs-so-slow-and-how-to-make-it-faster/

Paragon Blog:
Building Secure Web Applications in PHP
Sep 21, 2015 @ 16:15:56

The Paragon Initiative has posted an article to their blog talking about how to build secure applications in PHP. Rather than try to get into the specifics of specific vulnerabilities, they stay relatively high level and stick with concepts to keep in mind and steps you can follow to ensure your development practices are secure.

Whether you're planning the development of a brand new application or trying to prevent legacy code from causing a costly data breach, if you're going to be writing PHP, where should you begin? That is the question we will attempt to answer, in detail.

The article starts with an "easy way out" for those that don't feel like they know enough or just don't have the resources they need: hire consultants. With that out of the way, the article mentions two root causes for insecure apps: lack of knowledge about security and bad development habits. They then get into some suggestions about how you can learn to understand and prevent vulnerabilities in your own applications. They focus in on a few key places for PHP developers to pay attention to, complete with some charts showing the parts of the flow. The post ends with some advice on what do to if your site is compromised anyway and how to move forward.

tagged: secure application advice common issues developer

Link: https://paragonie.com/blog/2015/09/building-secure-web-applications-in-php

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/