Finch is an open source HTTP library built on top of Finagle, the RPC framework that powers Twitter’s infrastructure. Finch is a great candidate to use when building services, and compares favourably to other popular frameworks in languages such as Ruby, Go, JavaScript, Elixir, Clojure and Haskell. This talk outlines the types of problems faced when building small services, and how using a good type system can help. I introduce & outline Finch, highlighting how it addresses these concerns. Throughout, a concrete example of an API built for a startup using Finch is used.

Deploying large numbers of containers to production can be a difficult proposition if you don’t approach the problem with a strategy appropriate both to the needs of your developers and the size of your operations team. Choosing an appropriate strategy enables you to codify your deployment patterns in a repeatable manner and reuse them over hundreds of deployments without embracing unnecessary cost and complexity.

Using Atlassian’s PaaS as a model, the speaker will discuss important milestones as you scale from a single container to tens, hundreds and eventually to a thousand containers. At what points should you begin to embrace log aggregation, monitoring and metrics collection, orchestration and clustering solutions? Learn how to incorporate ever more sophisticated third party solutions as you go, to achieve cost-effective and stable management of your containers in production, and meet both current and future needs.

In his book, Agile Design Patterns (Pearson, 2002), Robert C. Martin introduces the SOLID design principals as cornerstones for the construction of software that amenable to change.

Part of a larger set of design principals, the SOLID principals are closely associated with object oriented languages like C++, Java, C#, and more recently Ruby. And although they span different eras, all these languages share the same class structured, inheritance based foundations.

Go is one of a set of new languages that eschew inheritance, instead preferring the mantra of composition. Does this mean that Go programs do not follow the SOLID design principals, or even that Go is not an object oriented language?

In this talk I will explore the five core SOLID design patterns, discuss their applicability to Go programmers, and explain that while Go programs are not inheritance or class based, they adhere strongly to Martin’s principals. The audience will learn how well structured Go applications naturally follow the SOLID principals, leading to code which is loosely coupled, highly reusable, and inherently maintainable.

The ABC recently launched a new video transcoding system to process all the content for ABC iview, our catch-up TV service.

Metro is a cost-efficient, scalable, cloud-based system that was built using Golang, Node, FFmpeg, and heavily utilises a variety of AWS technology including queues, varied capacity autoscaling, hosted database servers, and notifications. The system has been live since December 2015, and has successfully processed thousands of pieces of content.

Come along to learn more about:

• What video transcoding is
• Our system architecture
• Technical challenges we faced
• Costs
• Aims for the future

Parsing is hard. It is the cause of hundreds of vulnerabilities, implementation mistakes and plain crashes in production. It got easier with techniques like parser combinators, but developers did not adopt them right away, especially in binary formats for low level contexts, like C development. Most solutions were deemed either slow or memory hungry, for right and wrong reasons.

The Rust language, developed by Mozilla, came with promises of safe, low level data manipulation, with efficient memory usage. The Nom parser combinators library was designed to check that assertion and verify that safe, zero copy, streaming parsers were a practical approach. Its development put light on an essential factor of adoption for parsing solutions: the usability and tooling are crucial.

This talk will cover the tricks provided by Rust to manage memory efficiently, its safety net for developers, and its ability to integrate with C code. Then we will approach the interaction between language theory and classical file format (best or worst) practices. I will also present the tools I wrote to make the programmer’s life easy during design, development, debugging and production.

Terms like OAuth, OpenIDConnect, claims, tokens, two and three legged authentication, etc. are becoming increasingly common in discussions about software development. Most of us rely on these for authentication to services we use nearly every day! In an era where applications are highly distributed and dependent on other services to perform their function, modern identity approaches are important in allowing us to access protected resources without needing to share passwords around. This talk will help unravel some of these terms, explain modern approaches to authentication and show you how to easily get started setting some of these up yourself.

Automated testing is widely considered a best practice. After considerable effort, the industry now agrees that unit testing, system testing, usability, and performance testing are essential in most serious development efforts, but we know that they are hard work. In this keynote, Michael Feathers will discuss challenges to the testing orthodoxy presented by micro-services, transient code, and functional programming, and reflect on where we might find ourselves in 10 years.

Our industry has been gripped by microservice fever in recent years as many organisations plan to take to their legacy systems with refactoring scythes to reduce them into loosely coupled, distributed, solutions. In doing so, these organisations will be forced to build substantial operational discipline around managing these services, as the monolithic modules which communicated in-process become fine grained services communicating over the network.

These organisations are likely to be coming to grips with advanced forms of application monitoring, discovery, log management, contract-based testing, automated deployment and environment provisioning, all required to run a microservice architecture with confidence.

But what if there were other ways to reap the benefits of distributed architecture (e.g., independent scaling, versioning and deployment, loosely coupled systems) without needing to construct your own “Netflix in the Small” level of operational awareness? If you’re willing to stick to a single implementation language, then perhaps there is…

The OTP (Open Telecom Platform) sits beneath both the venerable Erlang and hipster Elixir languages and provides the process monitoring and management sophistication needed from a platform built to manage telephony applications like those used by Ericsson, where Erlang originated. Building on OTP with either Elixir and Erlang removes the need for 3rd party tools like Hysterix, Zookeeper and forever wondering whether you should use HTTP PUT or POST to update your resources

Is the trade off worth it? Is it worth sacrificing a polyglot future for a less complex operational environment? Come join Andy and Martin as they demonstrate the power of the OTP platform and proposes a monoglot microservices architecture that will have you decommissioning your DropWizard and Spring Boot services in favour of a braver Erlang/Elixir world.

What if you can write applications and treat your entire datacenter as one giant pool of resources? Apache Mesos abstracts CPU, memory, storage, and other compute resources away from machines (physical or virtual), enabling fault-tolerant and elastic distributed systems to easily be built and run effectively.

After this presentation, you will gain an understanding of the Mesos architecture; how it differs from existing virtualization and containerization technology and where it fits on the existing application and infrastructure landscape.

In addition, we will take a look at two primary Mesos frameworks available: Marathon and Chronos, discuss some of the Mesos usages in large-scale production systems today and close off by running a short demo of Mesos in action.

How much does your software cost to operate?

Software design and implementation has an uneasy relationship with cost. As software developers, we often dwell on the cost of building software, but far less so on the cost to operate. The current zeitgeist of pay-as-you-go infrastructure makes this particularly apparent where rigid, hard to deploy and adapt software directly equates to larger bills. If we want to take control of operational cost, it is critical that we start to make operational cost a first-class constraint in the design and architecture of modern software.

In this talk we will work through the idea of price-aware architectures, answering: what are the properties of a price-aware architecture? what happens when we design our systems in a way that can leverage variable price and availability of infrastructure? and finally, how do we implement such systems?

REST is a popular architectural style for building APIs. But if you take a closer look it seems that not many developers pay attention to or make use of hypermedia in their APIs, although most of them see themselves somewhere between level 2 (HTTP verbs) and 3 (Hypermedia Controls) in the Richardson maturity model.

Why do they miss out on one of the most valuable aspects of RESTful APIs?

Besides the lack of knowledge and experience the need to deal with the inherently dynamic runtime aspect of hypermedia APIs might hold them back.

In this talk, Uli will dive a little bit deeper into some of the aspects related to hypermedia and REST APIs in general and show that most of what is needed for providing a rich hypermedia API experience has to be developed anyway.

This will cover:

• what hypermedia is about and how it can help developing richer APIs
• considerations when selecting media types for a hypermedia API
• how to avoid coupling on the server and client side
• how to leverage and integrate the ubiquitous language of the domain

REST is a popular architectural style for building APIs. But if you take a closer look it seems that not many developers pay attention to or make use of hypermedia in their APIs, although most of them see themselves somewhere between level 2 (HTTP verbs) and 3 (Hypermedia Controls) in the Richardson maturity model.

Why do they miss out on one of the most valuable aspects of RESTful APIs?

Besides the lack of knowledge and experience the need to deal with the inherently dynamic runtime aspect of hypermedia APIs might hold them back.

In this talk, Uli will dive a little bit deeper into some of the aspects related to hypermedia and REST APIs in general and show that most of what is needed for providing a rich hypermedia API experience has to be developed anyway.

This will cover:

• what hypermedia is about and how it can help developing richer APIs
• considerations when selecting media types for a hypermedia API
• how to avoid coupling on the server and client side
• how to leverage and integrate the ubiquitous language of the domain

You’ve been working in tech for a long time, and you’re really good at what you do. Inevitably, at some stage the Question creeps in: “Is this the time in my career when I’m supposed to go into ‘management’?” What do managers even do all day? How do you know if you’d be any good at it–or more importantly–like it? A few years ago, I decided to make the jump and ended up in charge of a team of 20. I’ll walk you through the lessons I learned, the skills you’ll need, and the successes and failures I had along the way. (Spoiler: it’s a bigger leap than you think.)

In today’s world the decision of which technology to use to create mobile applications has becoming daunting. The best bet is no longer just native Objective C / Swift and Android with many cross platform technologies become more featured and matured.

Three technologies are in the forefront of this space – Xamarin, Cordova, and React Native. These technologies create cross platform applications in very unique ways, each with their own pros and cons.

This presentation will help explain when and why you would go cross platform, gain an understanding of their differences, what their development experience is like and experience a live demo of each.

There are a lot of algorithms that revolve around iterating a form of information propagation until it attains a deterministic fixed point. CRDTs, Datalog, SAT solving, functional reactive programming, and constraint programming all fit into this mold.

One framework for these sorts of algorithms is the notion of a “propagator” due to Sussman and Radul, but until now little rigor has applied to know how such algorithms terminate with consistent results.

Another framework is Lindsey Kuper’s work on the notion of “lattice variables” (LVars), which addresses termination, parallelism and eventual consistency well, but not iteration.

By blending these frameworks, I’ll build up a series of sufficient conditions for propagators to terminate with consistent results and proceed to show how we can use this common framework to steal insights and quirks from each individual domain to try to optimize the rest.

Setting up the server infrastructure for an application is tough enough, but the real challenge lies in keeping those servers running. What if we could do away with that headache?!

Amazon Webservices has been building out their platform at a breakneck speed over the past few years. But with the recent introduction and now maturing of AWS Lambda we have the missing piece of the puzzle to get rid of our servers entirely.

In this talk, I will show how to use API Gateway, DynamoDB, S3, Cloudfront, Simple Queueing Service and Simple Email Service into a coherent whole in a serverless architecture. A pretty awesome whole that is almost infinitely scalable and requires no server maintenance.

Origami is a free set of extensions to Apple’s Quartz Composer developer tool that Facebook created to prototype all their app and website interactions. It allows for a tight loop of interaction and artwork iteration that precludes a need for text-language coding, but goes way beyond what customary wireframes and click-through prototypes can achieve.

Brave designers using Origami can become interaction coders for prototyping and testing purposes without writing a single line of code. This type of rich product feature prototyping is an emerging specialisation in app development circles known as Product Design.

Origami can export native iOS/Android/web code, providing animation specifications (dimension, durations, etc) in a language engineers can readily understand and easily transform into finished code. Getting designers and engineers on the same UI/UX page has never been easier.

Those who attend this demonstration of Origami will come away with a feel for:

• the speed with which an app interaction prototype can be constructed;
• how fun live coding a prototype can be;
• the ease with which a prototype can be evolved;
• how expressive and open Origami and QC are in terms of constructing new interaction ideas;
• the tangible benefits in allowing designers to take more responsibility for application interaction design.

It’s very hard to do architecture changes on a legacy system, but with correct refactoring skills and techniques we managed to apply Presentation-Domain-Data pattern on realestate.com.au’s 6-year-old iOS code base.

We did this without creating a feature branch and while continuing ongoing feature development, we were still able to submit to Apple every 4 weeks.

I’m going to share my experience in this talk: The refactoring strategies needed on a legacy code base, how to change the architecture without breaking the system, and what we learned along the way.

Looking at a software from the point of view of its unit tests often provides great insights on the architecture and the point of frictions.

A common issue in unit tests is the overuse of mocks and stubs. This most often caused by a design where objects have too many responsibilities and/or dependencies, and side effects. The components of such a system are hard to test, hence the need for mocks.

In contrast with such objects, code that uses concepts from the functional programming world such as immutability and pure functions is easier and safer to test.

Such functional code can be used to write highly testable and easy to work with application, with the help of functional reactive programming frameworks like ReactiveCocoa or RxSwift. This is the concept of “functional core, reactive shell”.

Software written in such way might look unconventional, and has a bit of a learning curve. The talk is to show that the advantages it brings make it a viable choice.

Our industry has been gripped by microservice fever in recent years as many organisations plan to take to their legacy systems with refactoring scythes to reduce them into loosely coupled, distributed, solutions. In doing so, these organisations will be forced to build substantial operational discipline around managing these services, as the monolithic modules which communicated in-process become fine grained services communicating over the network.

These organisations are likely to be coming to grips with advanced forms of application monitoring, discovery, log management, contract-based testing, automated deployment and environment provisioning, all required to run a microservice architecture with confidence.

But what if there were other ways to reap the benefits of distributed architecture (e.g., independent scaling, versioning and deployment, loosely coupled systems) without needing to construct your own “Netflix in the Small” level of operational awareness? If you’re willing to stick to a single implementation language, then perhaps there is…

The OTP (Open Telecom Platform) sits beneath both the venerable Erlang and hipster Elixir languages and provides the process monitoring and management sophistication needed from a platform built to manage telephony applications like those used by Ericsson, where Erlang originated. Building on OTP with either Elixir and Erlang removes the need for 3rd party tools like Hysterix, Zookeeper and forever wondering whether you should use HTTP PUT or POST to update your resources

Is the trade off worth it? Is it worth sacrificing a polyglot future for a less complex operational environment? Come join Andy and Martin as they demonstrate the power of the OTP platform and proposes a monoglot microservices architecture that will have you decommissioning your DropWizard and Spring Boot services in favour of a braver Erlang/Elixir world.

Our main revenue driver as a bank is within our home lending service offering. This is an area fiercely contested by all the banks. Customer expectations, relationships, service levels & speed of change are vital to meeting customer needs. Today, a bank that just offers a better rate to gain more customers is not good enough. The service offering has to be consistent, supportive and effective. In this talk we explore how we drastically improved our home lending service offering, increased team work, gained deeper relationships and trust by using agile teams and all without even one mention of the word ‘agile’.

We used operational data (volumes/time/decisions) mixed with customer feedback to learn and continuously improvement until we reached version 1 of what an amazing customer experience looks like. We did all of this without any technology or major process change, we more changed the mindset and culture to better meet our customer’s needs.

The median results over a 13 week period were as follows:

• Increased the number of deal to decision within 5 days by 22%
• Decreased the time to decision per application by 50 mins (per app)
• Decreased the days to decision for the 80th percentile by 5 days
• Delivered 15% of the departments volume with less than 5% of the workforce
• Quality results were ‘perfect’ they achieved 100% quality from the sample size tested

We received feedback like: “Basically it was an unbelievable experience for not only myself but for my client who was shocked to get the call to say we are signing up his mortgages on the same day it was lodged”

For some teams, having a Business Analyst would be a luxury. For others, they are no longer necessary. Whatever your situation, analysis and critical thinking is still essential in software development. Even if you don’t have a Business Analyst!

During this talk, you will learn how to become a Business Analyst while still being a developer, tester, or product manager. I will introduce some of the secrets that great Business Analysts use to get people collaborating, discussing the problem, and agreeing on a solution. Learn how to run a design studio, 3 amigos session, or a story kickoff. Don’t just be a zombie reading your next ticket. Let’s think about the problem and how we’ll solve it together!

Terms like OAuth, OpenIDConnect, claims, tokens, two and three legged authentication, etc. are becoming increasingly common in discussions about software development. Most of us rely on these for authentication to services we use nearly every day! In an era where applications are highly distributed and dependent on other services to perform their function, modern identity approaches are important in allowing us to access protected resources without needing to share passwords around. This talk will help unravel some of these terms, explain modern approaches to authentication and show you how to easily get started setting some of these up yourself.

In this talk, we define the principle of functional programming, then go into detail about what becomes possible by following this principle. In particular, parametricity (Wadler, 1989) and exploiting types in API design are an essential property of productive software teams, especially teams composed of volunteers as in open-source. This will be demonstrated.

Some of our most important programming tools are neglected, often argued away under a false compromise. Why then, are functional programming and associated consequences such as parametricity so casually disregarded? Are they truly so unimportant? In this talk, these questions are answered thoroughly and without compromise.

We will define the principle of functional programming, then go into detail about common problems to all of software development. We will build the case from ground up and finish with detailed practical demonstration of a solution to these problems. The audience should expect to walk away with a principled understanding and vocabulary of why functional programming and associated techniques have become necessary to software development.

In this keynote, Simon will be talking through various aspects in the life of the CTO and sharing experiences and learnings from his 6+ years in the role.

He will give you the CTOs angle on building great products with real world examples on topics such as business transformations, agile, technical disruption, influencing, coaching, leverage, architecture, executive communication, the power of platforms, and some more recent approaches for guiding hundreds of engineers.

If you are looking to one day be a CTO yourself, then this talk is the grounding and inspiration you need to launch that phase of your career.

EventStorming enables a team struggling with understanding and exploring a complex business problem to model that problem collaboratively in hours instead of weeks. In this talk you’ll learn how this technique quickly generates shared understanding and insights into how the software can, and should, support the business capability being explored.

In EventStorming, development team members and business people gather in a room and together they create a visual map of the flow of events – important things that happen – through concrete business examples. They use sticky notes to map out a story of how the software system behaves, or should behave, given a particular business problem to solve. This session will teach you the rules of EventStorming and how it can help your team.

Laziness is one of Larry Wall’s “three great virtues of a programmer”, but most people probably don’t consider it a virtue when writing tests! Wouldn’t it be great though, if we could write a program that generates our tests for us? As it turns out, we can and should do this using property-based testing.

I’ll go through some example testing scenarios in a few popular programming languages, aiming to demonstrate:

• What property-based testing is and why EVERYONE should be using it (not just people coding in functional languages!)
• How generators can quickly & easily come up with more thorough test inputs than a programmer typing in magic numbers
• How to (and how not to) define properties to specify program behaviour
• The genius of shrinkers and why they can save you hours of tedious debugging and questioning your life choices

Attendees will gain a solid & practical understanding of how they can apply property-based testing to their own code, in fashion that is both enjoyable and lucrative.

Have you ever heard a developer or yourself say “But it works on my machine!”? This defence is usually heard after a C.I. or deployment failure, or after a new team member has been trying to get his PC set up for the project after a week of trying.

As a Long time JVM developer I thought I had this problem cracked. It turned out that I’d been coddled by the JVM, because when I tried to do some polyglot development with Python and JavaScript significant problems were encountered.

This talk aims to impress on the audience that DevOps is not simply a one way street with developers imparting their hard won skills and best practice on Ops, but also shows how Dev teams can directly benefit from the DevOps discipline by creating and managing their development environments using DevOps tools.

The problem is that there are normally quite a few undocumented or forgotten set-up steps or conflicting tools on a dev box.

It’s time to take back some professional pride, and engineer a solution.

In this presentation I introduces a way to systematically capture all the missing steps in an executable specification document (aka a software program). This allows for a much more robust way to develop systems.

In particular the audience will learn how to spin up isolated development environments using Docker as a Vagrant “box” that require almost zero procedural overhead and can be used just as easily as running the development natively on their own PC but with the benefit that it can be repeated by anyone, including themselves 6 months down the line when asked to do a maintenance fix, without breaking or ruining their current working environment.

There is a lot of confusion around Vagrant and Docker, what they are, how they differ and why would someone pick one over the other? The vagaries of Vagrant and the dastardliness of Docker are discussed and I will explain the sweet spot I settled upon and how it solved my problems.

I have prepared a working example in Github to show that this stuff “works on my machine” and it will work on yours too.

At Atlassian, we are in the midst of rearchitecting our systems as microservices run in AWS to support the scale and flexibility we need. We have been building out a core identity component of our Cloud infrastructure in Scala, based on event sourcing and command-query responsibility separation (CQRS) in order to achieve this safely. With event sourcing, data is captured streams of immutable events to represent data instead of the traditional update-in-place paradigm. Streams can be easily replayed to restore system state up to any point in time to recover from bugs or failures. In combination with the CQRS pattern, we can seamlessly bring online new functionality requiring schema changes or new query patterns, and re-architect later for more scale simply by replaying and reinterpreting events into new microservices and ephemeral data stores. In this talk, we will describe the architecture of our system using AWS (DynamoDB, Kinesis and Lambda), design principles we’ve used, and most importantly technical and organisational lessons learned to help attendees avoid pitfalls we’ve come across.

Goals: By the end of the presentation, the audience should:

• have an understanding of event sourcing and CQRS including benefits and how it works
• have an understanding of design principles for event sourcing and CQRS, including event design, and surfacing eventual consistency through the application stack and in APIs.
• have an understanding of an architecture for an event sourced/CQRS-based application.
• have an appreciation of the challenges faced when building a system using techniques presented in the talk.

For decades, many have argued for and against Dearden’s “Myth of real-time management information” HBR 1966. At best most organizations have had only partial data, and insufficient storage and processing, limiting their ability to be a real-time enterprise. Thanks to massive compute power, memory and storage it is now finally possible for modern enterprises to capture and process the totality of their data current and past. Given they have real-time data the challenge becomes how to clean, transform, query, analyze and present this in meaningful, actionable real-time information. In this talk, we discuss the challenges of working with the real-time data deluge from sensor IoT to Big Data.

We take a brief look at the world of big data tools, event processing, and skills as they exist today. We then discuss our experience building Ivy, an interactive visual analytics environment for Thinkers. Thinkers are the key enablers for a real-time enterprise and need a capability to Think-Compute-See and actively participate in problem solutions. We discuss user requirements for acquisition, preparation and visualization and our challenges developing solutions consumable by Thinkers that are built on state of the art software technologies fast data technologies.

Many developers at small companies, and most indies, don’t have the luxury of collaborating with genuine beret-wearing, latte-sipping designers. But never fear! There are at least 23 weird tricks you can learn to avoid your app looking like it was designed by a developer. After twenty years of designing for print, and six years making mobile apps, James White is probably still a better designer than he is a developer (although some might say that isn’t saying much). In this session he’ll talk about branding, colour, iconography, typography, whitespace, and the holy trinity of aesthetics, functionality and usability. Expect pretty slides, and to leave with a notebook full of tiny but useful tidbits of advice.