.a miniRFC.

Personal style and design convension.

TEST

Abstract

This resource acts in part as 1.) a declaration of my currently observed coding style convensions, 2.) to serve as a personal and single evolving authority of these convensions and 3.) be a public [for what’s it worth] undertaking by myself to use these convensions (where mum lets me).

NOTES

This resource tries to follow RFC style and defer to offical IETF resources where possible.

This document occasionally uses terms that appear in capital letters. When the terms “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT”, and “MAY” appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of the terms “MUST”, “SHOULD”, and “MAY” appears in RFC-1123; the terms “MUST NOT” and “SHOULD NOT” are logical extensions of this usage.

Sections

Language specific conventions

PHP

  1. Namespace naming
  2. Class naming
  3. Method naming
  4. Attribute naming
    1. Private prefix
    2. Static prefix
    3. Pointer/Reference prefix
    4. Constant prefix

JS

  1. Namespace naming
  2. Class naming
  3. Method naming
  4. Attribute naming
    1. Private prefix
    2. Static prefix
    3. Pointer/Reference prefix
    4. Constant prefix

Applied : Application Program Interface. (RPC Gateway)

  1. Development / Lifecycle
    1. Mocking
    2. Developer sandboxing.
    3. EOL and Support patterns
    4. Phases:
      1. Playground/Adhoc
      2. Local development
      3. Development -> Hotfix / Feature
      4. QA
      5. Release candidate 1/2
      6. Released -> Deployment tag.
  2. Endpoint URI path design guide
    1. Intro: Semantic Path / URI topology
      1. Recommended Semantic Path template
      2. Adding a versioning component -> Manifest busting -> Backwards compatibility.
    2. Lingistic / nomeniture convention
      1. Gender and plurality
      2. Localisation descussion
  3. ~~ :LIGHTING: Protocals~~
    1. Current preferences when selected a service protocal.
    2. Authentication bible
    3. HTTP[[S]]
      1. Request verbs.
      2. and Status codes.
        1. Status codes as rule based routing.
  4. ~~ :MAP: Architectual concerns~~
    1. :computer:Hosting
      1. within Geographics
      2. within an active Development context
      3. within a (horizontal) scale
      4. Working within a multiworker / multiwrite conherit data dependence.
        1. Alternatives to Master / Master DB Replication.
  5. :TICKET: Security
    1. Authentication methology templates.
    2. Rate-limiting.
    3. API User best practices.
    4. API User within a Lifecycle context.
    5. TLS / Encryption / Signing
      1. Making a company identity authority
        1. Using SMIME, HTTPS or Code Signing type CAs.
        2. Using a ROOT (self-signed) CA and when to.
        3. A few enterprise 3rd party CA alternatives
      2. Code signing:
        1. Developer certificates and commit signing.
        2. Atomic and crypographical signed releases.
        3. Forward end-point encryption. (MUST)
        4. Inter-Tier/Node communication guidelines.
        5. (howto:) Stateless crypographical signed sessions
      3. Challenge based tokening.
      4. Understanding PCI and scheduling stored user data.
      5. Safe(r) Fault / Verbosity patterns.
      6. Replay / Man-in-the-Middle / Service enumation overview.
        1. “NOOCE”? -> Learning from UDP Sequence field.
      7. Proxying 3rd-party API dependencies in the development phases.
      8. DoS hardening
        1. Passive ->
          1. [Understanding: Deterministic verse non-deterministic end points.]
          2. [Understanding: Payloads (and Caching) -> Userbound verse Servicebound.]
          3. ! Defining a tiered architecture.
          4. Tiering for a smart gateway layer
          5. Tiering the process stack.
          6. ~~Methods for KV coherency ~~
          7. Context derived path mapping.
        2. Active ->
          1. IP and TCP state filtering.
          2. Heuristic triggered filtering
  6. Logging / Auditing
    1. Handling multi-host, OS-level events with services like syslogd.
    2. Levaging exception feedback loops for defensive and robust services. (COMING SOON)

Support or Contact

Copyright (C) Kyle Younge (2017). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or disclaimers.

This document and the information contained herein is provided on an “AS IS” basis and the authors, ie. Kyle Younge or contributors, ie others DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

These guidelines are in part are an aggregation of every sensible developer and engineer I have worked with.

THANK YOU!

Where I remember and can, all copy & pastes of other 3rd party resources will be itemised below:

  • Countless IETF :HEART: