PRESENTATIONS
I am available for speaking engagements both in public and private settings. This is a list of my available talks.
All are roughly one hour long
HOW TO MANAGE MULTIPLE TEST ENVIRONMENTS IN A HYPERCONNECTED CLOUD WORLD
The advent of the cloud came to give us testing superpowers: one properly configured Kubernetes file and one can easily spin up a bunch of Docker containers that faithfully represent the production environment. However, with ease of use comes abuse, and the proliferation of test environments is beginning to be a real headache to many organisations, both in terms of management and cost. I have suffered this first hand, and from my experience at the trenches a number of strategies have materialised: universal feature flags, meta-automation, and test environment rationalisation. These techniques will allow you detect when you have overlapping and superfluous testing efforts, introducing the opportunity for cost savings, all while making sure your suite of tests environments remains flexible enough so as to take into account the different needs at different development stages. With these strategies you’ll feel confident that your test environments give you what you need, but no more.
MEASURING LONG-TERM PRODUCTIVITY: THE DEVELOPER’S LEGACY INDEX
Measuring a programmer’s productivity is a problem as old as the software industry itself. Number of worked hours? More productive people should need fewer hours, not more. Number of completed tasks? Not all tasks are equally hard. Number of introduced bugs? Bugs are not necessarily the programmer’s fault, and besides, what constitutes a bug anyway? The closest we’ve ever got to measure a developer’s productivity is lines of code, and this has proven to be a poor metric because not all lines of code are equally valuable. However, if we could measure not just how much a developer writes but how lasting the impact of their code is, we’d have a sense of the long-term contribution of a developer. This is where the Developer’s Legacy Index comes in: a technique to process the vast amount of information contained within modern code repositories so as to produce a statistical analysis of the lasting effect of each developer’s contribution. With the Developer’s Legacy Index you’ll be able to understand who’s really pushing your team forward (and whether you need to bring back that developer that left six months ago).
MAXIMISE THE BENEFITS OF REMOTE WORKING WITH BETTER PULL REQUESTS
The demands of the modern workplace are changing. Trends like flexible hours, remote working, or “bleisure” travel are being introduced to give employees more work-life balance. Moreover, organisations that are capable of working remotely in an effective manner are more resilient to external shocks, like the recent Coronavirus outbreak showed us. In order to remain effective when workers aren’t in the same place at the same time, teams need to leverage coordination tools. For the case of developers, one of the most important of these tools is the Pull Request. Join Abraham to discover the difference between a good and a bad Pull Request, and to understand the work that needs to happen before and after to make sure it is successful: deciding which changes need to be included and which ones need to be deferred, providing effective feedback, avoiding noisy change lists, etc. With these tips, you will notice that your Pull Requests become a rich communication channel, and you will be able to use distance to your advantage.
ARCHITECTURAL PATTERNS FOR A MORE EFFICIENT PIPELINE
Do you find constantly rebuilding things that don’t need rebuilding? If yes, this talk is for you. The way your codebase is structured impacts what you need to rebuild after each commit, therefore, the codebase needs to be re-architectured with the build pipeline in mind. Sometimes you’ll have many responsibilities packed in one module, so you rebuild all of them every time you change one. Or maybe you have a multi-tiered application and adding a feature implies modifying (and rebuilding) all tiers, with cascading effects. In this talk we’ll go over scenarios like this and others, showing how the code can be rewritten in a way that minimises unnecessary rebuilds.
POWER UP YOUR DEVELOPMENT EXPERIENCE WITH BASH SCRIPTS
Create a branch. Run the build. SSH into a Docker container. The developer’s day-to-day life is filled with little actions that require us to type particular orders into the command line. They are so small that we may not think much of them, but we run them so often that they end up taking an invisible toll; it feels like they’re getting in the way of real work.
This talk will show basic Bash scripting tools to automate most of your common day-to-day tasks, together with some ideas of what you can automate yourself. The content will ease your work, speed up common activities, and reduce the probability of common (and annoying) mistakes.
KEEPING YOUR CI/CD PIPELINE AS FAST AS IT NEEDS TO BE
Continuous Integration and Continuous Deployment have been key to increase the pace at which development teams can deliver value to the business while keeping quality high: automated testing provides a reliable feedback loop that ensures everything works, while automated deployments bring changes to the user sooner. However, as applications grow, many teams are finding that their build pipelines are becoming harder to manage, with builds taking so long that they often halt the development process.
This presentation explores the different ways in which long builds affect a team, together with the most common solutions that organisations tend to apply and which, unfortunately, involve a compromise that reduces the benefits of CI/CD. In order to fix this problem without compromises, Abraham introduces a technique to rebuild only the parts of the system that are affected by a change, in addition to a number of metrics that assess the overall health of the build pipeline. This equips teams with the necessary tools to understand when builds are too long and what to do about it.
SCALABLE CONTINUOUS DEPLOYMENT WITH MAVEN
This shows a way in which CD can be easily scaled up so you can keep growing your application without sacrificing quality. The talk will include real-life examples built with Java, Maven, TeamCity, Subversion and Artifactory, but most of the ideas presented can be easily transferred newer technologies.
Finally, the term Build-Driven Architecture is introduced as a natural evolution of Continuous Deployment, and explain how Build-Driven Architecture could shape software development in the future.
The talk will firstly touch upon the topic of Continuous Deployment, although attendees will benefit from having some previous knowledge (you don't need to be experts though). Then we will move to the technicalities of making Continuous Deployment work with Maven, and from there on how to scale it to as the project grows.