Paul M. Jones

Does this sound like anyone you know?

I’m charmed and sometimes I’m exasperated by how [Millennials] deal with the world. My huge generalities touch on their over-sensitivity, their insistence that they are right despite the overwhelming proof that suggests they are not, their lack of placing things within context, the overreacting, the passive-aggressive positivity.

…

I am looking at Millenials from the POV of a member of one of the most pessimistic and ironic generations that has ever roamed the earth. -- Generation X . Even my boyfriend agrees that [Millenials are] overly sensitive, especially when dealing with criticism. When [a Millenial] creates something they have so many outlets to display it that it often goes out into the world unfettered, unedited, posted everywhere … but when criticized for this content they seem to collapse into a shame spiral and the person criticizing them is automatically labeled a hater, a contrarian, a troll.

…

Anxiety and neediness are the defining aspects of [Millenials] and when you don’t have the cushion of rising through the world economically then what do you rely on? Well, your social media presence: maintaining it, keeping the brand in play, striving to be liked, to be liked, to be liked. And this creates its own kind of ceaseless anxiety. This is why if anyone has a snarky opinion of [Millenials] then that person is labeled by them as a “douche”--case closed. No negativity -- we just want to be admired. This is problematic because it limits discourse: if we all just like everything--the Millennial dream--then what are we going to be talking about?

…

Millennials can’t deal with that kind of cold-eye reality. This is why [they] only ask right now : please, please, please, only give positive feedback please.

Edited for compactness, from Generation Wuss.

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.

Read the Reddit discussion about this post here.

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.

UPDATE: Apparently "pivot" is also a keyword in SQL Server to help generate true pivot tables; see here. See also Associative Entity.

Read the Reddit discussion about this post here.

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 AuraAnything that is a HARD, CONCRETE dependency. THAT is coupling.

IlluminateContracts are all interfaces. abstractions. not concretions. THAT’s decoupling.

IlluminateContractsViewFactory 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.

Read the Reddit discussion about this post here.

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:

• Aura.Project_Kernel (the kernel files for every Aura project type)
• Aura.Cli_Kernel (the kernel files for CLI projects)
• Aura.Web_Kernel (the kernel files for web projects)
• Aura.Cli_Project (a skeleton CLI project)
• Aura.Web_Project (a skeleton web project)
• Aura.Framework_Project (a skeleton cli+web project)

(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!.

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.

Read the Reddit discussion about this post here.

Hollywood lies to you. You cannot have sex with multiple men before marriage and walk away emotionally and physically unscathed. There will be no handsome millionaire willing to marry you when you’re 33 and ready to settle down. Once you’re married, adultery is no light, breezy thing. You probably won’t live in that huge home with a pool and a maid to do the cleaning. Your “high-powered” career will mostly likely consist of tedious paperwork in a claustrophobic office cubicle as you daily work through messy office politics and cope with a few difficult colleagues, while worrying about all those unfinished tasks at home. All too often, especially if you made poor choices about what to study in college, you will not get your dream career. You might actually end up being the maid or the nanny for another woman, doing the same housework/childcare in a stranger’s home that feminists always told you was sneer-worthy work to do in your own home. Your debt load will scare you. Your loneliness could shatter you. Men will come and go as they use you for their sexual pleasure and you will pretend to feel “empowered” by letting them do so. Those of you who do marry will have to work hard at suppressing some depression-causing discontent in your late 30s when you look at your non-movie-star husband, the average home that’s as nice and as big as it’ll ever get, the kids who are just as special and wonderful as every one of their classmates, the neighbors who have more holidays and nicer vehicles than your family, and the sheer ordinary-ness of your life compared to the lives of the rich and famous.

Some women break. When a single woman breaks, she chiefly damages herself. When a married-with-children woman breaks, she damages many other lives as she runs off in search of the fantasy world of “perfect-happiness-with-a-gorgeous-sensitive-rich-man” that Hollywood fed to her.

As I said, there are many reasons why all too many Western women are unhappy. Hollywood is one of them.

via One Reason Western Women are Unhappy | Return of Queens.

In one experiment, Wiseman asked people to self identify themselves as lucky or unlucky. Then he gave his test subjects a newspaper. “Count the number of photographs inside”, he told them.

There were 43 photographs.

On average, the unlucky people took 2 minutes to count them all. The lucky people? Seconds.

The lucky people noticed the giant message that took up half the second page of the newspaper. It said, “Stop counting – There are 43 photographs in this newspaper.”

The unlucky people missed it. They also missed the equally giant message half way through the newspaper, “Stop counting, tell the experimenter you have seen this and win $250.”

The “lucky” people weren’t lucky. They were just more observant.

via Why are some people so much luckier than others?.

A summary of Vox Popoli: Mailvox: the distribution of atheist intelligence:

- On average, atheist IQ is a little higher than theist IQ. Of course, averages are misleading, because ...

- There are more high-IQ theists than high-IQ atheists.

- The majority of atheists have sub-100 IQs.

- "The two most common types of atheists are the High Church atheists with 128+ IQs and Low Church atheists with 65-72 IQs. The Low Church atheists actually outnumber the High Church atheists, 22.9 to 17.2 percent."

- "There are 11.4x more 128+ IQ theists who either 'know God exists' or 'believe God exists despite having the occasional doubt' than there are 128+ IQ atheists who 'don't believe God exists.'"

See the article for an interesting set of graphs.

Part of me wonders if this accounts for the "I Love Science!" crowd, despite not actually know what science *is*, as well.

FWIW, I was raised a Methodist Christian, so I have a warm place in my heart for religion. In adulthood I became an agnostic, not an atheist, so I have no particular dog in that fight. I have not taken a formal IQ test so I do not know where I fall on that scale. I like science as a methodology, which is why I am perturbed by messages purporting to be "scientific" when they are not.

Novice researchers often enter behavioral psychology convinced of the blank slate thesis. They believe that little boys and girls are born tabula rasa. Parents, teachers, and society then proceed to mold children’s interests, talents, and temperaments towards the dominant gender stereotypes.

Tenured faculty members have a word for blank slate proponents: “childless.”

In other words, men and women (on the whole and in the main) are physically, intellectually, and emotionally different. Thus, you don't need "the prejudice of sexism" to explain disparities. All you need is differing internal motivations, preferences, and interests. Yes, at the tail ends of the distributions you may find overlap, but if the significant majority show similarities to the rest of their sex, then even a small set of sex-based differences can lead to widely divergent outcomes between sexes.

But that gives Social Justice Commissars a lot less to work with, so of course it must be a result only of sexism. (/me rolls eyes)

via An 'Ether Of Sexism' Doesn't Explain Gender Disparities In Science And Tech.