The Rich Web Experience

2015

 

Not a Frontend Conf

  • Majority of "front-end" presentations were super intro-level talks.
  • Sometimes it seemed like they read the Wiki page on a topic and then turned it into slides
  • Sometimes they just completely made stuff up
  • The quality of Donuts.js presentations generally surpassed the quality of these front-end presentations
  • Opportunity: offer to present at future conferences

During Boring Talks, Learned:

  • React
    • stateful vs stateless components
  • Redux
  • Webpack
  • Webpack Dev Server
  • CSS Modules
  • Built Some Demo Components
  • Started a React Starter

Keynote

Venkat Subramaniam

Writing in an imperative paradigm: creating a puzzle.


Writing in a functional paradigm: creating a story.

Make yourself uncomfortable for at least 30 minutes a day learning something new

React Workshop

  • High-level overview of React only (the "V" of an MV* app).
  • Didn't get into flux / redux / actions, etc
  • A good opportunity to learn the very basics and have dedicated, structured time to experiment
  • I cloned the workshop repo for those who are interested: https://github.com/tuxsudo/react-workshop-day1

Microservices

Neal Ford

http://nealford.com/downloads/Building_Microservice_Architectures_Neal_Ford.pdf

Microservice is the first architecture style developed post-continuous delivery 

Traditional SOA

  • Architecture that is separated technically
  • Technology encapsulates domain

MicroServices

  • Architecture that is domain separated
  • Domain encapsulates technology

Share-Nothing Architecture

each service is individually deployable

Bounded Context

No external dependencies. All is self contained. Technical layers are bound within the domain layer.

  Decentralized Data Management

BASE over ACID

Decentralized Governance

  • Teams make best tech choices under their bounded context
  • Teams can make changes within bounded context

Small, Single Responsibility

  • small enough to fit in your head
  • rewrite when needed: not a big deal

Maximize Easy Evolution

services become hot-swappable

Evolutionary Architecture

  • Features are released
  • applications consist of routing of services.
  • when apps change routing from one service to another, you can monitor and deprecate unrouted services
  • one-off things are OK
    • not trying to build an empire service

Design for Failure

  • clients must fail gracefully

  • aggressive monitoring

    • business

    • architectural monitoring

    • semantic monitoring

    • (logstash, kabana)

Standardize on integration; not platform

  • embrace polyglot solutions where sensible
  • blackbox all the things, standardize on how they communicate

Products not Projects

Two-Pizza Teams

  • Teams small enough to feed with 2 pizzas
  • Cross Functional Teams
    • Product Owner
    • Devs
    • DBA
    • Operations
    • Designs
    • Etc
  • Team "owns" the product
  • Team more accountable to each other (face-to-face)

Conways Law

"Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations."

Team silos lead to system silos

  Inverse Conway Manuever

  Build teams around the desired architecture

Tons More Content

more follow-up needed

Books to Read

  • Domain Driven Design

  • Building Microservices

  • Release IT

  • Software Architecture, Fundamentals Part 1 Understanding the Basics

Microservice Testing

Matt Stine

Microservices:

Loosely coupled service oriented architecture with bounded contexts

Decentralized, Autonomous Capability, Teams, Services.

  Distributed Governance

From MTBF to MTTR

  • MTBF - mean time between failure
    • goal: maximize time between accidents
    • doesn't lend to risk-taking
  • MTTR - mean time to recovery
    • goal: minimize time until recovery
    • allows for risks
    • require more monitoring

Test Pyramid

  • Exploratory (least testing)
  • End-to-End
  • ------
  • Component
  • Integration
  • Unit Testing

Test Pyramid

  • Exploratory (least testing): user testing
  • End-to-End: entire system testing across bounded contexts.
  • ------ (contract testing) ------
  • Component: testing your blackbox; the public API
  • Integration: anything that touches the network within your bounded context
  • Unit Testing: testing units of code (most testing)

Design Principles

Venkat Subramaniam

Principles

  • DRY
  • YAGNI
  • SRP
  • SLAP
  • Compose Method Pattern
  • OCP
  • Limit Inheritance

R

By Jared Anderson