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

SitePoint PHP Blog:
Containerized PHP Development Environments with Vagga
Apr 13, 2016 @ 10:19:07

The SitePoint PHP blog recently posted a tutorial showing you how to use Vagga to "containerize" your development environment and help prevent some of the common incompatibility issues that come with setting up/configuring them.

It happens to all of us once in a while. We clone a project, and then we try to run it. However, something doesn’t work. It may be our version of NGINX or Apache. It might be that npm isn’t doing something right. Maybe the project needs an extension, and we don’t have it installed, and now we have to build the extension from source because the dependency does not exist in the repositories for our distribution. No matter the reason, the more complex the setup, the higher the probability of failure.

He sets up a scene where a developer, the primary on a certain product/project is out of the loop and changes need to be made. He steps through the problems another developer could have with setting up a similar environment and, unfortunately, the issues that come from it. Enter Vagga a tool that helps to set up development environments with containers, handle dependencies and run simple processes.

The tutorial then introduces the tool, helps you get it installed and shows how to create a simple environment. Their example uses just Nginx and PHP containers along with mounted volumes, custom configurations and simple command execution to automagically build the environment exactly as needed.

tagged: vagga container development environment docker tutorial

Link: http://www.sitepoint.com/containerized-php-development-environments-with-vagga/

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

Toptal.com:
The Art of War Applied To Software Development
Feb 19, 2016 @ 11:17:35

On the Toptal blog there's an interesting post where author Jose F. Maldonado takes the infamous book "The Art of War" and applies several principles to programming and development. He obviously doesn't go through the entire Art of War and relates each section, but he does pick out some good bits and makes some interesting parallels.

If you work in the software industry, it’s likely that you have heard about the divide and conquer design paradigm, which basically consists of recursively splitting a problem into two or more sub-problems (divide), until these become simple enough to be solved directly (conquer).

[...] However, the divide and conquer rule is not the only political strategy that can be applied to software development. Although politics and warfare have little to do with software development, just like politicians and generals, developers must lead subordinates, coordinate efforts between teams, find the best strategies to resolve problems, and administer resources. [...] Detailed below, you will a find a brief list of basic tactics and tips explained in the Art of War. They can probably be applied to your job in the software industry, or any of a number of other industries.

Included in his list of Art of War excerpts are topics like:

  • Time Is Crucial In Any Campaign
  • No Leadership, No Results
  • Teamwork And Motivation
  • Thinking Outside The Box

For each topic there's a reference to a chapter/paragraph location in the book, quotes from that section and his own thoughts on how this relates back to software development.

tagged: artofwar software development parallels opinion programming

Link: http://www.toptal.com/agile/art-of-war-software-development

SitePoint PHP Blog:
Clean Code Architecture and Test Driven Development in PHP
Feb 09, 2016 @ 09:13:28

The SitePoint PHP blog has an article posted by Vitalij Mik showing you how to merge the concepts of "clean code architecture" and test-driven development to make solid, maintainable code. The ideals of the "clean code architecture" were first proposed by Robert C. Martin in this post on the 8thlight blog.

The idea was to create an architecture which is independent of any external agency. Your business logic should not be coupled to a framework, a database, or to the web itself. [...] Frameworks will continue to change and evolve. With composer, it is easy to install and replace packages, but it is also easy to abandon a package (composer even has the option to mark a package as abandoned), so it is easy to make “the wrong choice”.

In this tutorial, I will show you how we can implement the Clean Code Architecture in PHP, in order to be in control of our own logic, without being dependent on external providers, but while still using them. We will create a simple guestbook application.

He starts with a first test, evaluating that a list of entries for the guestbook is empty. The code shows the "fakes" for the different object types Uncle Bob recommended in his article and how it fails because none of them exist yet. He extends this with a "can see entries" test and then starts in on the "use case" class to start making the test pass. He updates the case to pull in entries from the repository, another external dependency created later in the tutorial. He then goes through creating the classes for the "fakes" in the test and refactoring the test based on some of his changes during their development. In the remainder of the post he talks about the independence of the current setup and how to add in pagination functionality on the entries objects.

tagged: cleancode architecture testdriven development tdd tutorial entity repository decouple

Link: http://www.sitepoint.com/clean-code-architecture-and-test-driven-development-in-php/

SitePoint PHP Blog:
9 Development Workflow Upgrades You Should Know About
Feb 04, 2016 @ 11:39:10

On the SitePoint PHP blog editor Bruno Skvorc shares 9 development workflow upgrades that can help to make you a more efficient (and informed) developer. This is a list of handy tools and changes you can make to current software to help make you more productive.

Every once in a while I run into a tool or plugin so useful I can’t not add it to my arsenal. I usually shout out tweets and try to spread the word that way, but this time I believe I’ve got such a neat (and somewhat random) collection of productivity boosting entries, they deserve a collective article.

Included in his list of helpful tools and tips are things like:

  • git-fresh
  • [Composer changelogs](Composer changelogs)
  • Changing PhpStorm's configuration for faster rendering
  • Parallel downloads [with Composer](Composer parallel downloads)

There's also something he's called the "comfort collection" that can help you and your body feel less of the pains usually associated with long hours in front of the keyboard.

tagged: workflow upgrades development tools configuration tips comfort

Link: http://www.sitepoint.com/9-development-workflow-upgrades-you-should-know-about/

TutsPlus.com:
Test-Driven Development With Laravel & Doctrine
Feb 02, 2016 @ 13:39:47

On the TutsPlus.com site they've posted a new tutorial showing you how to do test-driven development with Laravel and Doctrine, making use of Doctrine's own testing functionality inside of a Laravel application for PHPUnit based unit testing.

As a PHP developer, you may use the Test-Driven Development (TDD) technique to develop your software by writing tests. Typically, TDD will divide each task of the development into individual units. A test is then written to ensure that the unit behaves as expected. [...] TDD verifies that the code does what you expect it to do. If something goes wrong, there are only a few lines of code to recheck. Mistakes are easy to find and fix. In TDD, the test focuses on the behavior, not the implementation. TDD provides proven code that has been tested, designed, and coded.

[...] PHPUnit is the de-facto standard for unit testing PHP. It’s essentially a framework for writing tests and providing the tools that you will need to run tests and analyze the results. PHPUnit derives its structure and functionality from Kent Beck’s SUnit.

He briefly talks about some of the assertions that PHPUnit has to offer before getting into the support that Laravel includes and how to configure it so Doctrine can work with your database. He then talks about Doctrine, briefly introducing the popular database abstraction tool and how to integrate it with a Laravel application. From there he starts in on the tests themselves, showing code that uses fixture data to create several tests for Post and Comment data.

tagged: testdriven development tdd laravel doctrine fixture tutorial

Link: http://code.tutsplus.com/tutorials/test-driven-development-with-laravel-doctrine--cms-25563

Zend Developer Zone:
Z-Ray Tip #4: Getting Rid of It!
Jan 29, 2016 @ 10:44:14

On the Zend Developer Zone they've posted the fourth part in their series of tips around using the Z-Ray profiling tool in your PHP applications. In this fourth tip they show you how to "get rid of it" in certain parts of your application.

Well, while Z-Ray is a great friend to have when developing your apps, there are just some parties you don’t want it to show up at. You might be using PHP scripts for accessing static pages. Or, you might not want Z-Ray to be displayed for one specific request. In production, you most definitely don’t want Z-Ray popping up for users using your app!

There are numerous ways to disable Z-Ray both in development and in production to make sure your development workflow is not interrupted and your live apps are not affected. Here are a few of them.

They include a few different ways to disable the tool including the use of a function call in the code (zray_disable), using a header in the HTTP request and, naturally, from the Z-Ray toolbar itself. They also talk about setting it up to be removed for production in one of two modes, either selective (only showing for certain requests) and completely disabled.

tagged: zray tip disable development production api get header selective

Link: http://devzone.zend.com/7149/z-ray-tip-4-getting-rid-of-it/

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

Adam Wathan:
Test Driven Laravel from Scratch
Jan 15, 2016 @ 09:22:51

Adam Wathan recently presented a talk at ZendCon 2015 about test-driven Laravel development. As the talk wasn't recorded he put together a condensed version of it and has posted it to his site.

This talk covers some common obstacles people run into when trying to get started with test driving real applications, including: what’s the very first test I should write, [...] how do I test routes, [and] should I start at the unit level or the acceptance level?

The video is embedded in the post but you can also watch it separately over on Vimeo. Adam also has some other videos for those interested in things like social logins with Laravel 5, polymorphism in the database layer and refactoring loops and conditionals.

tagged: video testdriven development laravel zendcon15 screencast

Link: http://adamwathan.me/2016/01/11/test-driven-laravel-from-scratch/

Procore Blog:
Evolution of Software Applications
Jan 12, 2016 @ 11:55:19

On the Procore blog there's an excellent article covering their thoughts on the evolution of software applications and the different stages they go through during their development.

If you develop software long enough, you notice patterns. One pattern that isn’t talked about enough is how systems evolve over time.

The software industry is so focused on the flavor of the week that we lose perspective. Most of what is “invented” today was created decades ago. Most problems we face today were solved by someone else.

Software developers don’t have a good understanding of our own history. In the spirit of that, I present to you my take on how software tends to evolve and why.

He starts by defining a term that is used through the rest of the article, software gravity, and illustrates how it relates to development time and complexity. He then gets into describing the seven stages of software evolution as he sees them (starting with zero, naturally):

  • Stage 0: Humans, Paper, and Spreadsheets
  • Stage 1: Simple Script
  • Stage 2: Pile Of Files
  • Stage 3: The Framework
  • Stage 4: Beyond The Framework
  • Stage 5: Modularization
  • Stage 6: Network System

For each of the points he provides an overview of what the application might be like at this stage and what levels the complexity/gravity are at. The post ends by asking about a "Stage 7" and if it even exists, suggesting that it might be an even further abstraction from previous steps.

tagged: evolution software application gravity complexity development time stages

Link: http://devblog.procore.com/dev/evolution-of-software-applications.html