mdwheele

Edit: A bit of context as more than expected are happening upon the gist.

This is in response to a conversation between a few engineers I consider experts in their respective fields:

• Jeffrey Way (of Laracasts) as a technical educator aiming to investigate exposing newcomers to DDD in an easier-to-digest/grasp way.
• Konstantine Kudryashov (Behat, phpSpec, Inviqa) as a BDD consultant
• Mathias Verraes (dddinphp.org, http://verraes.net/) as a significant DDD resource and independent consultant.

Additional context can be sought reading backwards from https://twitter.com/mdwheele/status/527233999744557056. The stream is a bit broken, but the general gist/context is there.

mdwheele

Please do not read any of this with an "absolute" tone. These are merely my thoughts on a problem based in my current understanding and some experience. To be honest, I would not be surprised if this is already being done by individuals more experienced than I at building REST APIs, but I think it is worth discussing as I have yet to find anything like this blogged about. I present this with utmost humility in order to foster discussion; not to create devolving argument.

Some Background

I believe that usage of media types in examples on the web demonstrating "how to build" RESTful APIs is too narrowly focused. In my experience, much of the discussion around them seems to be solely focused on their usage either in content-negotiation or applying versioning to an API.

*As an aside, versioning can be "controversial" itself as an "anti-pattern" of REST. I heard it argued that HATEOAS should be the answer to the problem that versioning works to solve. This is an aside and not the focus of this ponderanc

mdwheele

Replace this line with imperative summary

An awesome description describing WHY over HOW/WHAT

# [Ticket #12]

#-----------------------------------------------@----------------------#
#
# 1. Summary should be under 50 characters. @-symbol above is a marker 
#    for that.

mdwheele

<?php

namespace Vendor\Services;

use Closure;

class Cache
{
    protected $prefix;

mdwheele

Replace this line with imperative summary

An awesome description describing WHY this work over HOW/WHAT it does.
The diff attached to commit should describe implementation (HOW) 
well-enough.

# [Ticket #12]

#-----------------------------------------------@----------------------#
#

mdwheele

language: php

sudo: false

matrix:
  fast_finish: true
  include:
    - php: 7.0
      env: WITH_COVERAGE=true
    - php: 5.6

mdwheele

Benchmark

This is a benchmark for https://wiki.php.net/rfc/friend-classes that attempts to approximate performance delta between master and feature/friend-classes-poc.

Both benchmarks execute a script that attempts access of a target property 100,000 times. We sample 100 executions of this script and average to compare.

Compilation

make clean

mdwheele

const produce = ['Apple', 'Potato', 'Banana', 'Cucumber']

// Using a temporary value to build up our result.
const fruits = []

// Bad: Using filter that has a side-effect (non-pure function).
produce.filter(p => {
  if (['Apple', 'Banana'].includes(p)) {
    fruits.push(p)
  }

mdwheele

<script>
/**
 * This is a "renderless component". What that means is that it has no presentational
 * aspect to it at all. It's really just about behaviour and state management.
 *
 * It receives a list of whatever you want via :items and allows the consumer to set
 * a maximum page size via :perPage. Everything from that point forward is under control
 * of the parent of Paginate. You provide your own slot contents and destructure slot props
 * to get the current page or interact with pagination.
 */

mdwheele

<template>
  <Stepper v-model="step" v-slot="{ title, description, total, progress, next, prev, hasNext, hasPrev, nextStep, prevStep }">
    <p>There are {{ total }} steps.</p>
    <p>You are {{ progress }}% complete.</p>

    <h1>{{ title }}</h1>
    <p>{{ description }}</p>

    <Step title="First" description="The first step...">
      1