Øredev 2012, Notes from Day Two

The Rebellion Imperative, Reginald Braithwaite

Every daring attempt to make a great change in existing conditions, every lofty vision of new possibilities for the human race, has been labelled utopian. -- Emma Golden

Wealth breeds inefficiency

Since a wealthy man can buy anything he wants he has no need for efficiency.

The powerful enforce statis.

Progress is against their best interests.

Stasis, the state of equilibrium or inactivity caused by opposing equal forces. -- dictionary.com

The four sustainable positions from Marketing Warfare

• The Leader Defends
• The Rival Attacks
• The Innovator Disrupts
• The 99% are Rebels

Android is for people that don't need to be cool!

Don't attack their weakness, attack their strength!

Principles of Rebellion

• Find a territory small enough to defend - and don't overextend yourself.
• Never act like the leader.
• Be prepared to bug out at a moment's notice.

God fights on the side with the most cannons. -- Napoleon

When you are being rebellious, you don't want a lot of dependencies, like infrastructure etc. You need to be in control of your own destiny.

Bug out

You can't fall in love with what you are doing, because most of the time it will not work out.

A rebel does not have resources to waste on a lost cause.

Rebels are lean

• Rebels have lean businesses.
• Rebels use lean tool chains.

Disruption

If there is an existing market, you are doing it wrong.

Analysts are wrong because they are corrupt motherfuckers who are paid to make press releases. -- Reginald Braithwaite

You can't ask customers, you have to tell them!

Micro Service Architecture, Fred George

Unit test counts are important, the more you get working the more you show progress.

1M loc -> 100K loc trying to get out -> 20 * 5K loc services, trying to get out

Only nuggets should be published by the services. Nuggets are small pieces of information not the whole blob. If you need everything go get it from the source.

Clients that are not desperate will not try anything interesting at all.

Bayesian Service Principles

• It's okay to run more than one version at the same time.
• You can only deploy one service at at time.

Observations

• Services are like classes, small, crisp conceptualization, 100 loc.
• Smalltalk messages perfect for services.
• Encapsulation, every service own the data.
• Services became disposable, no need for test, just rewrite them.
• Loosly coupled via RESTful JSON
• Self monitoring services replaces Unit Tests.
• Business monitoring replaces acceptance tests.
• Service language-agnostic, Ruby, Node, Clojure

Problems

• Cycle, lost packets
• Need to redefine tracking, logging
• No experience in defining services.

Data Ecosystems

Collect all the data, In The Plex

• Consumers, R, Hive, Monitoring, Apps, Services
• Producers, app, app, service, web server

Conclusions

• Agile Best Practice Not Used
• Technical Debt does not appear, services are so small.

Principles

• Very small
• Loosely coupled
• Multiple versions acceptable
• Self-execution monitoring of each service
• Publish interesting stuff
• Application is a poor conceptualization

Living Software System

• Long-lived system, short lived services
• Extremely dynamic with continuous deployment, 5-10 minutes between deploys.
• Accept it is complex (especially for testing)
  • Acceptance test on business outcomes instead.
• Radical impact to processes, anarchy
• There will be a learning curve for developers!

Scalable and Modular CSS FTW, Denise Jacobs

Denise gave an overview of some other people's ideas. The ideas come from Object Oriented CSS, SMACSS, and CSS For Grown Ups.

OO CSS (I think)

DRY, Don't Repeat Yourself, Never repeat a style property if you can Group selectors with shared properties. Ask yourself why isn't this part of the group?

• Use a grid
• Use a reset CSS
• Use the cascade
• Separate structure and presentation
• Style classes rather than elements
• Don't use IDs for styling, only for JS hooks
• Avoid class names that are related to the style.

SMACSS

Categories of styles

• Base
• Layout
• Module
• State
• Theme

Shallow Selectors

• Use class names as the right-most key selector.
• You're better of adding classes than having overly-specific selectors.
• Module candidates navbars, carousels, dialogs, widgets, tables, icons
• Naming conventions are very important. Examples is-active, is-collapsed, btn-pressed

CSS for Grown Ups

Don't style pages, instead style modules and make a library that you can reuse.

Categories of Styles

• document
• base
• module
• layout

Javascript styles prefixed with js-

Common ideas

• IDs not so much
• Classes are good
• Less is more
• Use modules

• Naming conventions? !important

• Structure and inform, naming conventions, grids

• Reduce, no inline styles, short chains, don't use elements, prefer classes over IDs

• Recycle and Reuse, Leverage the cascade, modularize page components, extend through sub classing.

Measure twice, Cut once.

Techniques for improving CSS

• Optimize Selectors
• Reduce the redundant
• Clear the cruft,
  • eliminate style that rely on qualifiers high in the domA
  • Create portable styles
  • Institute a Grid, box-sizing, make it fluid max-size: 100%
• Separate the modules into separate files.

New best practices

• normalize.css
• Use a better Clearfix
• Use an <hr> as a divider
• Image replacemenet
• Use an <i> as an icon element.

Less, the Path to Good Design, Sandi Metz

• The Design is the Code
• Code need to work once and be easy to change forever
• The purpose of design is to minimize the cost of change.
• Loosely coupled, highly cohesive, easily composable, context independent
• Transparent, Reasonable, Usable, Exemplary
• Design is never perfect, the code is never done.

• Done is good enough!

• Sequence diagrams are great for object oriented design.

• Managing dependencies is at the center of design.

• The objects of which you are most uncertain are probably the ones that are at the center of design, they are your core objects.

• Uncertainty, shows you where to decouple.

• Trustworthy objects knows more of what they want and less of what others want.

• Practical Object-Oriented Design in Ruby

Typescript, Mads Torgerson

Typescript is a typed superset of Javascript that compiles to plain Javascript. It adds optional static types, classes, and modules. It compiles to idiomatic Javascript.

The type system

Being a superset means that raw Javascript is allowed in Typescript. Since typing is optional errors should be seen as warnings. The language supports type inference which gives you type safety without declaring all variables.

The biggest advantage of the static typing is that it gives good code completion. The type system is structural, similar to Go, and that allows duck typing like calls. It supports optional properties so it is more about guiding you than forcing you to follow strict rules.

The functions in Typescript supports overloading, i.e. foo(x: string) and foo(x: number). Functions can be declared to have properties.

It is also possible to declare index accessors [] on the objects, declared like this.

foo = {
  [x:string]
}

Typescript supports type inference on the built in Javascript objects by means of declare files provided by the IDE.

Classes and Modules

Classes in Typescript follows the Ecmascript standard, and adds types, privates and statics.

class Greeter {
    private greeting: string;
    constructor (message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
    static default = new Greeter('Hola');
}   

var greeter = new Greeter("world");

Typescript also supports lambdas => and it provides lexical scoping of this similar to what Ecmascript will provide

Modules

Modules are declared with the module keyword and export properties explicitly.

module Sayings {
    export class Greeter {
        greeting: string;
        constructor (message: string) {
            this.greeting = message;
        }
        greet() {
            return "Hello, " + this.greeting;
        }
    }
}
var greeter = new Sayings.Greeter("world");

Datomic, Tim Ewald

Fact, an event or thing known to have happened or exists Datoms, a tuple with entity, attribute, value, time

Everything can be encoded by datoms.

A collection of facts

• An append-only model
• Data is immutable
• Database state at given time is a value

Datomic Architecture

• Separate read, write, and storage.
• All apps reads from a local cache.
• A transactor supervises the writes and reflects it out to the peers.

Reading

• Read / query db value in the peer.
• Long-running work on consistent image.
• Opening query to clients with bulkheads
• Cross-database joins

Query

• Datalog-based query language
• Can invoke code
• Can define views using rules
• Can invoke application specific code
• Supports querying the past and a possible future.

Direct Access

• Entity Maps
• Direct Index Access via iteration

Writes

• Writes managed by transactor, single point of failure
• True ACID semantics, transactor functions can be stored in the database.
• Reified transactions can be queried as normal data.
• Transaction notifications can be listened to by the peers.
• Transactions return db-before, db-after, tx-data, tx-id

Storage

• mem, dev, ddb, sql, infinispan, riak, couch, etc.
• Pick a service that provides the scale and availability you need
• Migrate as needed with backup and restore.