Quick Hits: ADR Pattern Progress, MLAPHP Softcover, Aura Notices

Just some short updates today, since last week was so very busy:

1. The “Action-Domain-Responder” (née “Action-Domain-Response”) refinement of the MVC pattern has received some positive criticism and attention. In addition to example code updates, I have added responses (heh) to critiques regarding the Resource-Method-Representation pattern, and will soon be adding a response regarding “Entity-Interactor-Boundary” (aka “Entity-Contol-Boundary”). Many thanks to the commenters who recognized that they were already doing something along the lines of ADR; this helps to validate the pattern as something that already occurs “in the wild.” If you like the pattern offering, please star it at Github.

2. Modernizing Legacy Applications in PHP is now available for purchase in softcover via Lulu.com.

3. It looks like the next two Aura v2 releases will be Aura.View (the view system, specifically the “reduced” branch) and Aura.Html (the HTML helper collection that can be used by any view system). I’ve done a lot of work on them in the past few days and they’re beginning to feel like they’re ready.

Cheers all!

How To Modernize Your Legacy PHP Application

It is accomplished: “Modernizing Legacy Applications in PHP”, the book that will help you modernize your legacy PHP codebase, is complete. You can get it now it at https://leanpub.com/mlaphp.


Is your legacy PHP application composed of page scripts placed directly in the document root of the web server? Do your page scripts, along with any other classes and functions, combine the concerns of model, view, and controller into the same scope? Is the majority of the logical flow incorporated as include files and global functions rather than class methods?

If so, you already know that the wide use of global variables means that making a change in one place leads to unexpected consequences somewhere else. These and other factors make it overly difficult and expensive for you to add features and fix bugs. Working with your legacy application feels like dragging your feet through mud.

But it doesn’t have to be that way! Modernizing Legacy Applications in PHP will show you how to modernize your application by extracting and replacing its legacy artifacts. We will use a step-by-step approach, moving slowly and methodically, to improve your application from the ground up.

Moreover, we will keep your application running the whole time. Each completed step in the process will keep your codebase fully operational with higher quality. When we are done, you will be able to breeze through your code like the wind. Your code will be autoloaded, dependency-injected, unit-tested, layer-separated, and front-controlled.


From the Foreword by Adam Culp:

Developing with PHP has really matured in recent years, but it’s no secret that PHP’s low level of entry for beginners helped create some nasty codebases. Companies who built applications in the dark times simply can’t afford to put things on hold and rebuild a legacy application, especially with today’s fast paced economy and higher developer salaries. To stay competitive, companies must continually push developers for new features and to increase application stability. This creates a hostile environment for developers working with a poorly written legacy application. Modernizing a legacy application is a necessity, and must happen. Yet knowing how to create clean code and comprehending how to modernize a legacy application are two entirely different things.

But understanding how to use these refactoring processes on a legacy codebase is not straight forward, and sometimes impossible. The book you’re about to read bridges the gap, allowing developers to modernize a codebase so refactoring can be applied for continued enhancement.


Early reviews and testimonials from the feedback page:

  • “This is one of those books that PHP developers from all skill levels will be able to glean value from, and I know after just a single read-through that it will be an oft-referenced resource when I need to convert my old legacy-based procedural code into something cleaner, object-oriented, and testable.” (J. Michael Ward)

  • “As I followed the exercises in the book, my questions almost seemed to be anticipated and answered before the chapter was over. Structurally the book is very well paced. Chapters that I breezed over tended to be more useful than I thought they would be. I’ve been testing for years and I still picked up some useful tidbits about structuring my tests. Just having the step-by-step advice of an expert really made a difference.” (James Fuller)

  • “Reading through the book, it feels like you’re pair programming with the author. I’m at the keyboard, driving, and the author is navigating, telling me where to go and what to do next. Each step is practical, self-contained and moves you closer to the end goal you seek: maintainable code.” (Joel Clermont)

  • “This book helped me slay a 300k line of code giant and has allowed me to break out my shell. The refactored code has 15% code coverage for unit testing which grows every day.” (Chris Smith)


If you feel overwhelmed by a legacy application, “Modernizing Legacy Applications in PHP” is the book for you. Purchase it today and get started making your own life easier!

“Modernizing Legacy Applications in PHP” Update: Schedule, and Reviews

Today was my scheduled date for publishing the final edited copy of Modernizing Legacy Applications in PHP. Although the writing itself is complete, it has yet to finish its final editing pass. As such, the final version of the book is going to be delayed by at least a week. My apologies for the delay.

Even so, we have new reviews of the completed book! Here is one from J. Michael Ward:

Superb. This is one of those books that PHP developers from all skill levels will be able to glean value from, and I know after just a single read-through that it will be an oft-referenced resource when I need to convert my old legacy-based procedural code into something cleaner, object-oriented, and testable.

This is a very thorough guide to understanding how to write object-oriented programming in PHP in 2014 and getting developers stuck with legacy codebases up to speed with the tools that are available to them. I will recommend this to anyone who will listen.

And another from James Fuller:

The book is full of opinions on how to structure an application, but it thankfully avoids the trap of coming off as over-zealous and judgemental. The people who need this book know that legacy code is not a black-and-white problem and the tone of the book is both sympathetic and prescriptive.

The book is by no means overly-verbose, as you can read through it in a few well-spaced hours. I think that’s a good thing and you will probably find yourself going back to the book for reference time-and-time again, as I have already done in the period since I bought the book in beta. Occasionally you will have the annoying task of flipping to an appendix to read a large block of code but that is really a problem with any book that discusses code in detail.

And yet another from Joel Clermont:

Reading through the book, it feels like you’re pair programming with the author. I’m at the keyboard, driving, and the author is navigating, telling me where to go and what to do next. Each step is practical, self-contained and moves you closer to the end goal you seek: maintainable code.

I highly recommend this book. Even if you’re a seasoned developer like me (I’ve been writing code professionally more than 20 years), you will benefit from Paul’s approach and detailed documentation of the process.

If you feel overwhelmed by a legacy codebase, go out and buy Modernizing Legacy Applications in PHP today. (Updates are free for life.) The sooner you get started modernizing, the sooner you can start going home on time!

How To Convert Include Files To Classes

When working with legacy applications, there are two major problems tied for first place in causing frustration, pain, and overtime: globals, and includes. I talk about how to remove globals in “It Was Like That When I Got Here”. But removing includes can be a much bigger challenge in many ways.

My new book, “Modernizing Legacy Applications in PHP”, has an entire chapter on how to convert includes to independently testable classes. The chapter describes how to do this in a way that does not break the existing legacy code.

As a gift to PHP developers suffering under legacy applications, I have made that chapter part of the sample text for the book. You can read it here.

Afterword

Are you overwhelmed by a legacy PHP application? Have you inherited a spaghetti mess of code? Does it use globals everywhere, so that a fix in one place causes a bug somewhere else? Does every feature addition feel like slogging through a swamp of includes?

It doesn’t have to be that way. “Modernizing Legacy Applications in PHP” gives you step-by-step instructions on how to get your legacy code under control by eliminating globals and separating concerns. Each chapter shows you exactly one task and how to accomplish it, along with common questions related to that task.

When you are done, you will come and go through your code like the wind. Your application will have become autoloaded, dependency injected, unit tested, layer separated, and front controlled. And you will have kept it running the whole time.

Buy the book today, or sign up for notifications on the mailing list below!

[mc4wp_form id=”5830″]

Modernizing Legacy APIs

My friend Keith Casey is working on a book about practical API design. However, if you have a legacy application, adding (or updating) an API can be troublesome. It would be a lot easier to deal with an API if you could modernize your legacy application first. As Keith says:

If you read the tech press, everyone knows they need an API but most aren’t really sure what it is. They treat it as another checkbox like “Web 2.0″ was a few years ago or a mobile app was most recently. In fact, there’s an entire “API-first” movement in development circles that most people don’t understand or even realize why. …

Of course, how do you get your application ready for an API?

In response to that scenario, we are happy to announce a Leanpub book bundle: “Modernizing Legacy PHP Apps with APIs.” When you buy both books together and you get a discount from their separate prices. The Leanpub 100% happiness guarantee applies: if you don’t like your purchase, you can get your money back up to 45 days later.

Do you have a legacy application that you want to modernize? Do you want to add an API, or redesign the existing one? Buy “Modernizing Legacy PHP Applications with APIs” today and get started on making your own life easier!

“Page Script” As A Degenerate Controller

I read a good conversation on Reddit last week titled Thoughts on MVC vs. Pages for Everything?. Short version: the OP asks about the advantges of using a formalized model-view-controller system vs a series of typical PHP page scripts. The entire discussion is worth reading.

As the author of a book on modernizing legacy applications in PHP, this is a topic I am very familiar with. Almost all of the legacy applications I’ve had to deal with were page-based. In doing the work to modernize them, there comes a time where the page script has been refactored to look very much like a page controller, with some distinct but not critical differences. As such, I have come to consider the typical PHP page script to be a degenerate form of a page controller. With a little imagination, I think it’s easy to see why.

First, recall the basic operational cycle of almost every PHP framework ever, including the micro-frameworks:

  • a bootstrap index.php file that does some setup work, which hands off to …

  • a front-controller (typically a router/dispatch system) which picks …

  • a page controller or action method that calls services and collates the results into a data structure, which is passed to …

  • a view layer that renders the results for the client.

(In an earlier version of this dispatch cycle I split “page controller” and “action method” into two separate steps, and in many cases they may still be two separate steps.)

When we look at this cycle, it’s not so hard to envision a plain PHP script doing the same things. The web server itself becomes a simplified front controller+router+dispatcher, picking the “controller” (page script) to run based on the URL path mapped to the file system. After that the work is exactly the same, albeit combined into a single blob of code.

Even then, the page script can keep itself in good order by using service objects instead of embedding all the logic in one place. It should be easy to imagine converting a page script that combines the setup, data retrieval, data manipulation, and data output concerns as a blob of intermingled code, into something more like the following, where the concerns are in blocks:

<?php
// config, global vars, autoloader, etc
require_once '../setup.php';

// dependencies
$request = new Request($GLOBALS);
$response = new Response($GLOBALS);
$db = new Database($user, $pass, $host);
$service = new Service($db);
$view = new View;

// data retrieval
$page_number = (int) $request->get('page', 1);
$records = $service->fetchPage($page_number);

// data rendering
$view->setTemplate('/path/to/template.php');
$view->assign('records', $records);
$content = $view->render();

// send back to client
$response->setContent($content);
$response->send();
?>

That page script is not wildly different from what goes on inside a formal MVC framework. Yes, there are still some legacy elements. These include the global require setup at the top, the use of query parameters instead of path-info parameters, and the lack of a formal DI container (although for scripts like this a container proper might be overkill at the start).

On the other hand, most of the work is being done in classes and objects, not embeddded directly in the page script itself, just as you would see in a formal controller class method. These support classes and objects are independently testable; only the page script “controller” itself is not. But be honest here: of all the formal controller methods you have seen in the wild, how many were independently testable? My guess is “not many.”

Once we have refactored a page script to something like the above form, it becomes a lot easier to see how we might convert this degenerate controller over to a formal MVC framework with even further separation of concerns.

Afterword

Are you overwhelmed by a legacy application full of page scripts, spaghetti includes, and global variables? Do you want to improve the quality of the code, but don’t know where to begin or how to proceeed?

My new book, Modernizing Legacy Applications in PHP, gives step-by-step instructions on how to get your code under control and keep your application running the whole time.

Buy the early access version now and get free updates as it is completed, or sign up on the mailing list below for more information and a free sample chapter.

[mc4wp_form id=”5830″]

Book Announcement: Modernizing Legacy Applications in PHP

There you are, working late for the second night this week. Everyone else in the office has gone home. Most of the lights are out. Yesterday it was trying to copy a feature over to a different section of the site, because marketing wanted their new client to see it there. Today, you have just finished tracking down a globals-related bug in an SQL query embedded in a page script. It revealed itself only after yesterday’s feature addition. You had to search across scores of PHP files to find it. You commit the change, push it to the common repository, and update the bug report so that QA can check on it.

Although you are relieved, you are still frustrated and worried. Who knows what break this fix will reveal? The work should not be this hard.

Your Legacy Application

You were so excited when you got the job. The interviews went well. You clearly knew more than almost everyone else there. The other developers seemed like they really needed your help and expertise. The managers gave you a new laptop and a new LCD screen so you could be as efficient as possible. It was the perfect setup. You were eager to get to work showing off your skills and abilities to make the application sing, and get the project back on schedule.

But then you checked out the code base. It was a mess. It had been architected over several years by mulitple different lead developers, and it showed. There was no consistent pattern to any of the structure. The oldest core of the system was a collection of “include” files that ran several levels deep. Later, someone had bolted on some class-oriented libraries, and third person has decided to try a framework rewrite. All of it was done in a different coding styles, with different naming conventions. The codebase is a mixed-up aggregagation of PHP, HTML, SQL, JS, and CSS, frequently all in the same file. And there are no tests at all! The “tests” are the QA team running over the site once or twice a week.

After that first day, when you felt so enthusiastic, you have been reduced to feeling like a brand-new beginner every day since. It’s humiliating. Each day has been a new frustration, a new “WTF?” moment replayed in a dozen different ways. You want very much to to improve the codebase as it is, so that you can impose some sense and reason onto it, but the code is such an overwhelming mess of spaghetti that you don’t even know where to start.

Overwhelmed and drowning in bad code that you inherited from others, you’re ready to give up.

Modernize Your Legacy Application

But what if I told you it didn’t have to be this way? What if I told you there was a specific series of small, incremental changes you could make over time to slowly make the codebase better, more modern, and thereby reduce your own sense that things are futile?

My upcoming book, “Modernizing Legacy Applications in PHP”, does exactly that. Using my talk “It Was Like That When I Got Here” as a starting point, I condense 15 years of fixing PHP codebases into a collection of specific steps to complete in order. As you apply these small fixes, each one building on the last, you will be able to restructure your codebase from a spaghetti mess to a testable, organized, modernized application, free of globals and mixed concerns.

Would you like to have that knowledge, distilled into an easy-to-understand book? Sign up on the mailing list below, and you’ll be the among the first to:

  • Find out how the book is going (and when it’s ready for purchase!)

  • Receive hints on how to improve your codebase now

  • Get a free pre-publication chapter

[mc4wp_form id=”5830″]

I promise, you’ll never receive any spam or other unwanted messages on this list. Add your email today!