Paul M. Jones

Nazis make for better super-villains because at least they aim to be super or superior.  Communists ... are so unmentionable and unimpressive as individuals they by their own nature are not unique and thusly need to define themselves through others.  They aren't Lex Luther or The Joker hatching brilliant schemes as much as they are boring, common, petty thieves rationalizing their parasitism.

via Captain Capitalism: Why Nazis Make Better Super Villains Than Communists.

(N.b.: I was unable to write this post without saying "ssscrrrrutinizer" out loud over and over. I blame my friend Ray Chavarie for inflicting Frank Zappa on me at an impressionable time in my life.)

After finishing Uncle Bob's excellent Clean Code recently, I have been looking at my own code in Aura v2 even more critically. I started trying to apply more of the Clean Code principles to the different libraries, and thought I had done pretty well. But then I saw a scrutinizer.yml file in Luis Cordova's Gush project, and I was curious about it.

I visited scrutinizer-ci.com to read up on the project, and man was I floored. Here is a service that will analyze your project on Github and assign it a quality grade that aligns really well with the Clean Code principles (among others). After you register a repository with Scrutinizer and perform the first analysis, you can fine-tune the process with a config file so that the Scrutinizer looks in the right directories for source code, gives you code coverage analysis, and so on.

For one of my first experiments with the Scrutinizer, I started with the Aura.Sql_Schema v2 package. I thought it would come out pretty well, but even after pointing the Scrutinizer in the right direction, it only scored an 8.61 or so. I guess that's OK -- but could we do better?

Using the Hot Spots page I was able to find the worst offenders in the classes and methods. Because we have 100% test coverage on all Aura code, it was a only matter of applying appropriate refactorings -- the tests help to assure that changes don't break anything. (The Scrutinizer will even suggest refactorings for you to apply.)

After the refactoring processes, the Scrutinizer reported a 9.46. You can see the Scrutinizer report for Aura.Sql_Schema here. There's still room for improvement, but at least I know where the greatest improvement opportunities are.

Now that I've got a few days' experience with Scrutinizer, I find it a very valuable tool. It's very helpful as an objective assesment of code quality, so much so that I have added Scrutinizer badges to each Aura v2 package readme. You can see all the badges for all the packages on the v2 packages page.

Maybe the rest of the world knew about Scrutinizer before this, and I'm late to the game. I had not heard about it until recently, and now that I'm aware of it, I think it's a great service for any developer concerned about code quality. Congratulations to @schmittjoh and everyone else involved in Scrutinizer. Very nicely done!

UPDATE: In response to a question elsewhere: yes, Scrutinizer is free for open-source projects.

Read the Reddit discussion about this post here.

Earlier this week, we put the final touches on the “micro/macro” frameworks for v2 web projects and v2 command line projects. Although these had been delayed a bit while working out the Aura.Di v2 beta release, they both now have their first “Google beta” releases!

... The idea is that [Aura.Web_Project] starts as a very minimal system, with only router, dispatcher, request, and response functionality. But thanks to the Composer-assisted configuration system, it’s very easy to add whatever functionality you want, making the project as large or as small as you need. ...

Aura.Cli_Project takes exactly the same approach, but for command-line applications. It consists of a “context” and standard I/O system (the equivalents of a request and response), along with a console and dispatcher. It uses the same configuration system as Web_Project, so you start with a very minimal system that grows only as you need it.

...

Each project is little more than a skeleton around a core “kernel” package. The Aura.Web_Kernel is what actually provides the glue to connect the underlying library packages together, as does the Aura.Cli_Kernel.

Keeping the kernel separate from the project means we can update the kernel without having to re-install a project.

via First v2 Beta Releases of Web_Project, Cli_Project, and Framework_Project.

... average folks are constantly faced with images of people who seem to live lives that vastly surpass the quality of their own. These images are put in front of people in order to stoke the human being’s natural tendency to envy its fellow man, and it works. The goal is to get people to strive to meet the standards displayed in these images, and to spend accordingly to close the gap. The end result is a culture in which the image of an elite few has a tremendous impact on the way everyone else seeks to live their lives, as so many are willing to go to almost absurd lengths to close the perceived gap between themselves and the ideal individuals they see on television or on social media. Unfortunately, most fail to realize that the ideal lives they seek to mimic are mere facades, often generated at great personal cost to their owners. Too many are content with the mere appearance of success (tenuous as it may be) and too few are willing to take the time to ensure that solid, legitimate foundations underlie the image.

Emphasis mine. Via Why You Should Contain Your Envy.

It turns out that wealth inequality isn't about the 1 percent v. the 99 percent at all. It's about the 0.1 percent v. the 99.9 percent (or, really, the 0.01 percent vs. the 99.99 percent, if you like). Long-story-short is that this group, comprised mostly of bankers and CEOs, is riding the stock market to pick up extraordinary investment income. And it's this investment income, rather than ordinary earned income, that's creating this extraordinary wealth gap. 

The 0.1 percent isn't the same group of people every year. There's considerable churn at the tippy-top. For example, consider the "Fortunate 400," the IRS's annual list of the 400 richest tax returns in the country. Between 1992 and 2008, 3,672 different taxpayers appeared on the Fortunate 400 list. Just one percent of the Fortunate 400--four households--appeared on the list all 17 years.

via How You, I, and Everyone Got the Top 1 Percent All Wrong - Derek Thompson - The Atlantic.

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!

Read the Reddit discussion about this post here.

After a long period of consideration, research, and experiment, we have found a non-static solution for programmatic configuration through a DI container. It is part of a two-stage configuration process, implemented through a ContainerBuilder.

The two stages are “define” and “modify”:

• In the “define” stage, the Config object defines constructor params, setter method values, and services. This is the equivalent of the previous single-stage Solar and Aura v1 configuration system.

• The ContainerBuilder then locks the Container so that its definitions cannot be changed, and then begins the “modify” stage. In this second stage, we retrieve service objects from the Container and modify them programmatically.

...

So now, instead of each Aura package carrying a pair of define and modify includes in a subdirectory named for the config mode, we have a single class file for each config mode. The class file is in a subnamespace _Config under the package namespace. Here are two examples, one from the Aura.Web_Kernel package, and one from the Aura.Web_Project package.

Because they are classes, you can call other methods as needed, subclass or inherit, use traits, create instance properties and local variables for configuration logic, and so on. You could even call include in the methods if you wanted, keeping the class as a scaffold for much larger configuration files. This gives great flexibility to the confguration system.

...

To make sure the Aura project installation can find all the package config files, we use the {"extra": {"aura": { ... } } } elements of the composer.json in each package to provide a mapping from the config mode to the config class.

Read the whole article at Composer-Assisted Two-Stage Configuration.

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!

ArmaLite’s ads broke the unwritten rules. Instead of highlighting the hero’s body, they emphatically made him a warrior. Hence Franceschini’s objection to an “armed David,” even though every David is armed. “David famously used a slingshot to defeat the giant Goliath, making the gun imagery, thought up by the Illinois-based ArmaLite, even more inappropriate,” writes Emma Hall in Ad Age.

To the contrary, the gun imagery, while incongruously machine-age, was utterly appropriate. David did not use a “slingshot.” He used a sling. As historians of ancient warfare -- and readers of Malcolm Gladwell’s latest book, “David and Goliath” -- know, a sling was no child’s toy. It was a powerful projectile weapon, a biblical equivalent of ArmaLite’s wares.

Nor did Florentine patrons commission statues of David because he looked good without his clothes. They commissioned statues of David because he was a martial hero who had felled an intimidating foe. They made him a beautiful nude to emphasize his heroism, not to disguise his bloody deed. (Donatello’s David has his boot triumphantly on Goliath’s severed head.) Michelangelo’s giant was meant as an inspiration to locals and a warning to would-be invaders. He wasn’t an underwear model. He was a Minuteman. Putting a gun in his hand may look weird, but it’s a lot truer to his original meaning than a souvenir apron.

via Michelangelo's David Has a Right to Bear Arms - Bloomberg View.

While it is true that we spend more than other countries [on medical care] in an accounting sense, we actually use fewer real resources: fewer doctors, fewer nurses, fewer hospital beds, shorter lengths of stay, etc. That means that from an economist’s point of view, we aren’t necessarily spending more than other countries.

Fuchs says that with an extra $1 trillion, we could have more bridges, more highways, more teachers, more R&D, etc. But once again, this confuses money flows with real resource use. We can’t devote more real resources to non-health care unless we use fewer real resources in health care. But if we copy other countries, the resource flow will go in the opposite direction. That is, in order to have more doctors, nurses, hospital beds, etc., we will have to have fewer teachers, fewer roads, less R&D!

via A Better Way to Save $1 Trillion | John Goodman's Health Policy Blog | NCPA.org.