Microservices require having a solution for each of the boxes. @adrianco #qconnewyork microservices sotu pic.twitter.com/DYHiz7aOIz

— Philip Fisher-Ogden (@philip_pfo) June 15, 2016

How To Code Like The Top Programmers At NASA — 10 Critical Rules

How To Code Like The Top Programmers At NASA — 10 Critical Rules: "NASA’s 10 rules for writing mission-critical code:

•  Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion. 

• All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.

• Do not use dynamic memory allocation after initialization. 

• No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function. 

• The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements). 

• Data objects must be declared at the smallest possible level of scope. 

• The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function. 

• The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code. 

• The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. 

• All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings."

'via Blog this'

Processes > People

pic.twitter.com/oQ4doPmWNP

— Jessica DeVita (@UberGeekGirl) April 30, 2016

Google Testing Blog: Flaky Tests at Google and How We Mitigate Them

Google Testing Blog: Flaky Tests at Google and How We Mitigate Them: "At Google, we run a very large corpus of tests continuously to validate our code submissions. Everyone from developers to project managers rely on the results of these tests to make decisions about whether the system is ready for deployment or whether code changes are OK to submit. Productivity for developers at Google relies on the ability of the tests to find real problems with the code being changed or developed in a timely and reliable fashion.

Tests are run before submission (pre-submit testing) which gates submission and verifies that changes are acceptable, and again after submission (post-submit testing) to decide whether the project is ready to be released. In both cases, all of the tests for a particular project must report a passing result before submitting code or releasing a project.

Unfortunately, across our entire corpus of tests, we see a continual rate of about 1.5% of all test runs reporting a "flaky" result. We define a "flaky" test result as a test that exhibits both a passing and a failing result with the same code. There are many root causes why tests return flaky results, including concurrency, relying on non-deterministic or undefined behaviors, flaky third party code, infrastructure problems, etc. We have invested a lot of effort in removing flakiness from tests, but overall the insertion rate is about the same as the fix rate, meaning we are stuck with a certain rate of tests that provide value, but occasionally produce a flaky result. Almost 16% of our tests have some level of flakiness associated with them! This is a staggering number; it means that more than 1 in 7 of the tests written by our world-class engineers occasionally fail in a way not caused by changes to the code or tests."



'via Blog this'

Performance: 10 Commandments
Mostly scraped from @mjpt777 talks pic.twitter.com/K3NWtGnMl0

— Julian Warszawski (@hundredmondays) June 7, 2016

Yet Another Distributed Systems Reading List

"Yet Another Distributed Systems Reading List 

I started putting together a reading list for engineers fairly new to distributed systems and theory, with little hands-on experience yet."



'via Blog this'

HTTP API Specs

HTTP API Specs: "A collection of RFCs and other specifications, useful when designing and implementing HTTP APIs."

HTTP	Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Links	Web Linking
Links	URI Template
Links	IANA Link Relation registry
Generic Media Types	JSON Hypertext Application Language
Generic Media Types	Siren
Generic Media Types	Collection+JSON
Other Media Types	Problem Details for HTTP APIs
Other Media Types	Home Documents for HTTP APIs
Semantics	The ‘profile’ Link Relation Type
Negotiation	Prefer Header for HTTP
Caching	HTTP Cache-Control Extensions for Stale Content
Security	Hypertext Transfer Protocol (HTTP/1.1): Authentication
Security	The OAuth 2.0 Authorization Framework
Security	The OAuth 2.0 Authorization Framework: Bearer Token Usage
Security	OpenID Connect Core 1.0
Security	IANA HTTP Authentication Schemes registry
Syntax	Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Syntax	Uniform Resource Identifier (URI): Generic Syntax

'via Blog this'