Daily Archives: February 20, 2020

[2020 devnexus] afternoon keynotes

Posted on by
Reply

For more, see table of contents

Decoding the weather – Kait Parker

@weatherkait

  • IBM owns the weather company and app
  • IBM GRAF –  Global High-Resolution Atmospheric Forecasting System 
  • Weather is big business – lost productivity, spikes in sales, inciting new innovation, damage impact
  • Can lost half a billion dollars in a single snowstorm in Boston
  • Whereas a city like Atlanta shuts down for snow
  • Naual disasters increasing – both climate change and not building smart
  • Weather is data
  • Weather company has largest collection of weather data in the world
  • APIs for current data and forecasts
  • US had good technology for weather. Whole world does not.
  • GRAF – more precise, faster refresh, uses 400 GPUs on 90 IBM servers
  • Future: add sensors on planes
  • #CallForCode – international challenge for developers to mitigate impact of natural disasters
  • Project Owl won in 2018. For addressing communication when cell phone towers go down. Creates mesh network based on wifi to gather info of who needs help. Smallest nodes are duck links. They are linked to mama duck. A drone connects to papa duck which connects to first responders.
  • Team Promoteo won in 2019. Monitors first responders. Wear a device. Tracks current conditions and trends.
  • 2020 competition starts February 26

Dehuman Future – Ixchel Ruis

  • EM-DATE – international disaster database

(I had to leave before this one ended as I’m on the podcast the starts after the keynotes. Too bad. Ixchel is a great speaker)

[2020 devnexus] synchronized is obsolete

Posted on by
Reply

Speaker: Enrique Zamudio

For more, see table of contents

Classes

  • AtomicInteger
    • incrementAndGet()
    • compareAndSet()
  • AtomicReference
    • updateAndGet()
  • ConcurrentHashMap – methods on Map, but happens atomically
    • computeIfAbsent()
    • merge()
  • ConcurentSkipListMap
  • ConcurrentSkipListSet
  • LinkedBlockingQueue
    • Can take elements and deliver elements concurrently.
    • Every element delivered to exaclty one consumer
    • Unblocks consumers as long as something in queue
  • Locks – Lock, ReadWriteLock, ReentrantLock, CountDownLatch, CyclicBarrier, Semaphore, Phaser
    • ReentrantLock – execute code if can acquire lock
    • lock()
    • tryLock()
    • tryLock(10, SECONDS)
    • unlock()
  • Akka – project that implements Actor paradigm
  • vert.x – project for reactive – do things in single thread
  • Project Loom – lightweight threads. I thread takes 100MB just to exist; Project Loom is more like 2KB. Also no context switching.

Multiple processes

  • multiple copies of your jar
  • multiple vms with load balancer
  • synchronized or lock fails because each process can run code at same time
  • Can use database select … for update in database transaction so outside your process.
  • Similarly can use redis to set a lock with a random value. If the value matches, you know the lock is yours. If JVM crashes, lock stays. Can add lock timeout to avoid this
  • FencedLock – developed by Hazelcast Raft consensus model.

My take

I feel like I re-learn this topic every time I read the chapter in our book. (Scott wrote the chapter). I’m glad I went to this session. The more times I hear this, the more sticks. I had forgotten the project loom info so was definitely good to hear that again. The part about multiple processes was mostly new to me. (I just new about select for update)

[2020 devnexus] metrics that matter

Posted on by
Reply

Speaker: Joel Tosi @jdojoandco

For more, see table of contents

General

  • Finishing on time doesn’t matter if do wrong thing
  • Can’t just say happy; need to know how much costs
  • Who cares about metrics: managers, product owners
  • People tend to measure what is easy to measure
  • Goal is to make people happy (and make money)

Bad metrics

  • # people trained as measure of agile transformation
  • measuring just a piece. Doesn’t matter how fast deploy if deploying wrong thing. Sub-optimizing

Simple metrics

Good place to start if have no metrics now. (but not always good metrics)

  • Number of defects
  • Velocity
  • Lines of code
  • Number of teams (not x% transformed b/c y teams have done it)
  • Code coverage. (bad if game system: ex: tested all getters/setters to increase)

Notes

  • Easy to collect
  • Doesn’t tell customer impact, right or usable
  • If don’t have insight, can help

Directional Metrics

Take time to capture

  • Increase in code coverage
  • SQALE (from Sonar)
  • Reduction in % of defects
  • Cycle time
  • Deployment frequency
  • Average time a bug takes to get fixed
  • Number Checkstyle violations over time
  • Size user base

Notes

  • More sustainable. Ensures not killing team in meantime
  • More depth
  • Still not measuring impact to users

Impactful/Economic Metrics

  • Reduction of cycle time for a delivery that mattered
  • Systemic cost reductions
  • Stopping bad ideas

Notes

  • How do we get rid of noise in the system
  • People need to agree to do these types of metrics
  • Need psychological safety. Must be safe to be wrong

Process Behavior Charts

  • You deliver value with a system.
  • A stable system will continue to deliver outputs within a range if you do nothing different.
  • Goal is not to react to noise.
  • Process Behavior Charts help separate signal from noise
  • Need to understand what measuring
  • Chart data in a time series
  • Calculate the moving average
  • Calculate the upper/lower bounds by multiplying by 2.66
  • Introduce change and continue to measure

Supporting Knowledge Work

  • Better decisions if faster access to info
  • Onion – team, manager(s), business, execs. Who can answer a question. How many levels need to go through

Books

  • Measures of Success: React Less, Lead betteer, Iprove More – Mark Graban. Covers health care.
  • Understanding Variation – The Key To Managing Chaos – Donald J Wheeler. Explains why 2.66 and more complex charts
  • Principles of Product Development Flow – Donald G Reinertsen

My take

Good talk. I like the interactivity to supplement the slides. I was thinking it would be more concrete. But I liked what it was actually about. I hadn’t seen process behavior charts before and found that particularly interesting.