This is why you should always use braces on conditionals

In issue 65 on Aura.Router, Optional parameters not working as expected?, we can see that the problem was this piece of code from the issue reporter:

if(isset($this->route->params["id"]))
    echo "id = " . $this->route->params["id"] . "<br><br>";
if(isset($this->route->params["function"]))
    echo "function = " . $this->route->params["function"] . "<br><br>";
if(isset($this->route->params["third"]));
    echo "third = " . $this->route->params["third"] . "<br><br>";

Look at that last if statement: it ends in a semicolon. Although the line beneath it that is *intended* to be the body of the if statement, as indicated by the indentation, it is *not* the body of the if statement. It gets executed no matter the outcome of the if condition.

That kind of thing is really tough to debug.

Instead, if we use braces on all conditionals, regardless of how short or long the body is, we get this:

if(isset($this->route->params["id"])) {
    echo "id = " . $this->route->params["id"] . "<br><br>";
}

if(isset($this->route->params["function"])) {
    echo "function = " . $this->route->params["function"] . "<br><br>";
}

if(isset($this->route->params["third"])) {
}

echo "third = " . $this->route->params["third"] . "<br><br>";

Then it’s very easy to see what’s going wrong.

That is one reason Aura adheres to PSR-2; it incorporates that rule, along with many others, that makes it easier to know what to expect when reading code. Anything unexpected becomes a signal that something may be wrong.

What’s The Difference Between A “Pivot Table” And An “Association Table”?

An “association table” is a table that joins other tables in a many-to-many relationship. For example, if an Article can have more than one Tag, and each Tag can be placed on one or more Articles, then they are in a many-to-many relationship. To associate them to each other, we need a third table through which we can join them.

-- one end of a many-to-many relationship
CREATE TABLE article (
    article_id INT,
    title VARCHAR(255),
    body TEXT
);

-- the other end of a many-to-many relationship
CREATE TABLE tag (
    tag_id INT,
    name VARCHAR(255)
);

-- an association table mapping articles and tags to each other
CREATE TABLE article_tag (
    article_tag_id INT,
    article_id INT,
    tag_id INT
);

In ORM terms, we might say each Article “has many” Tags “through” the ArticleTag association, that each Tag also “has many” Articles “through” the ArticleTag, and finally that each ArticleTag “belongs to” an Article and that it “belongs to” a Tag.

When writing SQL to find the Tags for an Article, or to find all the Articles that use a specific Tag, we join the ArticlesTags table to get the associated entity IDs. The SQL looks something like the following:

-- select all the tags for an article
SELECT tag.*
FROM tag
JOIN article_tag ON article_tag.tag_id = tag.tag_id
WHERE article_tag.article_id = ?

-- select all the articles that use a tag
SELECT article.*
FROM article
JOIN article_tag ON article_tag.article_id = article.article_id
WHERE article_tag.tag_id = ?

This pattern is called an association table mapping.

On the other hand, a “pivot table” is a cross-tabulation query, frequently used in spreadsheets. You can see more about pivot tables through Google. In short, the idea is to build a query, and convert the rows into columns by grouping the rows in a particular way. These kinds of queries generally involve some conditionals and calculations to group the query results; you can see some examples here.

In summary: if you are joining tables to each other in a many-to-many relationship, the table that maps the relationship is an association table. If you are doing a cross-tabulation to convert rows into columns, you are working with pivot table.

What’s The Difference Between Tightly-, Loosely-, and De-Coupled ?

In a tweetstorm that spun up late last week, Taylor Otwell produced the following commentary:

look guys I’m “decoupled” because this package doesn’t have composer dependencies!!! HAHAHAHA LOL

how many composer packages a given package has does NOT affect YOUR code’s decoupling.

that is a matter of programming to an interface, etc.

you people seriously do not understand decoupling. at all.

if you type hint Aura\Anything that is a HARD, CONCRETE dependency. THAT is coupling.

Illuminate\Contracts are all interfaces. abstractions. not concretions. THAT’s decoupling.

Illuminate\Contracts\View\Factory could be a Laravel view factory, could be an Aura one. That’s decoupling.

how many composer pkgs the IMPLEMENTOR needs is an implementation detail my consuming code need not care about

consuming code ONLY cares about programming to an interface for decoupling.

you [@philsturgeon] and brandon [savage] and paul [jones] don’t understand basic programming concepts like coupling

and think somehow coupling is tied to composer

Aura ships hard concretions = you are tightly coupled to Aura.

which should my consuming code give a shit if Aura is decoupled AMONGST ITSELF. Nobody gives a shit.

i only care if MY code is coupled to Aura.

and since Aura makes you depends on hard concretions, it promotes hard couplings.

I’m saying if you type-hint a class dependency, you are coupled to that implementation (cont)

regardless of that package’s internal dependencies

While some of Taylor’s rant is correct for as far as it goes, much of it glosses over important distinctions in subtle misdirection, and the remainder displays some misunderstandings. He is also flat wrong in his assertions of other peoples’ understanding of “basic programming terminology.” As such, I think his words demand a careful response for future reference.

First, I’m glad to see Taylor paying attention to the proper use of terminology in a software context. This is something he’s not always been great at in the past, and I encourage him here.

But I can’t quite tell if Taylor thinks the developers who use Aura believe their code is decoupled by virtue of using Aura. Or maybe it’s that the Aura marketing phrase “fully decoupled libraries” is the target of his ire. I infer allusions to both from his tweets, so I’ll attempt to address both possibilities. (Perhaps there is some other interpretation I have missed.)

It should be so obvious as to not require stating, but for the sake of explicitness: If your code has a dependency on classes in a particular thrid-party package, your code is tightly coupled to the code in that package. This is true for any classes in any library, framework, or other package code. So, if you believe that depending on an Aura library in your code makes your code “decoupled” then you are mistaken. As far as I know, I have never attempted to state or imply otherwise. I don’t think any Aura users have this misperception, but if so, consider this a corrective.

The fact that your code could be tightly coupled to another package does not mean that the other package is coupled to anything else. That is to say, the other package might have no couplings of any sort to any other code outside itself. The other package in that case is de-coupled.

The Aura library packages are designed with that kind of decoupling in mind. That is, no Aura library package depends on anything at all in any other Aura package. Each of the Aura libraries is thus fully decoupled from the others, and incidentally from any framework that is composed of them. (Note that the *_Kernel and *_Project packages are coupled to other packages; the decoupling principle applies only to the Aura library packages.)

But why would you care if a particular library package is itself decoupled from other packages? I assert that one reason (of many) you want libraries that are themselves decoupled is so that, if you have to swap one out in your own code, you only have to worry about the one library, not about all the dependent libraries that it is coupled to (and all the dependent libraries they are coupled to). Swapping out is still tedious: you will need to work through your code, change all the typehints from that library’s classes to those in another, and change all the injections that specify classes from the library. But at least it’s only the one library; the fact that the library is itself decoupled reduces the swapping-out work.

Taylor points out another level of coupling called “loose” coupling. This means that, instead of your code depending on a particular class, you instead depend on an interface. This couples you to the interface, but not to any particular implementation. If your code depends on interfaces, your code is loosely coupled to the implementations of those interfaces (although I don’t think this means you are de-coupled – there’s still some knowledge necessary for interactions).

Being loosely coupled is a good situation to be in compared to being tightly coupled. If you need to swap out an implementation of an interface, you won’t need to change your typehints (unless you swap to another set of interfaces). However, you will still need to change all your injections to the new implementation. Overall, being loosely coupled makes for less work when swapping out libraries.

How can you tell if a package is coupled to another package? Provided that composer.json is not lying, it’s easy enough to examine the “require” element to see if there are other packages listed there. If there are, then it seems likely that the package is coupled to whatever is required. You need to exercise a little judgment, though. If the required package contains only interfaces, then the coupling is “loose”. Otherwise, it is “tight”. If there are no other required packages at all, then the package has no coupling of any sort; it is fully decoupled from anything outside of it.

However, that’s only if you assume composer.json is not lying. To really discover the coupling of a particular package, you would need to examine its code. Any uses of interfaces defined outside the package indicates loose coupling, uses of classes defined outside the package indicates tight coupling, and no uses of interfaces or classes outside the package indicates full decoupling.

(Note that this discussion is of inter-package coupling. Even if the classes inside a package may still be coupled to each other, the package as a whole may still be decoupled from any other package.)

Having said all this, Taylor is trying out a “contracts” package that exposes the Laravel interfaces independently of the implementations. I think this is a neat idea. It’s the only truly new thing I’ve seen introduced to the PHP community by the Laravel codebase, and I think it is worthy of emulation.

Even so, if the “contracts” include anything besides interfaces, I think coupling to them might be defined as “tight”. I am thinking specifically of the Exception classes included in the “contracts” package. Although it may be fair to think that Exceptions are exempt from coupling rules, perhaps they would be better provided as interfaces to Exceptions, instead of classes proper. I will reserve my judgment on that for a later time.

First Aura 2.0 Stable Project Releases!

Exciting news! After a little over a year in the making, the Aura web and CLI project packages saw their first stable 2.0 releases this weekend. This is a major milestone for Aura, as it means not just the core libraries but also the frameworks built from them are now complete.

Because Aura takes a “libraries first, framework second” approach, the project packages had to wait for the following 2.0 stable releases of these core libraries yesterday:

  • Aura.Di (a dependency injection container)
  • Aura.Web (web request/response objects, and a response sender)

Once those were stable, it was not much trouble to promote the various kernels and project skeletons to stable as well:

(Unlike Aura library packages, which have no dependencies because they are completely decoupled from each other, the *_Kernel and *_Project packages do have dependencies, as they are compositions of library and other packages.)

Read more on the Aura blog, including other library releases: First 2.0 Stable Project Releases!.

Action-Domain-Responder and the “Domain Payload” Pattern

tl;dr: Instead of inspecting a Domain result to determine how to present it, consider using a Domain Payload Object to wrap the results of Domain interaction and simulataneously indicate the status of the attempted interaction. The Domain already knows what the results mean; let it provide that information explicitly instead of attempting to re-discover it at presentation time.

In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.

For example, let’s look at an example of some older code to update a Blog post. This is MVC-ish code, not ADR code; we’ll refactor along the way.

<?php
class BlogController
{
    // POST /blog/{id}
    public function update($id)
    {
        $blog = $this->model->fetch($id);
        if (! $blog) {
            // 404 Not Found
            // (no blog entry with that ID)
            $this->response->status->set(404);
            $this->view->setData(array('id' => $id));
            $content = $this->view->render('not-found');
            $this->response->body->setContent($content);
            return;
        }

        $data = $this->request->post->get('blog');
        if (! $blog->update($data)) {
            // update failure, but why?
            if (! $blog->isValid()) {
                // 422 Unprocessable Entity
                // (not valid)
                $this->response->status->set(422);
                $this->view->setData(array('blog' => $blog));
                $content = $this->view->render('update');
                $this->response->body->setContent($content);
                return;
            } else {
                // 500 Server Error
                // (i.e., valid data, but update failed for some other reason)
                $this->response->status->set(500);
                return;
            }
        }

        // 200 OK
        // (i.e., the update worked)
        $this->response->status->set(200);
        $this->view->setData(array('blog' => $blog));
        $content = $this->view->render('update');
        $this->response->body->setContent($content);
    }
}
?>

We can see that there is some amount of model work going on here (look for a blog post, attempt to update it if it exists, check for error conditions on the update attempt). There is also some amount of presentation work going on; remember, the view is not the template – the view is the response. So, even though the view templates are separated, the HTTP status codes are also part of the presentation, meaning that there is an insuffcient level of separation of concerns.

In converting this to Action-Domain-Responder, we can pretty easily extract the model work to a Domain, and the presentation work to a Responder, resulting in something like the following. (Note that the Domain layer now adds values to the returned $blog entity to indicate different failure states.)

<?php
class BlogUpdateAction
{
    // POST /blog/{id}
    public function __invoke($id)
    {
        $data = $this->request->post->get('blog');
        $blog = $this->domain->update($id, $data);
        $this->responder->setData('id' => $id, 'blog' => $blog);
        $this->responder->__invoke();
    }
}

class BlogUpdateResponder
{
    public function __invoke()
    {
        if (! $this->data->blog) {
            // 404 Not Found
            // (no blog entry with that ID)
            $this->response->setStatus(404);
            $this->view->setData($this->data);
            $content = $this->view->render('not-found');
            $this->response->body->setContent($content);
            return;
        }

        if ($this->data->blog->updateFailed()) {
            // 500 Server Error
            // (i.e., valid data, but update failed for some other reason)
            $this->response->status->set(500);
            return;
        }

        if (! $this->data->blog->isValid()) {
            // 422 Unprocessable Entity
            // (invalid data submitted)
            $this->response->setStatus(422);
            $this->view->setData($this->data);
            $content = $this->view->render('update');
            $this->response->body->setContent($content);
            return;
        }

        // 200 OK
        // (i.e., the update worked)
        $this->view->setData($this->data);
        $content = $this->view->render('update');
        $this->response->body->setContent($content);
    }
}
?>

But at this point we’re still inspecting the Domain result to see how we should present it. This strikes me as a lot of work to determine something the Domain already knows.

Instead of re-discovering the Domain status in the Responder, we should let the Domain tell us not only the data, but also what to think about that data. The Domain should give us an indication as to what it tried to do, and whether it succeeded or not. Then we can completely skip the inspection of the Domain results and present those results without lots of additional work.

The key to doing this is something called a Domain Payload Object. (Initially I called this a “Domain Result” but my recent reading of Vernon’s Implementing Domain Driven Design revealed the term to me. I love finding the right word for a concept!)

With a Domain Payload, we wrap the Domain results in an object that carries those results for us. We can then extend the semantics of the Domain Payload to tell us what kind of payload it carries. Something as simple as the class name of the Domain Payload can give us that information.

In the ADR example code we will find a series of Domain Payload objects. While these map closely to HTTP response codes for simplicity’s sake, other Domains are very likely to have different kinds of payload statuses. The point is that each Payload object explicitly tells us what the results indicate: entity not found, invalid data in the entity, database error, successful update, and so on.

The BlogUpdateAction remains straightforward. However, the example BlogService‘s update() method now does all the update work, and it wraps all returned results in a Domain Payload that indicates the result status.

Finally, the BlogUpdateResponder, which itself extends an AbstractResponder, can match a Domain Payload class name to a method that presents the payload results.

Voila: no more inspection of the results to figure out presentation. We let the Domain tell us what it tried to do and whether it worked or not (and what the cause of the failure was, if any). At the presentation layer, our Responder can honor (or ignore) that information at its convenience.

New Aura v2 Stable Releases, and More

New v2 releases, and hey, what’s this about Aura.Di finally getting auto-resolution of typehinted parameters?

First, we have brand new 2.0.0 stable releases of these v2 packages!

Next, the Aura.Di package just got bumped to 2.0.0-beta2. This package in particular has seen some great new improvements, most notably auto-resolution of typehinted constructor parameters, and a brand-new README. Check it out at https://github.com/auraphp/Aura.Di.

Emphasis not in original; read the whole notice at http://auraphp.com/blog/2014/09/03/new-releases/.

Auto-resolution of typehinted parameters is something I’ve been against since the beginning of Aura.Di. After having used implicit magical convention for a long time, I have learned to prefer explicit configuration. However, auto-resolution turned out to be relatively simple to add, and the tradeoff of not having to explicitly specify every lazyNew('ClassName') every time on every parameter seems reasonable. (One hopes one does not get burned later for having made this concession.)

On Project Structure; or, The Framework/App Is Not Special

(I apologize for the hasty writing here; this subject makes me impatient.)

Reading this post from Code Rabbi makes me reflect on project structure and organization. Frankly, most project structures (as from CodeIgniter, Cake, and all the popular frameworks since then) strike me as misdirected. They’re examples of why the project maintainers think their code is somehow special and different, and that the application built from it is also somehow special and different.

Your framework and application code are not special. Their code does not go in a special place. There’s no need for a top-level “app” directory with its own special subdirectories. There’s no need for a special naming convention to keep your different application-specfic code in specific places.

We had PSR-0, and now have PSR-4, and the Composer autoloader, to handle all that for you. Just use namespaces. All you need for code at the top level of your project is a “src” directory, where all your app code goes, just like all your library code goes in a “src” directory in a library package.

Instead of /app/controllers and /app/models, you have /src/Controller and /src/Model, or however else you want to organize your namespaced code. Then there’s no need for a special autoloading system or for hard-coded paths just for your application-level code. Add one single line to Composer that points to the src directory and voila, everything inside it loads for you.

That’s it. Nothing special. Just like every other library in your system.

(Again, this was hastily written. Please ask for clarficiation if you feel you need it.)

DRY is about Knowledge

From Matthias Verraes:

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

This is a great observation, one I had not considered before. It makes me feel a lot better about the very few and very minor duplications of code in the various independent and decoupled libraries in Aura. In short, DRY is not a reason to couple code libraries with similar behaviors; instead, it is a reason to have a single canonical source of knowledge within a system.

Back On The Market!

After a year spent writing my book, working on Aura, speaking at conferences and user groups, advising startups, and proposing new design patterns, I am back on the market.

I’ve been writing PHP code since 1999, and in that time I’ve been everything from a junior developer to a VP of Engineering. If you have a PHP codebase that requires some attention, especially a legacy app that needs to be modernized, I’m your man. I’m also excellent as a leader, mentor, manager, and architect, on small teams and on large ones.

Resume and references available on request. Contact me by email (pmjones88 at gmail) or on Twitter @pmjones if you want to talk!>

UPDATE (Tue 19 Aug): Well that was quick. I’m off the market again, and looking forward to productive efforts with my new employer. My deepest gratitude to everyone who expressed interest; I am truly humbled by the whole experience. Thank you to all.

Soccer, Development, and The Value Of Teamwork

The lesson of soccer is that individual effort will often suffice when things are relatively easy. But in order to surmount the more difficult challenges, you will almost always need reliable teammates of one sort or another.

I assert the same is true in development efforts. A single developer working alone can do good work, but a team of frontend devs, backend devs, devops, and DBAs can do stuff that is truly amazing. Combine your comparative advantages instead of trying to do everything yourself. Via Vox Popoli: Calcio is life.