9.00am Java Community Keynote [KEY7694]
IBM demo of an application on technologies and announced open-sourcing OpenLiberty and Open J9
The usual silly antics with lots of community onstage. This year based around the Matrix. Good to see the cool JavaOne 60Pi cameras to create the Matrix style 360 panorama. No James Gosling this year….
11.00am From Functional to Reactive Programming [CON7319]
Reused lots of material from previous talks to show functional programming
Aim with Lambda is always to be lazy
Java does not apply functions to whole Collection (would hit performance) but smarter
Java assumes lambda pure (so make sure it is).
Functional about moving away from how, just what
Excel example of real time programming
Last 20 years we have lived in Crud
Reactive si elastic, message-driven, responsive and resilient
Always think of what might fail – unhappy path
Stream has single channel unlike Observable (data, error, complete)
12.00am Cloud-Based Test Microservices [CON2789]
Aim to replace old monolithic.
Why both on micro services and why on cloud?
Micro-service is succinct API to accomplish particular task
Benefits: modular, Simpler, Portable, Customised
Test Generation service useful to automate tests
Make it easy to run any test as a benchmark
1pm Migrating to Java 9 Modules [CON1455]
Finally define dependencies explicitly and encapsulate
Even if your code not modularised, j9 is
Demo of issues with existing code and updating to work using –add-modules
Illegal deep reflection warnings (typing to access JDK types). Will become errors in future
Automatic modules – non-modular jar file which we move from class path to modulepath. V. useful for library.
module-info.java contains key module data
requires may need adding to find missing values defined in imports
Firstly refactor code to 1 module and then refactor code to multiple modules
2pm Twelve Ways to Make Code Suck Less [CON7324]
There are What, when, how and why people
Why should we care? We cannot be agile if our code sucks
Code is how we tell our colleagues how we feel about them.
Lower quality = longer dev time
Code great because you wrote it?
Quality of code inversely proportional to effort it takes to understand
12. Schedule time to lower technical debt
Freeway filled with cars is a parking lot – we always need wriggle space (linda Rising)
You need slack time or you will never innovate
Book: Guns, germs and Steel – Jared Diamond
11. Favor high cohesion
Narrow focused, does one thing well.
Think about frequency of change.
high cohesion == low cyclomatic complexity
10. Favor Loose coupling
9. Program with intention (no accidental coding). Avoid working in desperation
When Wrote this code only God and I knew what it does. Now only God knows…
Kent Becks rules for simple design:-
a) Passes all tests
b) Reveals intention
c) No duplication
d) Fewest elements
8.Avoid primitive obsession
Am I the chosen one? If general purpose, someone else was chosen long ago – use their code.
Imperative code is packed with accidental complexity
Programmers smartest people on planet as always say it looks good, not its correct
Good code is a story not a puzzle
7. Prefer clear code over Clever code
Optimise for reading
Sacrifise quality to get performance may be get neither
6.Apply Zinsser’s principle on writing
Book:- On Writing well – william Zinsser
Simplicity, Clarity, Brevity, Humanity
5. Comment Why, not what
Don’t comment to cover bad code. Refactor
Write expressive, self-documenting code
Code code is like good joke (should never need explaining). Refactor until it works
Those who can’t design are condemned to document
4. Avoid long methods – Apply SLAP
Perils of long methods. Problem is levels of abstraction
3. Give good meaningful names for variables.
2. Do tactical code reviews
Write tests when you find bugs
Tell them what to do, not what is broken. Give them some options.
1. Reduce state & State mutation
Let go of idea We can code it once and get it right
3pm Optimizing Java with Linux Perf [CON1879]
Performance = money. Cheaper to optimise than buy new hardware
Linux Perf demo with counters, tracepoints and sampling
perf list gives very long list of events and probes (2K or so)
Perf map give info on JIT code perf..map file for compiled methods
Created with perf-map-agent after running perf record
Then use perf report (also Flame graphs or hotspot tool)
Perf also has JIT Dump
Latest posts by Mark Stephens (see all)
- My experience of a Turkish bath (visiting Istanbul for DevFest) - November 24, 2017
- My 5 key takeaways from JavaOne 2017 - October 6, 2017
- My notes and pictures from thursday JavaOne 2017 - October 5, 2017
- My notes and pictures from Wednesday JavaOne 2017 - October 5, 2017
- My notes and pictures from Tuesday JavaOne 2017 - October 4, 2017