Here you can find the talks that I have presented.
They are included along with slides and, where available, recordings.
Domain Driven Design (DDD), Elixir/erlang and causality are all facinating topics, that I hope to talk about in the future.
Prepared talks that I have yet to present can be found at the bottom of this page.
Introducing Raxx, an Elixir Webserver Interface
Raxx is a personal project investigating the value of a rack style interface to the Elixir ecosystem.
This talk is quick overview of why I undertook the project and some thoughts on progress at the time.
Building with domain concepts
All useful software is applied to a particular problem domain. This talk will encourage the use of value objects to better model a programs problem domain.
Ace an Education in TCP
Building a server from the ground up with Elixir.
Ace was built with one unusual design priority; to have simple to understand source code.
I created it to learn more about the network layer. Valuable at a time when microservices are bringing networking issues to the fore.
shows the path from simple echo functionality to a robust general purpose server;
discusses the challenges and lessons encountered along the way; and
covers why Elixir was such a perfect fit for this project.
It may also be possible to present this or similar topics as a more technical introduction to why to use BEAM for other communities.
Designing a DSL in Elixir
Elixir Macros: The power and the responsibility
What macros can do for you and what you can do for everyone else
Elixir's Macro system is incredibly useful and incredibly powerful.
It offers much that is not possible with meta programming constructs in other languages. So much so that the first rule of macros is 'don't use macros'.
I have published several libraries using macros to build DSLs. From this experience I will provide an intro to macros. Level up to a show a few best practises for working in the ast. Finally, discuss some design principles to get the most value from your macros
Personal macro experience with OK, await and routing DSL
Object Oriented Programming, one more time.
Spoiler: Objects come in two flavours, Facts and Actors.
Discussions around Functional Programming(FP) and Object Oriented Programming(OOP) are many and varied.
These two paradigms are often presented as opposites.
To Alan Kay classes are a minor detail of OOP; in many tutorials on the subject, classes are a cornerstone.
Joe Armstrong, the creator of erlang, describes it as perhaps the only true OOP language.
Yet many consider it to be a leading example of a functional language.
"Everything is an Object".
This is valid statement, and yet useless.
By expanding what it means to be an object we can reconcile some of the differences between the two camps.
Finally having solved this argument we can move on to a glorious future for programming (perhaps).
This could definitely do with a better title.
Rails in the corner
Rails is not your application. Take control and focus on what makes your application unique.
Rails is just one part of your toolkit, yet it makes a lot of demands for your attention.
Not just building a CRUD application?
Unsure which model to use for a new feature?
Perhaps we need to look carefully at what Rails leaves to you, the developer.
This talk looks to advance the audiences understanding of MVC.
It will introduce a few complementary ideas from Domain Driven Design and Hexagonal Architecture.
All with the goal of building applications that are more than just Rails apps.
The content of this talk is based on production applications that have followed this approach.
The guidance for the development was from the ideas of bounded contexts and pluggable services from Domain Driven Design.
Application border control
Validating input is a pain. TODO finish this description.
"Build programs that model the problem domain".
This is one of the best ideas from Domain Driven Design.
However how to we have a progam composed of rich objects that make use of libraries that don't have the same semantics.
How do we prevent our application from getting bogged down in implementation details.
This talk discusses the above and in particular tackles the most pernicious implementation detail of HTTP servers.
In many ways this is the extension of "building on domain concepts", although all necessary ground about value objects is covered.