slides

z, ?	toggle help (this)
space, →	next slide
shift-space, ←	previous slide
d	toggle debug mode
## <ret>	go to slide #
c, t	table of contents (vi)
f	toggle footer
r	reload slides
n	toggle notes
p	run preshow
P	toggle pause

loading presentation...

Surviving Software Development

Who we are

Trabe

Men at work

Shiny happy opinionated people

Ideas
Tools
Real life problems & solutions
The many hells of Computer Science

Ideas

A good design is easy to change, rather than easy to configure

someone, somewhere

There is no silver bullet

Every architecture/design solution has pros & cons

Architecture & technology should fit the problem

Simple is better

Simple solutions are easier to:

grasp
design
code
document
mantain
evolve

Architecture: the UNIX way

Orchestrate simple components, each doing one thing,
and doing it well

Design: SOLID rock

KISS & DRY driven

S = Single Responsability

A class should have only a single responsibility

O = Open/Closed

Open for extension. Closed for modification

L = Liskov Substitution

objects in a program should be replaceable with
instances of their subtypes without altering
the correctness of that program

I = Interface segregation

Many client-specific interfaces are better than
one general-purpose interface

D = Dependency inversion

Depend upon Abstractions. Do not depend upon concretions (i.e. Dependency injection)

We are always SRP driven

You should be too

SOLID leads to Design Patterns

(Designs patterns are SOLID)

Be OO, my friend

Other useful buzzwords

YAGNI
CoC

<action path="/admin/ShowConfiguration"
  type="controller.admin.ShowConfigurationAction"
  scope="request">
  <forward name="success" 
           path=".admin.ShowConfiguration"/>
</action>

Y U NO admin.ShowConfiguration

TEST, TEST, TEST

TDD, BDD
Regresions
Benchmarks
DI
Refactoring
CI

TEST, TEST, TEST

Complex test
↓
Bad design
↓
Refactor & DI
↓
Better design. Better API

Every time god kills a kitten

Tools

The Trábico process

Agile, sort of : )

Tools

Continous improvement. Always trying new stuff : )

Project development

TDD
Code reviews
Pair programming

Trello

Git

Bitbucket README

Bitbucket Pull Request

Bitbucket Pull Request Diff

Confluence

conventions
automation
scripts
bootstrap

$ git clone trabe:awesome-project
$ cd awesome-project
$ ./bin/setup

TESTs, TESTs, TESTs

Automatic run (guard)
Mocking
Metrics (coverage)

Conveniences

Transpilers: CoffeScript, SASS, etc.
Debugging tools
Live Reload. YAY!

Chrome tools

Real life problems & solutions

Context

NeoSAI

A Laboratory Management System

NeoSAI design

Problem

Different kinds of UIs

Solution

Basic CRUD: forms & listings
Advanced CRUD: JS components + AJAX
Complex tasks: Single-page app + REST

WTF are REST APIs?

Theory
duh, duh, duh (and more bullshit)
Practice
way to comunicate apps/systems through HTTP

WTF are REST APIs?

URIs
HTTP verbs
HTTP Status codes
JSON params/response (or XML or whatever)

GET https://api.twitter.com/1/users/show.json?screen_name=trabe


  {
    "id": 6253282,
    "name": "Trabe",
    "location": "A Coruña, Spain",
    "followers_count": 3000000
    ...
  }

Problem

Run the same business logic from different places

Solution

Context objects

Runnable from app controllers,
API controllers, cron jobs

class CreateUserContext
  def initialize(user_params, notifier)
    ...
  end

  def run
    user = User.new(user_params)
    if user.save
      notifier.send(:new_user, user)
    end
  end
end

Problem

Run business logic as different users, even as no user

Solution

Context objects
Runnable as user
NullUser (NullObject pattern)

NullObject pattern

Remove branching logic
Avoid null errors
Improves testability

    class User
      constructor : (name) ->
        this.name = name

    greet = (user) ->
      if user
        alert "Hi #{user.name}!"
      else
        alert "Hi stranger!"

    john = new User('John')
    keith = null

    greet john    # Hi John!
    greet keith   # Hi stranger!

    class User
      constructor : (name) ->
        this.name = name

    class Stranger extends User
      constructor : ->
        super 'stranger'

    greet = (user) ->
      alert "Hi #{user.name}!"

    john = new User('John')
    keith = new Stranger()

    greet john    # Hi John!
    greet keith   # Hi stranger!

Problem

Complex permission checks

Can change a report if I am the author or its author is one of my subordinates and the report has not been signed

the customer

Solution

Policy objects


class ReportsController
  def edit
    report = Report.find(params[:id])
    can_edit = ReportEditorPolicy.
      new(current_user, report).comply?
    ...

class ReportEditorPolicy < Policy
  def initialize(user, report)
    ...
  end

  def comply?
    (owner_of_report? or
    subordinate_report?) and
    unsigned_report?
  end

  ...

Problem

User role based behaviour

Solution

Inject user with
role dependent methods
State pattern (sort of)

User roles

Problem

Present same model object in different ways on different views

Solution

Decorator pattern
Decorate associations too
One or multiple decorators
Variant: presenter pattern

class User
  def initialize(name, email)
    ...
  end
end

class UserDecorator
  def initialize(user)
    ...
  end

  def name
    user.name
  end

  def email
    user.name + "<" + user.email + ">"
  end
end

user = User.new('john', 'john@mail.com')
decorated_user = UserDecorator.new(user)
mail = new Mail()

mail.send to: decorated_user.email

Problem

Global search

Solution

External Indexer (REST API)

Indexer

The many hells
of Computer Science

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

Easy cache invalidation

LRU Caches + Auto expiring keys


  class User
    def cache_key
      "user#" + id + "#" +
        updated_at.to_millis
    end
  end


  cache user.cache_key do
    ...
  end

Easy naming

There is no easy naming. Sorry folks!

Yao Ming

Maybe there are more hard things

Mother of God

Encoding hell

Use UTF-8

Encoding

Timezones, i18n, l11n, Accessibility hell

Always use UTC :D

Treat i18n, l11n and accesibility as first class citizens

Beware of software/tools/libraries quirks


  # DB stores UTC. Conversion done by Rails
  r = Report.first
  r.created_at # => 2013-11-06 00:00:00 +0100
  r.created_at.utc # => 2013-11-05 23:00:00 UTC

  Report.where('DATE(created_at) = ?', 
    r.created_at.to_date)

  # Ooooopppps!
  #
  #  SELECT * FROM reports
  #  WHERE (DATE(created_at) = '2013-11-06')

A test should have
detected the defect ;)

Fuck timezones

The money hell

Beware of spanish taxes and accounting

Use f**king cents

The money hell
a.k.a the floating point hell

Stick to integers. Use fixed point

Show me the money

Deployment and
environments hell

Define enviroments from square one

Automatize deployment as much as you can

Mina deploy

Migration hell

Data evolves along your code

Use some way of control/script/automate migrations

i.e. RoR migrations, Flyway for Java


add_column :invoices, :report_id, :integer

Invoices.find_each do |invoice|
  order = Order.where(number: invoice.order_number)
  invoice.order = order
end

Beware of data massaging

Either complex or simple ¬¬


add_column :invoices, :report_id, :integer

Invoices.find_each do |invoice|
  order = Order.where(number: invoice.order_number)

  raise "Fuck" if order.client_id != invoice.client_id

  invoice.order = order
end

Documentation/Code sync hell

Self explanatory code (DRY)

Document APIs

Document wisely

Treat documentation as part of the code


/**
 * Returns the user names in alphabetical order
 * @returns the names
 */
public String[] orderedNames() {
  return sortAlphabetically(this.getNames());
}

/*
 * Sort with quicksort algorithm
 */
private String[] sortAlphabetically(String[] words) {
  // lines of elegant yet uninteligible code ;)
}

Multithreading hell

Use multi process

Avoid too much low level

Inter Process Communication

Unix Sockets
Queues
Shared memory

Or use a library!

Or switch to erlang :P

Fragmentation hell

Do your HTML5/CSS3/JS homework
SOLID also applies (SMACSS, etc)
Know how to tame browsers
Know how to tame mobile

Bitbucket Ok

Bitbucket full

Bitbucket Android

MVC Inception hell

Inside an webapp MVC there is another MVC

There are many more hells

Integration, legacy management, and so on

You'll discover them in time T_T

Parting note

SOLID (SRP in particular)

↓
Simple
↓
Easy to change
↓
Happiness \(^o^)/

YAGNI

↓
Simple
↓
Easy to change
↓
Happiness \(^o^)/

TESTs, TESTs, TESTs

↓
YAGNI + SOLID
↓
Simple
↓
Easy to change
↓
Happiness \(^o^)/

Refactor, Refactor, Refactor

(code and tests)

↓
Better code & tests
↓
...
↓
Happiness \(^o^)/

DRY more than your code

Automatize, share, extract

Read and write

Hasta la vista baby

Complementary reads

http://ir.gl/trabe-reads

Questions?

Do your PFC at Trabe

.

..

...

Encore

It's up to you

More about NeoSAI

the Laboratory Management System

Problem

Integrate new & legacy app

Solution

Shared DB
REST APIs (JSON preferred)
SSO
UI integration via IFrame +
HTML5 PubSub

SAI Integration

Problem

Integrate "nonintegrable"
third party software

Solution

Ad hoc REST API
Mail vacuums

testo_wamp

Problem

Mail log: different sources

Solution

Wrapper + REST API

Mail wrapper

Problem

Long running contexts

Solution

Execute contexts in background
Jobs queues
Jobs executor

Background Jobs

FEDERICO

Application integration

a.k.a. real life hitting your groin

Problem

Signup/signin on multiple services

Consolidate personal info

Solution

Procedure repository
Orchestrate services (Service Bus)
Single Sign On

Federico ideal

Federico full

Technology

Java stack
Ruby for automation

DCI

Data, Context, Interaction

class BankAccount
  attr_accessor :balance
end

module TransferSource
  def withdraw(amount)
    self.balance -= amount
  end
end

module TransferTarget
  def deposit(amount)
    self.balance += amount
  end
end

class TransferContext
  def initialize(source, target, amount)
    ...
  end

  def run
    source.extends TransferSoure
    target.extends TransferTarget

    source.withdraw amount
    target.deposit amount
  end
end

DCI

SRP
Reusability
Testability
Best with dynamic langs
Beware of implementation quirks

Hasta la vista baby

Surviving Software Development

Shiny happy opinionated people

Contents

Ideas

A good design is easy to change, rather than easy to configure

someone, somewhere

There is no silver bullet

Every architecture/design solution has pros & cons

Architecture & technology should fit the problem

Simple is better

Simple solutions are easier to:

Architecture: the UNIX way

Orchestrate simple components, each doing one thing, and doing it well

Design: SOLID rock

KISS & DRY driven

S = Single Responsability

A class should have only a single responsibility

O = Open/Closed

Open for extension. Closed for modification

L = Liskov Substitution

objects in a program should be replaceable with instances of their subtypes without alteringthe correctness of that program

I = Interface segregation

Many client-specific interfaces are better thanone general-purpose interface

D = Dependency inversion

Depend upon Abstractions. Do not depend upon concretions (i.e. Dependency injection)

We are always SRP driven

You should be too

SOLID leads to Design Patterns

(Designs patterns are SOLID)

Other useful buzzwords

TEST, TEST, TEST

TEST, TEST, TEST

Tools

The Trábico process

Agile, sort of : )

Tools

Continous improvement. Always trying new stuff : )

Project development

TESTs, TESTs, TESTs

Conveniences

Real life problems & solutions

Context

NeoSAI

A Laboratory Management System

Problem

Different kinds of UIs

Solution

WTF are REST APIs?

WTF are REST APIs?

GET https://api.twitter.com/1/users/show.json?screen_name=trabe

Problem

Run the same business logic from different places

Solution

Context objects

Runnable from app controllers,API controllers, cron jobs

Problem

Run business logic as different users, even as no user

Solution

NullObject pattern

Problem

Complex permission checks

Can change a report if I am the author or its author is one of my subordinates and the report has not been signed

the customer

Solution

Policy objects

Problem

User role based behaviour

Solution

Problem

Present same model object in different ways on different views

Solution

Problem

Global search

Solution

The many hellsof Computer Science

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

Easy cache invalidation

LRU Caches + Auto expiring keys

Easy naming

Orchestrate simple components, each doing one thing,
and doing it well

objects in a program should be replaceable with
instances of their subtypes without altering
the correctness of that program

Many client-specific interfaces are better than
one general-purpose interface

Runnable from app controllers,
API controllers, cron jobs

The many hells
of Computer Science

A test should have
detected the defect ;)

The money hell
a.k.a the floating point hell

Deployment and
environments hell

Integrate "nonintegrable"
third party software