2 DAY CONFERENCE

YOW! 2018 Brisbane

Topics covered at #yow18
architecture discovery mobile-&-iot quality engineering ai-&-ml cloud mobile-&-web performance-&-security big-data architecture-&-design people-&-process languages

Monday, 3rd - Tuesday, 4th December in Brisbane

35 experts spoke.
Overview Programme SkillsCasts Other Years
Overview

YOW! Conference is designed by developers for developers, and each speaker has been invited because of their development expertise by our independent international program committee. At YOW! Conference you'll get straight tech talk by world-class experts and networking with like-minded developers.

Excited? Share it!

Programme

Live Coding the intersection between the Arts, Technology and Research

Live Coding systems encourage us to think extremely differently about programming languages. In addition to considering standard requirements such as reliability, efficiency and correctness we are also forced to deal with issues such as liveness, coordination and synchronization all whilst working in real time.

Live Coders not only run and modify code live — they often perform with it on stage in front of large crowds of people who really don't want the code to miss a beat. In this code and demo-heavy talk, Sam will introduce the motivation for Sonic Pi - a system designed specifically for live coding music - before taking a deep technical dive into the internal ideas and innovations. The audience will explore Sonic Pi's novel temporal semantics which allow multiple concurrent threads to execute in synchronization along with live hot-swapping of code.

Ultimately, everyone will discover an exciting area of programming language research in an approachable and instructive manner all whilst making some sick beats and drops.





Sam Aaron

Dr Sam Aaron is the creator of Sonic Pi, an internationally renowned live coding performer, public speaker and science communicator. Sam has a PhD in Computer Science and held a research position at the University of Cambridge Computer Laboratory where he initially developed Sonic Pi.

Sam regularly engages audiences of all ages and backgrounds with the creativity of code through keynotes, workshops and performances. He has live coded internationally featuring in the Royal Albert Hall, Berlin Warehouses, Music Festivals, on the BBC and even school assemblies. Sam has received two Google prizes for his Open Source work, was listed amongst Fast Company's "Most Creative People in Business 2020" and The Rolling Stone magazine described his Moogfest performance as “transcending the present”.


Neural Nets From The Ground Up

The best way to understand neural networks is to get your hands dirty and write one.

In this session, we'll start from scratch and invent a neural net that can recognize handwritten digits with over 98% accuracy. Without leaning on any libraries! From the bottom up, we'll discover gradient descent, activation functions and backpropagation, as well as the mathematics behind this fascinating machine learning technology.

We'll code entirely in C# in a lightweight IDE (LINQPad). And you'll get to keep the code!



Joe Albahari

.NET Developer
LINQPad


Big Data, Fast Data @ PayPal

PayPal processes more than $1B in payments every day, is an accepted method of payment in over 200 countries, and covers everything in the online payments ecosystem from issuing credit and debit cards, to supporting credit card & POS processing, facilitating checkout at online merchants, and making it easy for friends to split a dinner bill or resolve shared expenses. All of this convenience comes with the added security of some of the most advanced fraud prevention algorithms powered by huge repositories of data. Given the vast ecosystem that PayPal has been playing in over the past 20 years, PayPal has collected large amounts of payment transaction and contextual data relating to consumers, merchants, and products -- over 150PB of data to be precise. How does PayPal manage this massive amount of data while all the while extracting useful insights that can propel the business ever forward? Come to this talk to find out!



Sid Anand

Chief Architect
Datazoom


3X: Explore/Expand/Extract

Before you can evaluate a method, you have to understand its goals. Before you can evaluate a style of software engineering, you have to understand its goals. Quick execution of experiments? Rapid scaling in the face of unexpected bottlenecks? Sustained, profitable growth? Each goals requires a different style and yet we talk about software engineering as if it should be one thing.
This talk introduces 3X and the ways software development, quality assurance, design, management, financing, planning, and staffing change depending on the goal of development.


Kent Beck

“For each desired change, make the change easy (warning: this may be hard), then make the easy change.”

Kent Beck hates writing biographies. Guitarist, singer, storyteller, walker, poker player, programmer, artist. Original signer of the Agile Manifesto, author of the Extreme Programming book series, rediscoverer of Test-Driven Development, and inspiring keynote speaker. Helps geeks feel safe in the world.


Is the 370 the worst bus in Sydney?

In Switzerland, people will be surprised at a bus that's 2min late. In Sydney, people will only consider it noteworthy if a bus is more than 20min late, and this varies greatly between routes and providers. So, how do Sydney bus routes stack up? And if we're talking about privatisation, how do the private bus providers stack up against the state busses?

To answer these questions we need data… lots of data. Hooray for open government data! Transport for NSW publishes real-time information on the location and lateness of all public transport. Unfortunately it's ephemeral – there is no public log of historical lateness for us to analyse. To gather the data I needed I had to fetch, log and aggregate ephemeral real-time data that was never intended to be used this way. There are random gaps and spontaneous route or timetable changes for special events, roadworks or holidays. Even with noisy data, the patterns start to emerge across months and we can start to answer some questions. The 370 bus route is one of the most complained about routes in Sydney, it even has it's own Facebook group of ironic fans... but is it really the worst bus? Let's look at the data.



Katie Bell

Freelance Developer
Independent


Kubeflow Explained: NLP Architectures on Kubernetes

There's more to a Natural Language Processing (NLP) application than an ensemble of models. Much more! Like any traditional application, there is an entire ecosystem of supporting tools that enables core ML functionality. How do you choose the best ones? Which ones can you do without? How do you maintain context when the complexity of such a system gets out of hand?

In this session, you will learn how to deploy the full scope of an NLP application on Kubernetes with Kubeflow. The guiding principles of a robust and resilient system are explained and used as the foundation for defining a specific architecture. Techniques for modifying and maintaining it over time are described. Find out what Kubeflow currently supports and the long-term vision for the project, presented by a project contributor.



Michelle Casbon

Sr. Engineer
Google


Lessons learned building Kubernetes controllers

In this talk I'll discuss my experiences building Kubernetes controllers using as a case study Contour, a new Kubernetes Ingress controller, that I've been working on since joining Heptio.

This presentation will cover:

  • What an ingress controller is and what role it plays in a Kubernetes cluster.
  • Why Heptio chose Lyft's Envoy proxy as the data plane for our ingress controller.
  • How Contour works as a translator from Kubernetes to Envoy. The parts that were a good match, the parts that weren’t, and how we dealt with it.
  • How to develop a component of an interactive system like Kubernetes while avoiding the dreaded compile/push/deploy time sink.


Dave Cheney

Staff Systems Engineer
Heptio


The Importance of Laughter

In software development, we strive for inspection and adaptation. In order to make the best of this, we have to feel good about ourselves and with each other. Fun and laughter is something I have always tried to enhance in the places where I work, but only recently have I started looking into why it is helpful.
Diving into this subject, I was amazed by how big an impact fun and laughter can have on your social life, your wellbeing, and your energy levels. Join me for a session with brain research, examples of fun, and case studies from real life. Bring an open mind and leave with knowledge about why you should have fun every day.


Aino Vonge Corry

Founder
Metadeveloper


BOSSA nova: Beyond Agile - Preparing for Digitalization

Today companies are expected to be flexible and both rapidly responsive and resilient to change, to both survive but also to thrive on disruptions. These challenges call for company-wide agility. Yet, doing Agile (the mechanics) is different from being Agile (the mindset). For example, substituting management meetings with daily Scrums or using a backlog for the board of directors doesn’t make a company agile.

In order to become truly agile (meaning flexible, responsive, adaptive, fast, and nimble), you need to think outside the (agile) box. Company-wide agility requires a holistic approach, a combination of different principles: First and foremost the principles of

  • Beyond Budgeting (flexible budgeting & relative targets),
  • Open Space (leveraging the innovative power of all employees),
  • Sociocracy (flexible organizational structures and decentralized decision making), and –of course–
  • Agile (inspecting & adapting).

We synthesized these proven principles into a wider perspective dubbed BOSSA nova: B = Beyond Budgeting, OS = Open Space, S = Sociocracy, A = Agile. Jutta will reveal a path toward company-wide Agility by showing the synthesis of BOSSA nova.



Jutta Eckstein

Jutta Eckstein is an independent coach, consultant and trainer from Braunschweig, Germany. Her know-how in agile processes is based on over ten years experience in developing object-oriented applications. She has helped many teams and organization


Code is Your Partner in Thought

We used to build software like bridges. There was time for careful collection of requirements and the analysis of design options. But we don't do that anymore, in part because the time we spent did not ensure we hit our targets or avoided risks. Today, most companies use some form of continuous design where the software changes in small steps, often weekly or even daily, which makes those companies responsive to environmental changes. The problem is that in just a few years the software becomes over-complicated and usually needs to be rewritten, even when the team refactors. The longer you let the team code, the worse the code gets. That's a shame because other kinds of engineering don't have this problem. Car engines, for example, improve every year. I'll primarily discuss some ideas about why things work out this way and also some promising ideas for how we can practice continuous design longer, if not forever.



George Fairbanks

Software Engineer
Google


Functional Composition

Chris Ford shows how to make music starting with the basic building block of sound, the sine wave, and gradually accumulating abstractions culminating in a canon by Johann Sebastian Bach. Examples live-coded in Clojure.



Chris Ford

Chris is a certified BABE (Bachelor of Arts, Bachelor of Engineering), and consequentially an idiophile and technophobe. He began to make music with code partly to compensate for his poor technique, and partly because air piano is unsatisfying. When he works, he works for ThoughtWorks, though that isn't all the time.


Building Evolutionary Architectures

An evolutionary architecture supports guided, incremental change across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This talk illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.



Neal Ford

Neal is Director, Software Architect, and Meme Wrangler at ThoughtWorks, a software company and a community of passionate, purpose-led individuals, delivering technology to address the toughest challenges, all while seeking to revolutionize the IT industry and create positive social change. He speaks at many conferences.


The Future of Software Development

From autonomous vehicles, 3D printed rocket engines, and “affordable” consumer-owned satellites to rapid advances in AI and secure, decentralized electronic currencies, the past several years have shown us that the only prediction we can confidently make about the future is that it will arrive more quickly than any of us imagined. Yet with all of these major technological advances, the way we develop, test, deploy, and manage software has been incrementally changing over the years. Many of the most forward-thinking paradigms, practices, and technologies are based on concepts and even implementations created decades ago.
How can software development itself benefit from the disruptive changes in technology in recent years? This talk will explore influences, tech trends and coming innovations which will change how we as an industry approach to software creation, maintenance, management, and even employment.


Chad Fowler

Chad is the co-founder of Rubycentral.com, a leading contributor to the Ruby community and author of various books on Ruby on Rails, including Rails Recipes.


What is 'this'? ¯\_(ツ)_/¯

Have you ever wondered what _this_ actually is, and how it relates to other JavaScript black magic, like prototypes or the _new_ keyword? Many frameworks have been designed to hide you from needing to fully understanding this and many related concepts.

In this session, Jake will dive into all of the above and will also cover how the new ES2015 language features like arrow functions, keywords like let, const and classes with constructor functions which make dealing with _this_ much easier to understand.



Jake Ginnivan

Jake Ginnivan is an Open Source Enthusiast, Blogger, Speaker, Microsoft MVP (VSTO) and a fan of good Beer & Whisky.


Cloud Performance Root Cause Analysis at Netflix

At Netflix, improving the performance of our cloud means happier customers and lower costs, and involves root cause analysis of applications, runtimes, operating systems, and hypervisors, in an environment of 150k cloud instances that undergo numerous production changes each week. Apart from the developers who regularly optimize their own code, we also have a dedicated performance team to help with any issue across the cloud, and to build tooling to aid in this analysis. In this session we will summarize the Netflix environment, procedures, and tools we use and build to do root cause analysis on cloud performance issues. The analysis performed may be cloud-wide, using self-service GUIs such as our open source Atlas tool, or focused on individual instances, and use our open source Vector tool, flame graphs, Java debuggers, and tooling that uses Linux perf, ftrace, and bcc/eBPF. You can use these open source tools in the same way to find performance wins in your own environment.
m


Brendan Gregg

Fellow
Intel Corporation


#NOCODE

For beginning programmers, coding is a superpower. But as we gain experience, code-centric thinking can become a trap. Prepare to have your conception of what it means to be a programmer challenged, as we explore how to increase your leverage by choosing NOT to write code.


Avdi Grimm

Head Chef
Ruby Tapas


1968

It’s half a century since the NATO Software Engineering conference in Garmisch. How are we doing? Are we nearly there yet? Or is there no there there?
The world of software development has changed so much and in so many ways since 1968 that it’s difficult to imagine what we could learn from the past, but it’s learning rather than imagination that’s the constraint. There was no shortage of imagination, insight and inspiration in the 1960s and 1970s, and in many ways the apple of 21st-century software development has fallen disappointingly close to the tree of the past.
So let’s turn back the clock to see what we could have learned from the past, what we can still learn from the past and what the future might hold in store for code and its development.


Kevlin Henney

Programming · Patterns · Practice · Process


Failure and Change: Principles of Reliable Systems

As we construct larger or more complex systems, failure and change are ever-present. We need to accept and even embrace these tensions to build software that works and keeps working.

This is a talk on building and operating reliable systems. We will look at how systems fail, particularly in the face of complexity or scale, and build up a set of principles and practices that will help us implement, understand and verify reliable systems.



Mark Hibberd

CTO
Kinesis


Shaving the Golden Yak

Programming is a series of frustrations. Everything we do, we could do better or faster if we only had our tools set up just so. If our error messages were a little better, our code a little cleaner, our tests a lot wider. When we spend time on this, it's known as "yak shaving," and it can get messy.

How do you balance the work you’re supposed to be doing with the work that makes your work, work? Dive into the yak stack with me. We'll see five different species of yak, and discuss how and when to tackle each one. At the bottom of the yak stack, we might find the Golden Yak, with secret wisdom engraved on its skin.

This session will give you reasons to spend time smoothing your development experience, and clues for where to spend that time in ways that help your whole team.



Jessica Kerr

Principal Developer Evangelist
Honeycomb.io


The Origins of Opera and the Future of Programming

There’s a story to tell, about musicians, artists, philosophers, scientists, and then programmers.

There’s a truth inside it that leads to a new view of work, that sees beauty in the painful complexity that is software development.

Starting from The Journal of the History of Ideas, Jessica traces the concept of an “invisible college” through music and art and science to programming. She finds the dark truth behind the 10x developer, a real definition of “Senior Developer” and a new name for our work and our teams.



Jessica Kerr

Principal Developer Evangelist
Honeycomb.io


Cloud, Containers, Kubernetes

Microsoft issued me a Mac when they hired me to help people use Linux on Azure. If this sounds like the beginning of a nerdy joke, it’s because we need to question long-held opinions, let go of deeply-cherished stereotypes, and welcome this new era of open collaboration.

Let’s take the 10,000 foot tour of today’s cloud, containers, and orchestration landscape before diving into specifics we can use when making calls on microservices, backing data stores, and app decomposition. We’ll talk public cloud, containers, and k8s from the “Open at Microsoft” perspective!



Bridget Kromhout

Bridget Kromhout is a Principal Technologist for Cloud Foundry at Pivotal. Her CS degree emphasis was in theory, but she now deals with the concrete (if ‘cloud’ can be considered tangible). After years in site reliability operations (most recently at DramaFever), she traded in oncall for more travel. A frequent speaker at tech conferences, she helps organize the AWS and devops meetups at home in Minneapolis, serves on the program committee for Velocity, and acts as a global core organizer for devopsdays. She podcasts at Arrested DevOps, occasionally blogs at bridgetkromhout.com, and is active in a Twitterverse near you.


How to Avoid the Top Ten Software Security Flaws

Software security defects come in two categories: bugs in the implementation and flaws in the design. In the commercial marketplace, much more attention has been paid to finding and fixing bugs than has been paid to finding and fixing flaws.That is because automatically identifying bugs is a much easier problem than identifying design flaws. The IEEE Center for Secure Design was founded to address this issue head-on. My presentation will cover the IEEE CSD’s first deliverable by introducing and discussing how to avoid the top ten software security flaws. The content was developed in concert with Twitter, Google, Synopsys, HP, Sadosky Foundation of Argentina, George Washington University, Intel/McAfee, RSA, University of Washington, EMC, Harvard University, and Athens University of Economics and Business. During the talk, I will introduce and discuss how to avoid the top ten software security design flaws. It's important, of course, to know that these flaws account for half of the defects commonly encountered in software security. But more important still is learning how to avoid these problems when designing a new system or revisiting an existing system.



Gary McGraw

Vice President of Security Technology
Synopsys


Grinding the Monolith

Microservices sound appealing, but what can we do with those ten-million-line code bases? Shared domain objects, horizontal coupling, and years of boundary erosion have left us with enormous complexity and spiderwebs of coupling. Michael will share techniques at various levels of abstraction, from implementation details to API design and responsibility allocation. There’s no silver bullet that will make it easy to decompose a monolith, but you’ll learn some techniques that have helped and some pitfalls to avoid, all based on Michael's experience with both successful and failed transformations.



Michael Nygard

SVP, Platform & Architecture
Sabre Corporation


Why Great Leaders Must Unlearn to Succeed in Today’s Exponential World

Effective leadership comes with a large learning curve. In today’s rapidly-evolving business climate, this is more true than ever for seasoned leaders and entrepreneurs alike.

Many leaders rely too heavily on past achievements, practices, and ways of thinking to drive positive business results today, but they often need to unlearn those behaviors before they can take a step forward.

Join executive coach Barry O’Reilly as he breaks down a transformative framework that shows leaders how to rethink their strategies, retool their capabilities, and revitalize their businesses for stronger, longer-lasting success.



Barry O'Reilly

Barry O’Reilly is a business advisor, entrepreneur, and author who has pioneered the intersection of business model innovation, product development, organizational design, and culture transformation.


Automatic Programming How Far can Machines Go?

Program synthesis is the wild west beyond code generators and onward toward self-programming systems. What can it do for us? The answer, right now, is not a lot. It can harness the wisdom of the crowd to help reproduce scenarios that are repeated often, and in narrow scopes tools can make educated guesses about what the programmer intended, but full automatic program synthesis is likely impossible. Specifically because of this, it becomes most interesting to explore what it can't and won't be able to do on its own. Self-programming systems might be past the horizon, but getting a human more involved makes a big difference, and while the computer might never program for us, it might make for a decent pair-programming partner. We'll look at glimpses of this future, in academia and outside it, and see why they're more IDE plugins and less the robot apocalypse.


Hila Peleg

Doctoral Researcher
Technion - Israeli Institute of Technology


Events and Commands: Developing Asynchronous Microservices

The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s only accessible indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging. In this presentation, you will learn how to solve these distributed data management challenges using asynchronous messaging. I describe how to implement transactions using sagas, which are sequences of local transactions, coordinated using messages. You will learn how to implement queries using Command Query Responsibility Segregation (CQRS), which uses events to maintain replicas. I describe how to use event sourcing, which is an event-centric approach to business logic and persistence, in a microservice architecture.



Chris Richardson


Deprecating Simplicity

When engineering teams take on a new project, they often optimize for performance, availability, or fault tolerance. More experienced teams can optimize for these properties simultaneously. Now add an additional property: feature velocity. Mental models of architecture can help you understand the tension between these engineering properties. For example, understanding the distinction between accidental complexity and essential complexity can help you decide whether to invest engineering effort into simplifying your stack or expanding the surface area of functional output. Chaos Engineering was born within this conflict between feature velocity and increasing complexity. Rather than simplify, Chaos Engineering provides a mechanism for you to embrace the complexity and ride it like a familiar wave, maintaining our business priorities while dialing up feature velocity.



Casey Rosenthal

Casey Rosenthal is currently the CTO at backplane.io. Philosopher, volunteer, vegan. Formerly at Netflix, Basho.


Serverless in Practice

A Cloud Guru built one of the largest platforms using serverless technologies like AWS Lambda and API Gateway (we don’t run a single server, anywhere). It has been an incredible journey and we learnt a lot of lessons scaling our platform to 650,000+ users.

In this session we’ll share notes from our experience including:

  • What our serverless system looks like 2 years in (inc. key metrics, architecture, and cost)
  • Our serverless security posture
  • Important design patterns and architectures
  • Common serverless mistakes and how to avoid them

We will dive in to the design of our platform and share interesting data, go through key patterns and architectures, and discuss what it actually takes to build a scalable, reliable and high-performing cloud-native serverless systems today. This talk will focus on AWS but many of the principles and concepts can be carried across to Microsoft Azure and Google
Cloud Platform.



Peter Sbarski

AWS Serverless Hero, Author of Serverless Architectures on AWS


The Future of High Speed Transportation

In the global marketplace that transfers knowledge at the speed of light, we have a massive time delay and that is modern transportation methods. The hyperloop is the first new mode of transport to be created in over 100 years. The motivation is to connect people, reduce congestion, and protect our planet by eliminating CO2 emissions from terrestrial transport. The hyperloop can best be described as space travel on the ground - a magnetically levitating, electromagnetically propelled, passenger vehicle in a vacuum tube. With the elimination of aerodynamic drag and surface friction, power consumption plummets, speeds can reach 700 mph, and waste and cost are minimized. With the use of autonomy the service is on demand and delays become a thing of the past. Dr. Sengupta will discuss how space-age tech coupled to the VC funded innovation environment are enabling the revolution in green transportation from suborbital rocket flights, to electric airplanes, to space travel on the ground with the hyperloop.



Anita Sengupta

Rocket Scientist, Sr. Vice President
University of Southern California


Attitude Determines Altitude - Engineering Yourself

Success is not determined by our aptitude -- our skill at a particular task. Instead, it is determined by our attitude -- how we go about it. It is far less the contributions of genetics, or education, or circumstance than it is how we approach challenges, limitations, and opportunities in our lives. Through real science and some very personal stories, we will discuss how you can use your attitude to improve yourself.
We begin by discussing Growth Mindset - Carol Dweck's idea that we can improve ourselves through sustained effort. Focus and attention will help us put in the 10,000 hours of deliberate practice that allow us to achieve mastery.
We then discuss Trust - by trusting others to do their part and to do it well we can achieve both greater personal happiness and better business results. Generative organizations and psychological safety in teams are key themes.
We finally discuss Confidence - from the underconfidence of the Impostor Phenomenon to the overconfidence of the Dunning-Kruger effect. Most importantly, we conclude with practical ways you can build and sustain your own confidence in yourself.


Randy Shoup

VP Engineering and Chief Architect
eBay


Breaking Codes, Designing Jets, and Building Teams

Throughout engineering history, focused and empowered teams have consistently achieved the near-impossible. Alan Turing, Tommy Flowers, and their teams at Bletchley Park broke Nazi codes, saved their country, and brought down the Third Reich. Kelly Johnson and the Lockheed Skunk Works designed and built the XP-80 in 143 days, and later produced the U-2, the SR-71, and the F-22. Xerox PARC invented Smalltalk, graphical user interfaces, Ethernet, and the laser printer. What can this history teach us? Well, basically everything.
Effective teams have a mission - a clearly defined problem which the entire team focuses on and owns end-to-end.
Effective teams collaborate without hierarchy, across disciplines and between diverse individuals. It should be no surprise that Bletchley was an eclectic mix of "Boffins and Debs" - almost 75% women at its peak; or that Skunk Works' founding team included the first Native American female engineer.
Effective teams rapidly learn and adapt. Constant experimentation, tight feedback loops, and a policy of embracing failure are all part of the recipe of success. Innovation does not arrive on a waterfall schedule.
If this sounds a lot like DevOps, or true little-a agile, that's no coincidence. But too few organizations actually practice these three-quarter-century-old ideas despite the overwhelming evidence that they work. As Santayana wrote, "Those who cannot remember the past are condemned to repeat it." So let's relearn those history lessons.


Randy Shoup

VP Engineering and Chief Architect
eBay


Cancel All My Appointments

The most complicated state in an application is time. Like cooking a bag of microwave popcorn, modern web applications desperately try to keep up with their state through an orchestrated chaos of asynchronous operations popping off in indeterminate cadence. No question, coordinating all this concurrency is hard.

But there's a pitfall at the heart of asynchrony that stays mostly unaddressed.

When an operation doesn't finish right away, synchronously, it's possible the operation may never finish. Or, it may be destined to finish eventually, but a second operation may be raised which means we no longer care about the first. Whatever the case, we need to be able to cancel it. This critical check ultimately protects users from the vagaries of unpredictable systems.

Cancellation should be core to our async programming; no asynchrony should run without it. Too often, such handling is just a corner case exception. Without a cancellation strategy, your applications are incomplete at best.

We'll discuss use-cases for async cancellation and various approaches to managing them.



Kyle Simpson

Human-Centric Technologist
Getify Solutions


The Metrics You Should Use (but probably don't)

Have you ever had a gut feeling a project is about to go off course but no way to validate (or invalidate) that feeling? Has your team ever been burned by an inaccurate estimate or unreasonable expectation? Have you ever wished you could peer a bit into the future?

Navigating the uncertainty of knowledge work is often difficult and uncomfortable. During this session, you’ll learn new ways to visualize your team’s reliability and variability of delivery using the data you already collect. Instead of relying entirely on your gut or laboring over estimates, you’ll learn to predict outcomes and describe their likelihood. While this session won’t teach you to eliminate uncertainty or allow you to see the future, it will provide you with tools to explore and chart a reasonable course through the inherent ambiguity of knowledge work.



Cat Swetel

Cat is a technology leader interested in exploring how digital transformation facilitates relationships and could create conditions for more generative institutions. Her leadership style is deeply feminist in that it is focused on allowing all people to flourish. This leadership style (coupled with good technology instincts) has allowed Cat to establish an impressive track record of delivering the “impossible”.

In addition to leadership experience in a variety of settings from startups to large enterprises, Cat is also an accomplished public speaker delivering keynotes, workshops, etc all around the world. In her leisure time, Cat enjoys cooking, hiking, making jokes about Bitcoin, and reading feminist literature.


Transforming Programming

We're a generation of programmers who grew up with object orientation and imperative programming. When we transition to languages such as Elixir (and even some modern idioms in JavaScript), some of our old reflexes are no longer appropriate. Others are deeply useful, but in different and surprising ways. So, as we work towards the ideal of "programming by transforming", we mustn't forget to transform our thinking, too.

(ps: reducers are objects...)



Dave Thomas

Dave Thomas is recognized internationally as an expert who develops high-quality software--accurate and highly flexible systems. He helped write the now-famous Agile Manifesto, and regularly speak on new ways of producing software. He is the author of six books, including the best selling The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley) and Programming Ruby: A Pragmatic Programmer's Guide (Pragmatic Bookshelf).


Java in a World of Containers

Container technologies such as Docker are rapidly becoming the de-facto way to deploy cloud applications, and Java is committed to being a good container citizen. This talk will cover some of the new tools and techniques for reducing container size (jlink, Alpine/musl support), for improving startup time and sharing of data between JVMs (AppCDS and ahead-of-time compilation), and the recent work that has gone into interacting with container resource limitations.





Mikael Vidstedt

Director of the Java Virtual Machine
Oracle


Streaming Data with Kafka and Microservices

When we think of modern data processing, we often think of batch-oriented ecosystems like Hadoop, including processing engines like Spark. However, the sooner we can extract useful information from our data, the better, which is driving an evolution towards stream processing or “fast data”. Many of the legacy tools, including Spark, provide various levels of support for stream processing, but deeper architectural changes are emerging.



Dean Wampler

Product Engineering Director for Accelerated Discovery
IBM Research


The Problem with Pre-aggregated Metrics

Pre-aggregated metrics and time series form the backbone of many monitoring setups and have many redeeming qualities, but simply aren't sufficient for capturing the many ways things can go wrong in modern or complex systems. Problems inherent in the concepts behind and implementation of pre-aggregated metrics prevent them from being effective for any sort of debugging or diagnostics; we'll talk about why that is, and what techniques we should be leaning on instead.



Christine Yen

Co-Founder
Honeycomb


SkillsCasts
Other Years

Awesome!

Friends don't let friends miss out on great events.
Share it, and make the event even better!

×