Paul M. Jones

Don't listen to the crowd, they say "jump."

Michelangelo's David With A Rifle: A Right To Bear Arms

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.


Don't Confuse Money Flows With Real Resources

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.


Publishers withdraw more than 120 gibberish papers

The publishers Springer and IEEE are removing more than 120 papers from their subscription services after a French researcher discovered that the works were computer-generated nonsense.Over the past two years, computer scientist Cyril Labbé of Joseph Fourier University in Grenoble, France, has catalogued computer-generated papers that made it into more than 30 published conference proceedings between 2008 and 2013. Sixteen appeared in publications by Springer, which is headquartered in Heidelberg, Germany, and more than 100 were published by the Institute of Electrical and Electronic Engineers IEEE, based in New York. Both publishers, which were privately informed by Labbé, say that they are now removing the papers.

Just because something is published under the banner of "SCIENCE!" does not mean is it actually scientific. Via Publishers withdraw more than 120 gibberish papers : Nature News & Comment.


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"]


Laravel Keeps Using That Word -- I Do Not Think It Means What They Think It Means

One of the things that we do by defining design patterns is we create a common language that we can use to explain and express ourselves. When I say to you “I used an Adapter” or “I implemented the Factory pattern”, that should conjure up a specific image in your mind of object relationships and behaviors, even if you don’t know my specific use case or problem domain.

When we use these terms incorrectly, we not only devalue them, we confuse developers. For one of the most up-and-coming frameworks to use a technical term so incorrectly is disturbing. It breaks down the vocabulary that technical people use to communicate with each other, because there are now two very different definitions floating around with the same name.

Of course, Laravel’s Facades are in fact well-designed proxies implementing the Proxy Pattern. There’s nothing wrong with that: as a developer, it’s up to you to decide how and what patterns you’re willing to accept in your framework, and to write your application however you wish. All I ask is that we stop calling them Facades.

Hear hear. Via Let’s Talk About Facades | BrandonSavage.net.


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!


Leanpub Sample Files With Symfony and Aura

One of the things that bothers me about some cli/console packages is how the commands you write with them end up being tightly coupled to the "framework" the package provides. You extend a command controller, which itself may use service location, and it has to be dispatched to via a specific console mechanism. Your actual command (the business logic) ends up tightly coupled not just to a tool for a specific task but to the package as a whole.

Most of the time I don't need a "full console application" -- I just need to read some input for the command, run my actual command logic, and send some output from the command. The Leanpub Sampler from Matthias Noback is an example of the kind of thing I usually end up doing in small or one-off projects.

Look at the invocation file for the command to generate Leanpub and see how Matthias gets this command running: load the autoloader, create Aura.Cli context and stdio objects, define the getopt flags, and then (this is the key) pass the option values to his real command object.

The command is completely separated from the environment, and fully decoupled from the "framework" that launched the command. The command itself uses the Symfony Finder component and a series of custom iterators. The work performed by the command could run as part of a web process if we wanted. This is a very nice piece of work.

Now, if you want a full console application to combine together a bunch of stuff, that's cool. Aura has Aura.Cli_Project for that, and there are other things out there for that as well. But the central point remains this: we should strive to keep the actual work of the command separated from the framework of the project as a whole.

Afterword

One of the troubles we have with legacy code is that there's very little separation of concerns. Setup work, business logic, and presentation logic are all intertwined and difficult to work with separately. As one result of that they are difficult to test.

But it doesn't have to be that way. My newest book, 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 complete that chapter, you will have improved the quality of your application, and it will keep running until you decide to start the next chapter.

Read more about the book!



Forward!

The first time I entered an American food market at the age of seventeen, I froze.

Older Soviets who visited American stores for the first time, got hit harder -- all the lies they were taught from childhood through the decades of their lives -- until that last moment, they expected them to be at least partially true.

Sure, they heard stories from overseas, but come on, those were just the Potemkin villages, mirages created to make the Soviets jealous. How can one imagine the unimaginable?

"They told us in Odessa, that in San Francisco it's hard to find milk."

This is the typical Soviet mentality, and they were used to it, and they bought into it, and then they entered that American supermarket and saw the rows upon rows of milk of different brands and kinds and fat percentages.

This is where some have been known to cry. It is the realization that their lives were stolen from them by the regime. A realization of what could've been, if they had been lucky enough to be born in this place which, from everything they knew, could not possibly exist.

I now live in Northern California, in the heart of the Bay Area, thousands of miles away from my homeland.

And yet the poison of Soviet propaganda seeps through college dorms just as it did in Soviet classrooms.

via Articles: Forward.


Aura.Marshal, A Database-less non-ORM

Just a quick-hit today regarding Aura while I work on the Modernizing Legacy Applications in PHP book:

It’s probably not correct to call Aura.Marshal an object-relational manager. With ORMs proper like Doctrine and Propel, the ORM issues queries for you using an embedded or preferred database library.

With Aura.Marshal, you use the data retrieval tools of your choice and write your own queries to retrieve data from a data source. You then load the result data into an entity type object, and the marshal automatically wires up entity and collection objects for you based on a relationship scheme you define for it.

The great benefit of this approach is that it completely decouples the in-memory object wiring from the act of doing the queries in the first place. The Marshal knows how to build and interrelate the objects, but it has no idea how to get the data for those objects in the first place.

Via Aura.Marshal, A Database-less non-ORM.


What Application Layer Does A DI Container Belong In?

James fuller asks:

any thoughts about which layer of the application we should be using a DI container like Aura.Di? Highest layer possible?

Twitter is too constrained and ephemeral for a good response, so I'll answer that question here.

First, we need to remember that a Dependency Injection container and a Service Locator are indistinguishable from an implementation perspective. (This is a view I accepted only recently.) The difference is in their use: if a container is ever placed into an object so the object can retrieve its own dependencies, that container is being used as a Service Locator. Conversely, if the container stays entirely outside an object so that dependencies are pushed into the object, the container is being used for dependency injection.

If we accept that description, the proper layer for a DI container is outside every other layer in the application (with the possible exception of Factory classes). That means the DI container is part of the bootstrapping code that sets up the application, and not part of anything else.

As an example, we can imagine a web application bootstrap script that looks like this:

<?php
// set up the autoloader
include '/path/to/autoload.php';

// create and set up a Container
$container = new Container;
$container->load('/path/to/container_config.php');

// retrieve a front controller service and run it
$front_controller = $container->get('front_controller');
$front_controller->exec();
?>

The purpose of the bootstrap is to create and configure the container with all its services and settings, then pull one object out of the container and invoke it. None of the objects in the system has to know that the container even exists. All of the objects are being created via the container, so in a way the container "contains" the entire object graph.

The part I had the hardest time getting about real dependency injection was this: If you have a class 2 or 3 layers down in the application, and that class needs dependencies, how do they get injected? Don't you have to pass the dependencies through the intervening layers, and then doesn't that break a lot of rules, along with violating plain common sense? And what if that class needs access to several different but related objects, but doesn't necessarily know what they are in advance?

The key for me was realizing that all object creation work happens in the container and not in the classes themselves. This is an alien way of looking at things for most PHP developers, who are more used to Singleton, Registry, and Service Locator, not to mention static calls to ActiveRecord objects. All of these patterns of usage mess with separation of dependencies, but are very common in PHP land, and form the basis of most PHP developers' understanding of how to work with dependencies.

It took me a year to really "get" the concept of dependency injection, under tutelage from guys like Jeff Moore and Marcus Baker, along with the writings of Misko Hevery. Once I understood it, I wrote the Aura.Di readme file as an introductory document to step readers through the various stages of dependency allocation. Perhaps that document will be helpful to others, even if they don't choose Aura.Di as a container.

Afterword

If you work with a legacy application, you already know how hard it is to track dependencies throughout the code. Sometimes the dependencies are global, sometimes they are created inside that class that needs them, and sometimes there is a service locator implementation floating around inside the classes. This makes it frustrating to track down bugs and make wide-ranging changes, and terribly difficult to write tests because everything depends on everything else.

But it doesn't have to stay that way. My new book, Modernizing Legacy Applications in PHP, gives detailed instructions that will lead you step-by-step from an include-oriented mess of page scripts to a modern architecture using dependency injection techniques.

You can buy the book in early-access mode today, or sign up on the mailing list below to get more information as it becomes available!