JavaSelf Reliant Systems

Björn Granvik

Self Reliant SystemsIn Code, In Process, In Moment

Björn GranvikCTO, Jayway

Enclaimer

§ The information in this presentation has been painfully gathered through experience.

§ Events and characters are purely based on reality. However, names of the innocent and the guilty have been changed in order to be nice.

§ Programmers have been hurt during these experiments…

Toyoda and His loom

30:1 - looms:personsStop the line!

Our Reality?

Me

Project'sTest server

Test'sTest server

Stagingserver

Productionserver

Productionserver 2

Productionserver 3

LoadBalancing

Joe

Mr Smith

SAD

UCR

TES

GKW

Stop the line?

Coding

Anything that changes the behavior of your system.

.properties"parameters"Admin console, tweaking the productionLoad balancers, pools, indexes, …

…programming

The Problem

The Guild

Stuck in craftsman mode Almost all parts are "made to order"

Impossible to replicate the systemImpossible to "know" the systemMonday morning – every morning, every dayIT medieval ages

Symptom: Whazzup?

Symptom: More Whazzup!

Symptom: Running?

Q: How do you know if your system is working?

Surf to your web site/application.Try something. Does it work?Check memory/processes/portsCheck log filesCheck GKW

…now what? - Wake the programmer!

Symptom: Compile?

BackupContinuous IntegrationContinuous Feature Creep…

Q: Five years on, does your code compile?

…now what?– Buy single malt, call the programmer!

Symptom: Change Spec?

Search for keywords in codeCheck for unit tests…

Q: Changed specification – what do you do?

…now what? – Change and Pray.

Why not analysis/reports?

Some are needed but...

Word etc cannot be verifiedAlmost all are wrongWe've tried that…

Exercise: Read any project document and see if it is correct.Conclusion: We cannot rely on them.

Why not tools?

Only answers general questionsCatch 22The tooling industry Tool vs. product: 10x precision!

We – the IT Industry 2xs …Yeah right!

Exercise: Compile your colleagues project…Conclusion:

We must build our precision/knowledge into our components!

Theory

The Line …in theory

Any feedback oriented system will either adapt and succeed - or fail fast.

The Component …in theory

What to do …in theory

Build it inFeed it backPay it forward

In Code

Word is Evil!“Coding" beyond developer's machine is Evil.

Put it all there into the componentSelf Testing Requirements Healing …

Component should adapt

In Process

Not in process automatically forgottenAutomatic & repeatableFeedback Oriented

In Moment

Do the job in the moment Where all knowledge is there All the developers are present

programmers, testers, business analysts, etc

Code like you will be gone after three iterations

Examples

NO!

Example -1: Where's that lib?

Yes

Example 0: Logging

Trivial! But forgotten.Think "production and runtime", not just development

What to do: Use your favourite logging framework Log to correct level

Info – important info and state changes Debug – well, just debug info

Log appropriately per machine/situation/etc

Example 1: Testing

Testing - from unit to acceptance level JUnit, TestNG DDSteps ...and many more

New: Deploy the code with this ability Self test in production

Use Case PingUCC – Use Case Coverage

Example 2: Running?

Make it easy to decide if your system is up and runningNew: Is it installed properly? Is it up and running? Dead easy to spot a (non)working system! Easy to spot level of problem Less calls to second/third level of support

Example 2: Running!

Use Case Ping

Process

Sockets

Memory

.

.

....

Dependent Systems

Example 3: Dynamic Components

OSGi etcRuntime is conquered!Hot deploy in architecture, not just for monolithsEach module should contain: Function, i.e. Code (F) Logging (L) Health Check (HC) Tests (T)

From unit up to acceptance Use Case Ping and Use Case Coverage

Agile Requirements (AR) …

Example 3: Dynamic Components "Screenshot"

A is-integration-tested with BA depends-on BA part-of B

foo

bar

My Phone

Gone

BigSystem

Example 3: Dynamic Components cont'd

Metadata Runtime, test time, compile time dependencies Licenses Interface compatibility

Lots of it, but not usedCould be used for versioned build and development system meta info possibly machine searchable via POM, RDF etc Discovery mechanism for components ...

Example 4: Agile Requirements

Nuked RequirementsImpossible to traceChanged req - Which code changed?

Do references Findable in code

Do 1:1 relationship Refactorable Codable/compilable Runtime support

Example 4: AR Example

//REQ specB#123@requirement(uri="req:custA.prod3.specB#123")Still not in one place

Unit TestsRequirement, RequirementManager

Example 4: AR Aspect

@Aspectpublic class ColorMustBe256Requirement {

@Around("execution(* se.jayway.color..foo(Color))")public Object invoke(ProceedingJoinPoint pjp)

throws Throwable{

// ...Do some check on Color

Object result = pjp.proceed();return result;

}}

Self Reliant Systems

In CodeIn ProcessIn Moment

Build it inFeed it backDo it when you still can

Self Reliant Systems

Q & A

Remember! Enter the evaluation form and be a part of making Øredev even better.

You will automatically be part of the evening lottery

Self

//more

Based on the component, not on the tool

Feedback speeds

Feedback Is crucial!

Fast Feedback Minutes Continuous integration

Furious Feedback Seconds Pair Programming Continuous Compilation (IDE)

The faster feedback, the faster success or failure

Spot the Signs!

Java 6: Monitor and debug always "present" jhat – analyze heap jconsole …

Trifork P4, a profiler – use it in production//moreCustom monitoringSelf test

Codex Hammurabi

Hammurabi, King, Mesopotamia Circa 1700 BC

LawBoth law and houses still here