php[architect] logo

Want to check out an issue? Sign up to receive a special offer.

Treasure, Old & New – May 2018

You’ve probably been deep into debugging an issue, when you have a “How did this ever work?” moment. When you inherit someone else’s codebase, you’ve also probably asked: “How is this supposed to work exactly?” I’ve found a lot of programming time is spent alternating between these two extremes. While you may be under pressure to just fix something or get a feature out the door, it’s worth taking a little time to pay-it-forward, usually to your future self, by documenting things clearly, adding tests, and choosing an easy-to-understand solution instead of a clever one. In this issue, we focus on how to keep your application code shiny.

Sponsored By
Nexcess Logo

Up to My Eyeballs in Technical Debt!

By Steve Grunwell

In this era of “move fast and break things,” organizations often fail to consider the long-term costs of decisions made for short-term gains. When projects cut corners, lack documentation and/or tests, and are regularly changing it’s not uncommon for them to quickly become too expensive to maintain or, at the very least, technical pits of despair. Software doesn’t need to be painful, however, and a little pragmatism goes a long way towards mitigating so-called “technical debt.”

The Life-Changing Magic of Tidying Your Code

By Bryce Embry

When I made the transition from hobbyist to professional programmer, I discovered it isn’t enough for my code to work; it also has to be easy to maintain. At first, I wasn’t sure how to make it happen. Then, when I read Robert Martin’s book *Clean Code*, I discovered good code is written with people in mind, follows a consistent format, has short functions, uses meaningful names, and avoids comments. Applying these principles has dramatically improved my code and can change your life as well.

Moving a Monolith to AWS

By Keanan Koppenhaver

Cloud technology can give applications greater flexibility, but it can be more complicated to maintain, especially for a monolithic legacy application. However, with a few tweaks, even older codebases can run in the cloud. Let’s take a look at how an older application which needs to scale can benefit from running in the cloud.

Easier Mocking with Mockery, Part 2

By Robert Basic

In part one, we laid the practical groundwork for using test doubles. Let’s explore the parts of Mockery that, in some cases, exit the realm of everyday usage and see how it can help us in dealing with scenarios we might have thought impossible to test like static method calls, spying on objects, and more.

The Dev Lead Trenches: It’s Toxic

By Chris Tankersley

The tech industry is a relatively young industry, and in many ways, it shows. In one of my favorite books, Hackers: Heroes of the Computer Revolution, Steven Levy talks about the birth of the open source industry going back to the late fifties and early sixties. Many of his descriptions of programmers then are not vastly different than programmers today. These problems are not technical and can drive good programmers away. What can we do to avoid these issues?

Artisanal: Odds and Ends

By Joe Ferguson

This month I’m running with a collection of odds and ends of Laravel which I feel strongly about or that answer some common questions about Laravel and the related ecosystem. I find these issues to be common among people who ask me about Laravel on social media or in person at conferences or user group meetups.

Education Station: Build an API, Part Two

By Edward Barnard

In this series, we look at using Behavior-Driven Development (BDD) and specification by example to develop a RESTful API. In Part Two we introduce Behavior-Driven Development as a way of communicating with non-developers, our stakeholders.

Security Corner: Paying Off Technical Debt

By Eric Mann

Every successful development team has two things in common: they’ve shipped a product, and they accepted compromises to make that shipment possible. Every team and every project has technical debt. It comes with the territory when you start building software. Usually, the term “technical debt” is seen as a negative, but that’s not always true.

Community Corner: My Picks From Packagist

By James Titcumb

Most people are aware of how the Composer revolution came about, and the goal of getting everyone to play nicely together. For the most part, it seems to have worked, and more and more developers are coming on board with avoiding “Not Invented Here” and embracing the more than 1.2 million versions of packages available today. With so many packages it can sometimes be difficult to know where to begin. “I’m going to look at some packages from the open source community you might find useful if you’re not already using them!

finally{}: Innovation in PHP

By Eli White

One of the fantastic things about the PHP language is that we, the community, are constantly evolving it. If you take a look at PHP code from just a few years ago, it can appear alien compared to anything written in modern PHP today. In fact, I’ve often stated that PHP was, in fact, unique among all the programming languages that exist currently. Yes, quite a few of them are open source; however, PHP is the only one truly embracing the open source concept. It is continuously changed, and not by a single gatekeeper but by a broad and vast team of engineers who use the language every day.

Leave a comment

Use the form below to leave a comment: