Command Query Responsibility Segregation (CQRS) is an important architectural pattern for enterprise applications. It involves the separation of the command (or write) side of the application from the query (or read) side of the application and then only guaranteeing eventual consistency of the query side. It offers a number of important benefits for more complex and collaborative applications. This presentation will give a quick introduction to and overview of CQRS within a Domain Driven Design (DDD) context.

CQRS applications can also benefit, in many circumstances, from the use of Event Sourcing (ES), wherein events produced from the actions of commands are persisted rather than the actual state of the application. This presentation will give an introduction to and overview of CQRS using Event Sourcing, with some of the libraries and frameworks that help create CQRS/ES applications, and a few ways to persist these events in regular data stores or a custom-build third-party event store.

Finally, the presentation will consider whether events are the ultimate and most timeless way to persist application state (without actually persisting application state). The ability to construct and reconstruct data stores on the read side enables post-hoc optimisations of data representation for queries. The ability to change paradigms on the application write side means that the data representation is perhaps even more powerful and timeless than relational data stores.

Dread. And countless other choice words come to mind when you’re looking at that massive two thousand lines of code in that one function. You wouldn’t consider touching it with a ten-foot pole, but you have no choice. It has to be done. Your dread now morphs into stress. That stress multiplies when anticipating your deployment to production. Heaven forbid you have to rollback your change! Three year plans of, “let’s rewrite the entire thing” doesn’t usually work when business relies on the software to make money. So then how do you dismantle this monolith?

In this session, see how using Event Driven Architecture you can transform this monolithic mess into something clean, something small, something a lot more manageable. You can don’t have to make sweeping changes to that legacy stuff every time you need to introduce a feature. Instead write clean code completely on the outside. Break your monolith down, one micro brick at a time. It’s about time.

This session will demonstrate how to use the new features of C# 6 to simplify your code and reduce clutter. We’ll talk about what makes the new “Elvis” operator special, and also demonstrate the power of “Roslyn”, the new compiler-as-a-service.

This is the era of mobility. Application development teams in enterprise IT are gearing up to produce the mobile apps their customers require.To meet the time-to-market demands of mobile users, most mobile apps are developed using Agile and lean development processes.However, quite often, it seems testing slows down the development process and defeats the purpose of Agile development.The ever-increasing demand from the business,the diverse nature of the platforms & frequent releases of mobile operating systems make our current testing framework, designed using the traditional tools & methodologies, unfit to cope with these challenges.The big question is, how can we tackle these challenges? Should we sacrifice testing for the sake of speed? Or, should we design a test framework which will be closely integrated with the development process, providing an instant feedback on the functionality & performance of our mobile app after any new code is checked in.Here in this case study, we intend to demonstrate our test framework, designed using some commercial & open source tools, and showcase how we use this framework to test our mobile API and our app on real-time devices.

The presentation will be structured with the flow of an agile environment in mind.We will demonstrate how we tackled the challenges of mobile development by having close knit team of individuals – we call them solution engineers.We do not segregate the team depending on particular disciplines like development & testing.Testing in the team now starts before development begins.The test scenarios are drafted & the automated API tests are created.The unit & the integration tests (API tests) are executed after every code drop.Once we get the build ready, the app gets automatically installed on the real-time devices & the user interface tests are triggered.As the test pyramid suggests, we increased the test coverage in the unit & integration layer, reducing the number of user acceptance tests which run through the user interface layer & are expensive to maintain.

We know the “right thing” to do is to work together, to remove bottlenecks, to automate, automate, automate. But when the status quo is finger-pointing, mistrust, blame, and over-exhaustion from increasingly complex manual releases, it seems impossible to find a way to climb out of the downward spiral. How did an IT department turn this around to become a harmonious department with common goals and over 10x faster cycle times?

Winning the hearts and minds needed for lasting DevOps change requires something more than just great automation. This is the story of how Wotif found a way to incentivise a DevOps transformation across an entire IT department, resulting in cycle times measured in hours instead of weeks/months. While this journey involved technology such as DropWizard, Puppet & ZooKeeper, Matt (dev) and Alexandra (ops) extract principles that they hope can be applied to any organisation at grassroots and leadership levels using existing toolchains to support not only the best ideas of the present but also the legacy of the past and the unknown innovation of the future.

For most programmers, regular expressions are a riddle wrapped in a mystery inside an enigma shrouded in line-noise. So most sensible programmers either don’t use them at all (and are thereby forced to reinvent worse wheels…badly), or else they fall back on an “evolutionary programming” approach: find an existing regex that looks like it might do, then randomly permute its “genome” over and over again until it appears to work.

In this talk, we’ll go back to basics and discover that regexes mostly aren’t what you think they are, mostly don’t work the way you were taught they did, and mostly shouldn’t be created the way everyone tells you to.

More usefully, we’ll also talk about what regexes really are, how they actually work, and see how normal programmers can make use of their existing software development skills to construct correct and efficient regexes…without selling their souls or losing their minds.

In November 1924, in Cicero, Illinois, at the behest of Thomas Edison, the Western Electric company kicked off a set of workplace studies that would become a foundation for modern management thinking. A group of people that included a young William Edwards Deming, Joseph Juran, Walter Shewhart and our very own academic from Adelaide, Elton Mayo, took a foundation in engineering practices, combined them with a curiosity about social sciences, and started a revolution in thinking that impacts almost every workplace today.

Almost exactly 90 years later, another graduate of Elton Mayo’s Wharton School, Paul Tozour, published the results of a 21st century equivalent of the Hawthorne studies – The Games Outcome Project. Real empirical data on what makes software teams perform – and it has little to do with how agile you are.

These two studies, and the 90 years of theorising and research that lie between them, impact software engineers more than they might care to acknowledge. Productivity and the health of workplaces have become hot issues as Facebook moves into its 10 acre open plan office, Joel Spolsky (still) swears by an office for every engineer, and Basecamp work religiously on a remote basis. The aim of this talk is to join some dots and identify what from all this research has stood the test of time as better ways to work, with particular reflections on life at real-estate.com.au where the author works in IT.

Do you want to write less tests for the same amount of confidence?

Do you want to print out the testing pyramid on a dot matrix printer, take it outside and set fire to it?

How confident are you that you can survive the refactoring apocalypse without breaking your tests?

As consultants, we get to see how testing is performed across many different organisations and we have a chance to experiment with different testing strategies across multiple projects. Through this experience, we have developed a pragmatic process for setting an initial testing strategy that is as simple as possible and iterating on that strategy over time to evolve it based on how it performs. We have also settled on a style of testing that has proved to be very effective at reducing testing effort while maintaining (or even improving) confidence from our tests.

This talk will focus on some of our learnings and we will cover the different types of testing and how they interact, breaking apart the usual practice of testing all applications in the same way, the mysterious relationship between speed and confidence, how we were able to throw away the testing pyramid and a number of techniques that have worked well for us when testing our applications.

Even the simplest web application has so many vectors of attack, it’s no wonder most people forget at least one. Web applications aren’t stand-alone; they are built upon frameworks, upon platforms, upon core libraries, each of which could suffer from vulnerabilities you’re not only unaware of, you’re statistically unlikely to discover them all. Consider, for example, last year’s OpenSSL “Heartbleed” Bug.

We hear about security vulnerabilities every week, now it’s time to experience them. Find out what the leading concerns are, and the not so common ones too, and experience live demonstrations of how these attacks play out.

This presentation aims to arm you with the mindset, tools and resources to minimise the opportunities for attack, and to reduce the fallout when they succeed. From cross-site scripting and session hijacking to brute force and man-in-the-middle attacks, you’re expected to cover all your bases so the bad guys can’t use a single one.

At Atlassian, we’ve been migrating applications in our Cloud platform to a microservice-based architecture to support the scale and agility we need to grow long into the future. While developing small microservices with the latest tech stacks is relatively quick and fun, rolling out such radical architectural changes to 60,000+ existing instances of systems used continuously by our customers with minimal downtime and no loss of data is extremely challenging. In this talk, we’ll describe our safety-first approach for achieving this, using our recent work rolling out a microservice binary data storage and migrating many terabytes of attachment data from JIRA into AWS as our main case study. We will discuss our success stories and learnings for rapidly developing new microservices with pure functional architecture, planning and executing safe rollout, and engaging the rest of the organisation to achieve immediate and future business benefits.

In this session Jorge explains five remarkable areas in which the F# language provides a significant advantage when comparing it with C#. He shows examples covering from basic to more advanced features, like type providers and computation expressions. This session provides a glimpse of what is possible with F#, its main advantages and a basic understanding of how powerful this great language is.

Have you designed / developed a system using the “best practices” of the last few years? Are these acronyms familiar – ORM, SOA and DDD? If so there’s every chance that when your system makes it to production, it’s going to suffer.

In this session, I will investigate this often forgotten life of a system – when it’s deployed into the real world and the original developers move on to pastures new. It’s a collection of my experiences from the last 9 months working very close to a live system which I designed a few years ago using the then, best practices.

We will consider issues which are often overlooked or not thought about in too much detail at the development phase like performance, concurrency, scalability and deployment. We’ll see ways we can track problems down, sometimes before the end users even see them. We will think about how to deal with them or even side-step them. And we will consider how we may have avoided them by taking different architectural paths early on.

By the end of the talk I’m hoping you’ll see that delivering a system to production is just the beginning of it’s life, and have some ideas on how to keep it happy and healthy whilst it grows!

Agile borrowed from the JIT manufacturing processes originally at Toyota. The Agile Manifesto itself summarized the key aspects brought into programming from JIT.

Original Agile processes like eXtreme Programming (XP) brought breathtaking speed of delivery to a waterfall world. But Agile has not stood still. From XP’s original (and aggressive) 2­3 week iterations, we now see individual programmers pushing new functionality to live systems several times a day!

Acceleration drives changes to an organization’s processes and skills, just as the original shift to Agile from waterfall. Organizations reluctant to address such changes, however, inhibit the acceleration. Indeed, their attempts to accelerate often result in lower morale and flawed delivery; these failures drive conservative (and destructive) attitudes against change.

In this talk, we will address a myriad of drivers for faster delivery:

• Available technologies, including Cloud, languages, and new frameworks
• Shift toward active monitoring rather than one­time acceptance testing
• Refined, lighter processes consistent with shorter cycles
• Architecture that is fault­-tolerant rather than provably perfect
• Shift toward trying ideas rather than firm requirements
• Reduction in role specialists
• Reduction in delivery team size

For each of these drivers, we will describe teams that have taken these steps and the corresponding accelerated delivery.

In my consultancy, I’ve come to realize that most clients/teams I’ve coach don’t care too much about the theory.This presentation, therefore, takes a standpoint in the practical parts.I will also mimic my experience with most teams I’ve introduced kanban too, and do the introduction in small iterations.This means that the presentation also is a template for anyone that will need to introduce kanban to others.

Impact mapping is a powerful visual technique to make sure that you are building the right thing; making a big impact with our efforts. I’ve found it very enlightening and powerful.

In this session I wanted to try to turn the normal flow on it’s head; by first doing an impact map together and then talk about what this means and how to use it.

Setting up a shared infrastructure environment is a challenging task, changing an existing one without breaking anything even more and one that traditional testing methods often have trouble supporting.

Behaviour Driven Infrastructure (BDI) is one of many tools that can help us change the way we approach testing of infrastructure changes. Supported by a real-life case study I will shed some light on what the future might hold in this area and expose some ways in which BDI might help fill the gaps.

Of all the misunderstood and abused terms in the Lean/Agile dictionary, MVP is right on top of the list.

MVPs are a great way to structure your learning around your products, but what it has come to mean is “the crappiest thing we can get away with”. In this session we will learn:

• Why it is a bad idea to release a MVP based on the least amount of effort.
• Why we need real MVPs
• Some examples of MVPs
• What needs to change to run real MVPs

Keming Labs was commissioned by a client in the energy sector to design and build a custom heavy equipment inspection tool. The tool was designed with Harel Statecharts and implemented with ClojureScript running on an Android device.

In this talk, Kevin will discuss this approach; in particular, how explicit immutable data yielded fast, on-device prototyping, easy-to-implement visual testing tools, and improved cohesion between developers, designers, and the end customers.

Monitoring monolithic applications integrating with single databases is a well-understood problem. But who writes monolithic applications these days? Who would even dare in the face of the all-conquering wave of microservices popularity?

Yet effective monitoring of a large fleet of decoupled microservices is a different kettle of fish entirely. And whilst an organisation may have the development savvy needed to build these fine-grained services, this competence does not always provide the necessary operational nous to monitor them in production.

Correlation ids, synthetic transactions and circuit breakers are all concepts those struck with microservice-fever are going to have to master to ensure the benefits of this architecture are not outweighed by the complexity of the associated support infrastructure.

This presentation will use the event stream processing tool Riemann (riemann.io) to demonstrate how typical microservice monitoring patterns can be implemented to provide simple and effective monitoring.

Do you want to write less tests for the same amount of confidence?

Do you want to print out the testing pyramid on a dot matrix printer, take it outside and set fire to it?

How confident are you that you can survive the refactoring apocalypse without breaking your tests?

As consultants, we get to see how testing is performed across many different organisations and we have a chance to experiment with different testing strategies across multiple projects. Through this experience, we have developed a pragmatic process for setting an initial testing strategy that is as simple as possible and iterating on that strategy over time to evolve it based on how it performs. We have also settled on a style of testing that has proved to be very effective at reducing testing effort while maintaining (or even improving) confidence from our tests.

This talk will focus on some of our learnings and we will cover the different types of testing and how they interact, breaking apart the usual practice of testing all applications in the same way, the mysterious relationship between speed and confidence, how we were able to throw away the testing pyramid and a number of techniques that have worked well for us when testing our applications.

Last year Apple announced a brand new programming language as a modern replacement for the venerable Objective-C. Swift makes a very interesting study in language design – influenced by modern statically-typed languages with an emphasis on safety and speed, but (almost) seamlessly compatible with the unsafe, dynamic, weakly-typed OO language it needs to co-exist with.

Sam will run through a brief introduction to the language, highlighting some of the design choices and tradeoffs made, and show how to use the language features to write better code.

Tiny little apps on your wrist! WatchKit is the SDK for developing apps for the new Apple Watch. This presentation will cover a variety of information to help you create great WatchKit apps, including:

• The architecture of WatchKit apps
• What functionality is and isn’t possible using WatchKit
• Communication and data sharing between Apple Watch and the iPhone
• Tips and tricks for great WatchKit app performance

The presentation will be useful both for newcomers who are looking for a head start in developing WatchKit apps, as well as developers with some WatchKit experience who are interested in sharpening their skills.

At Atlassian, we’ve been migrating applications in our Cloud platform to a microservice-based architecture to support the scale and agility we need to grow long into the future. While developing small microservices with the latest tech stacks is relatively quick and fun, rolling out such radical architectural changes to 60,000+ existing instances of systems used continuously by our customers with minimal downtime and no loss of data is extremely challenging. In this talk, we’ll describe our safety-first approach for achieving this, using our recent work rolling out a microservice binary data storage and migrating many terabytes of attachment data from JIRA into AWS as our main case study. We will discuss our success stories and learnings for rapidly developing new microservices with pure functional architecture, planning and executing safe rollout, and engaging the rest of the organisation to achieve immediate and future business benefits.

Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.

In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.

We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.

With 73% of the world using Scrum as their predominant Agile method, this session will open up your eyes to the many other Agile and edgy Agile methods and movements in the world today. For many, Agile is a toolbox of potential methods, practices and techniques, and like any good toolbox it is often more about using the right tool for the problem that will result in meaningful results. Take a rapid journey into the world of methods like Mikado, Nonban, Vanguard and movements like Holocracy, Drive and Stoos where we will uncover 40 methods and movements in 40 minutes to help strengthen your toolbox.

We know the “right thing” to do is to work together, to remove bottlenecks, to automate, automate, automate. But when the status quo is finger-pointing, mistrust, blame, and over-exhaustion from increasingly complex manual releases, it seems impossible to find a way to climb out of the downward spiral. How did an IT department turn this around to become a harmonious department with common goals and over 10x faster cycle times?

Winning the hearts and minds needed for lasting DevOps change requires something more than just great automation. This is the story of how Wotif found a way to incentivise a DevOps transformation across an entire IT department, resulting in cycle times measured in hours instead of weeks/months. While this journey involved technology such as DropWizard, Puppet & ZooKeeper, Matt (dev) and Alexandra (ops) extract principles that they hope can be applied to any organisation at grassroots and leadership levels using existing toolchains to support not only the best ideas of the present but also the legacy of the past and the unknown innovation of the future.

Spreadsheets are the bane of people’s lives in many organisations and – for better or for worse – businesses continue to rely on them very heavily, even for critical parts of their day to day operations. In my presentation I will discuss how the following technologies can be utilised to build neat solutions to help automate these workflows.

• Scala’s Streams and Case classes
• ScalaTest’s FlatSpec
• The Apache POI project

It will begin by talking about how we’ve ended up here in the first place – a case in point is within large financial organisations which have critical risk models (accounting for billions of dollars on their balance sheets) that still reside within huge and highly complex spreadsheets!

Following a brief overview of a typical spreadsheet model, I will demonstrate how one can interact with them programmatically with the excellent Apache POI library. I then go on to breakdown how by utilising stream processing and case classes in Scala one can provide really neat solutions to replace these manually managed spreadsheets with fully automated and concise, functional solutions.

Finally, I will illuminate how one can assist with the end to end validation process, via the magic of BDD – which can help articulate all is behaving as expected.

Technology gurus predict that in 2017 – 2018 time frame we have computers with 10 terabytes of non-volatile memory! In this talk we explore the disruptive impact of massive amounts of memory and try to answer the following questions. What are the potential benefits and costs of all this free and persistent memory? Will be have database or file systems or transaction read/write sets or Java style garbage collection? What happens to application architectures and development in the huge memory world? How can large memory make development better and execution faster?

Remote working in our industry is becoming more prevalent everyday. Geography is no longer a constraint in setting up a work function in an organisation.In 2010 REA Group, together with ThoughtWorks China, set up an offshore delivery centre.This centre works extremely effectively using REA Agile processes.

I have been building remote teams in Xi’an for the past 2 1/2 years. As a Technical Lead,I have detailed hands on experience and specifics that I will share with the audience on what has worked well for us as well as what hasn’t worked so well. This case study will provide a recipe for working with remote agile teams effectively. In particular I will cover:

• Remote team composition
• Essential technology
• Core practices
• Asynchronous versus Synchronous communication
• Common Challenges
• Building a successful culture
• Tips and tricks for remote working

Functional Programming, like Object Oriented and Structured Programming, is a quite radical departure from previous programming practices. Like these two previous changes in approach, change is gradual and faces significant resistance.

While the ideas around functional programming are becoming more widely accepted, actually adopting the techniques in old-school imperative teams and code bases presents significant challenges technically, culturally and politically. Exploiting the full potential of FP does require experience, and when the imperative experience vastly outweighs that of FP, importing experience can be enormously beneficial.

This talk is about experiences introducing functional programming across a large organisation; what works and, perhaps more importantly, what doesn’t. It looks at some specific patterns and anti-patterns that should be considered for people wanting to transform any organisation that has significant existing program assets and software engineering teams. It will help form and present discussion and arguments to achieve meaningful change.

This is the era of mobility. Application development teams in enterprise IT are gearing up to produce the mobile apps their customers require.To meet the time-to-market demands of mobile users, most mobile apps are developed using Agile and lean development processes.However, quite often, it seems testing slows down the development process and defeats the purpose of Agile development.The ever-increasing demand from the business,the diverse nature of the platforms & frequent releases of mobile operating systems make our current testing framework, designed using the traditional tools & methodologies, unfit to cope with these challenges.The big question is, how can we tackle these challenges? Should we sacrifice testing for the sake of speed? Or, should we design a test framework which will be closely integrated with the development process, providing an instant feedback on the functionality & performance of our mobile app after any new code is checked in.Here in this case study, we intend to demonstrate our test framework, designed using some commercial & open source tools, and showcase how we use this framework to test our mobile API and our app on real-time devices.

The presentation will be structured with the flow of an agile environment in mind.We will demonstrate how we tackled the challenges of mobile development by having close knit team of individuals – we call them solution engineers.We do not segregate the team depending on particular disciplines like development & testing.Testing in the team now starts before development begins.The test scenarios are drafted & the automated API tests are created.The unit & the integration tests (API tests) are executed after every code drop.Once we get the build ready, the app gets automatically installed on the real-time devices & the user interface tests are triggered.As the test pyramid suggests, we increased the test coverage in the unit & integration layer, reducing the number of user acceptance tests which run through the user interface layer & are expensive to maintain.

The maker culture, it’s a place where minimum viable product simply isn’t cool enough, where manufacturer security holes are useful and where your skills as a developer are a membership card.

Learn how to get started coding against the devices in your home and see how your existing developer skills and tools can be used to improve the way you interact with the physical world. We’ll dive into real world examples of bringing a residential A/C and a typical domestic wireless doorbell into the Internet of Things using a netduino and the .net microframework. Along the way we’ll discover some pitfalls for experienced developers and a heads up for dealing with the iGeneration prankster.

HBF has a vision to create a unique community where Members are renowned for being healthier, happier people. HBF delivers this in part, through a range of web based and mobile health tools to allow members to track and monitor their wellness, and by capturing insights from these services alongside broader member data. This case study will present how three solutions originating through experimental innovation days within the HBF IT developer community, applied new technology to local opportunities, to create true member value and a shift in thinking and capability. Examples include the development of a pilot application using Google Glass for HBF Fitness; an application for members to upload their wearables data into an integrated service to record and compare data and receive rewards and incentives; and the use of rapid data discovery and interactive visualisation tools to bring HBF’s data to life.

After spending a year working on a project and delivering all the ‘must’ and ‘could’ have features. You hear through the grapevine that customers found the solution clunky and the uptake hasn’t been great. What’s more, your part of a success ‘agile’ team adopting XP practices and continuous deployment. What’s going wrong?

Successful product development is a team effort and can’t simply be left to the business to decide what’s right. There is a new approach called Lean UX which derives from the UX world, rooted firmly in design thinking, agile and lean startup.

In this talk, I will introduce Lean UX and take you through the guiding principles of the learning loop. Through the talk I will use Bankwest as a case study of how we experimented with Lean UX from projects to strategy.

After spending a year working on a project and delivering all the ‘must’ and ‘could’ have features. You hear through the grapevine that customers found the solution clunky and the uptake hasn’t been great. What’s more, your part of a success ‘agile’ team adopting XP practices and continuous deployment. What’s going wrong?

Successful product development is a team effort and can’t simply be left to the business to decide what’s right. There is a new approach called Lean UX which derives from the UX world, rooted firmly in design thinking, agile and lean startup.

In this talk, I will introduce Lean UX and take you through the guiding principles of the learning loop. Through the talk I will use Bankwest as a case study of how we experimented with Lean UX from projects to strategy.