Peter Saxton

Talks

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.

Presented


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.

Not Presented


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.

This talk:


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.