Self Reliant Systems
-
Upload
bjoern-granvik -
Category
Technology
-
view
69 -
download
0
description
Transcript of Self Reliant Systems
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