Andrew is a Principal Consultant with Readify, and has participated on enough interesting gigs in his time to have a tale or five to tell. Like many he has made some strong opinions along the way - some of which even pertain to software; but is always ready to revise them if a convincing argument (and possibly a cleansing ale) is supplied!
Created
August 25, 2019 11:05
-
-
Save andrewabest/2f432803fc8002e591ca0904041a55e1 to your computer and use it in GitHub Desktop.
DDD Adelaide 2019 Submissions
Most of us have a good idea on how to execute a software delivery - we have a clear picture of the practices, processes, and behaviours we employ to ship good outcomes, given a particular business initiative, requirement, or deliverable.
But how we arrive at that point can be a mystery! At the very start lies the infinite universe - all that is possible, and impossible. We need to equip ourselves with tools that can help our businesses understand their portion of the universe - their services, products, customers, market, problems, and opportunities, that can be leveraged to form goals that we can achieve with the help of the software we can craft.
Once we understand the possibilities of what can be delivered - how do we rationalize what we should be devoting time, money, and effort into delivering? This is very much a business decision, and we need to be able to guide our businesses through the decision making process, eliciting, creating, and capturing the data we need to make decisions about what we should be delivering, and when.
In this talk, Andrew will equip you with a set of tools, techniques, and opinions, that will help you help your businesses discover what they could achieve, decide which of these possibilities they should be executing on, and if there is time left - some opinions on the key ingredients of successful software deliveries!
Shipping code is the most important thing that we do. Shipping working software allows us to validate assumptions, and realise value. The quicker and more confidently we can ship code, the better our chances are of creating great outcomes.
Two things that allow us to ship code more quickly, and with higher confidence, are cloud services and devops toolsets. If you are in Azure - Azure Devops might be your weapon of choice. If you are in AWS, you may be using AWS Code Pipeline. But there are also a proliferation of other third party options - TeamCity, Jenkins, Octopus, AppVeyor, CircleCI... you get the picture. How do you decide which tool suits your use case best? Are the first-party tools really better when you are in their world? Will those tools scale to your particular use-cases?
In this talk we will establish an ideal mental model for continuous integration and deployment tooling, and then hold up three CI/CD stacks to it: Azure Devops, AWS CodePipeline, and TeamCity + Octopus Deploy.
Whose cuisine reigns supreme?
Formal specifications can be daunting. A long time ago, in a galaxy far far away, ietf.org created the stylesheet you are greeted with when attempting to open an RFC document. It looks like it was crafted with the internet's version of a typewriter. Opening one of these RFC documents usually greets us with a solid few pages of index. Most of us in this situation, when going to read a spec, are on a mission to Get Stuff Done TM. When we are confronted with having to do some solid bedtime reading in order to move things forward, it can be tempting to close the browser tab and go searching Stack Overflow for more direct answers.
Once we dive in however, a new world of understanding is available to us - these specs are a goldmine of information that help us gain a far more fundamental understanding of the technologies we are trying to wield.
Let's dive into the spec of a technology in an area we are all responsible for knowing more: security. OpenID Connect is the standard modern application authentication specification. In this talk we will attempt to build an OpenID Connect Client that can authenticate against a compliant Identity Provider, and prove that specs aren't as scary as they seem, and that they should be one of the first places you look when learning a new technology.
Disclaimer: this talk is about learning fundamentals, not about rolling your own security tools. Don't do this in prod kids - always rely on security tools and technologies built by the pros.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment