This year was my first ElixirConf! It was an incredibly exciting and enjoyable time. I was able to meet many interesting people working on interesting projects. What follows is a series of brief writeups of the talks which I saw in person.

Chris McCord Keynote

Chris’ keynote was a combination of discussion on the current Elixir community as well as a great talk on whats coming in the future of Phoenix. He presented a high level view of his plans for Phoenix Presence as well as the coming changes for Phoenix 1.3.

Here is a list of my key takeaways:

The directory structure of Phoenix applications in 1.3 is being treated as “less special”. This means that web/ is now going to live in my_app/lib/my_app/web . * I think this is a good change and will be quite educational from a personal standpoint. I absolutely leaned towards thinking "Phoenix apps are special", and I am glad that I am being forced to rethink this.

Additionally in the 1.3 restructure, the word ‘model’ is being removed. Chris was clear to emphasis that it was a mistake to use that term to begin with. Side by side with this change is to formalize/push for using (what I am calling this at the moment) Service Modules. A Service module is a module which takes all logic other than render logic out of the controller. Chris said that the Phoenix team did themselves no favors by having the default generators and documentation place core logic at the controller level. It is his hope that by restructuring things in 1.3 that the thought process of putting all logic in one file can be avoided. * I love controller change. It has been on my list for a month or so now to pull all logic out of my controllers, and its good to hear that the community at large is going to be moving in this direction. * I understand the removal of the 'model' word, but if I am being honest it does not make too much of a difference to me. * I am currently restructuring one of my applications to use this new directory structure to understand how the migration will look. I will be posting on this at a later date.

Umbrella applications are going to have better support, and eventually starting new Phoenix applications will default to the umbrella style directory structure. * This makes sense for applications which will be growing. I am indifferent on this change at this time. I think that there is more work to be done on the release side with [Distillery](https://github.com/bitwalker/distillery/) and general best practices before this change will pay off.

With the release of Phoenix presence, Chris believes that the next “big thing” to be included in the project is automatic service discovery. * As I have not played with presence at all, I cannot speak to this. Conceptually it *feels* right, and ultimately very valuable.

PG2 and You - Eric Entin

This was a great little introduction to the pg2 library. @antipax went over some of the cool things that it does as well as discussing his translation into Elixir repg2.

There is not much to say on this talk other than it was interesting and gave me some high level information that I otherwise would not have had. All I have in my notes other than the link to repg2 is a quick comment on the :kernel.SafeSupervisor which is something that I had no idea existed. It is a base level supervisor which a user has no entry point into.

The future of deployment in Elixir - Paul Schoenfelder

This was a wonderful overview of the state of releases in Elixir. This is a subject which is super relevant to me and I expect anyone who has a strong desire to use Elixir in production. Paul mostly discussed his own dissatisfactions with how he built exrm and how Distillery is the future of releases. Because exrm was implemented on relx, Paul was not able to implement some critical dynamic features (use of /config files per environment for instance) which he viewed as critical. He strongly discourages anyone from continuing to use exrm, and says that all new development should use Distillery.

He also mentioned a great need for “real world” documentation of building and using releases. I agree! I pitched in recently with a basic release walkthrough for Phoenix which was distributed with Distillery 0.9.9 . If you are using Distillery or have experience building and using OTP releases please chip in, the community needs your knowledge!

Debugging Techniques in Elixir - Erich Kist

Erich presented a wonderfully educational talk on the debugging ecosystem in Elixir starting with IO.puts all the way through :observer and how to use it in production.

I learned a few new tricks about IO.inspect , foremost of which was the new :label option which will be making it into the next minor release. using :label will allow you to prefix label your inspect output instead of interpolating. For example:

Turns into this:

Minor maybe, but pretty neat!

Key points:

Make sure that you always handle ALL messages in your process’ mailbox to prevent mailboxes from getting too huge. This means at the very least make sure that you include a catch all clause.

If you need a traditional debugger, check out :debugger in Erlang

in Erlang If you want to have access to observer in production releases make sure you *include runtime_tools in your applications in mix.exs . If you don’t, you will not be able to start observer on your production machine. Also, be sure to set a cookie on your production nodes so that you have some degree of security for remote connections for debugging purposes. Read up on Erlang’s node security for more details. ALSO, make sure to run observer in stand alone mode on your production machine. You do not want any issues in observer to crash your node (stand alone mode prevents this). Finally, for remote debugging, you should be forwarding your connection port in the SASL application configuration. I know nothing about this right now, but I will be trying it soon.

in your applications in . If you don’t, you will not be able to start observer on your production machine. Also, be sure to set a cookie on your production nodes so that you have some degree of security for remote connections for debugging purposes. Read up on Erlang’s node security for more details. ALSO, make sure to run observer in stand alone mode on your production machine. You do not want any issues in observer to crash your node (stand alone mode prevents this). Finally, for remote debugging, you should be forwarding your connection port in the SASL application configuration. I know nothing about this right now, but I will be trying it soon. For production debugging Erich recommended the free book from Heroku Erlang in Anger

All in all this was a very relevant talk for anyone at any stage in their use of Elixir.

Measuring Your Elixir Application - Renan Ranelli

Renan discussed the current monitoring stack for his employer Xerpa.

Out of these tools, exometer , elixometer and graphana were new to me. This was a good case study of what an in house monitoring stack could look like for an Elixir application.

Refactoring Techniques for Elixir, Ecto, and Phoenix - Gary Rennie

Gary discusses and demonstrates different refactoring techniques in an example Elixir application.

This is a hard talk to write notes on due to the examples. I recommend watching it if you are new to Elixir or new to using pattern matching.

Key points:

Have tests before starting. Automated or otherwise

Lean on mix xref for initial pass link

for initial pass link Move internal case statements into function definitions using with or multiple function definitions relying on pattern matching

Ecto key points:

Look into using Repo.Aggregate for basic aggregation fragments like count(id) which may be hiding in your queries

for basic aggregation fragments like which may be hiding in your queries Check out Ecto.Multi for grouping multiple statements together link This strut in this module is designed to be passed to Ecto.Transaction so that all statements can be inspected/validated and then executed together.

Phoenix key points:

Keep Repo out of your controllers. (See my notes above on the 1.3 changes)

out of your controllers. (See my notes above on the 1.3 changes) Make sure that your error pages are working properly

Two afternoon sessions

I unfortunately needed to step out due to client work for the two early afternoon sessions. I will update this post once I have the opportunity to watch the talks I had planned on.

WebRTC and Phoenix, when μ seconds aren’t fast enough - Jason Stiebs

This was a fantastic talk on a subject which I knew nothing about coming in. Jason delivered a fantastic presentation on the WebRTC project and how it could be used with Elixir. He discussed different network topologies and how they effect communication between different clients. In addition, he showed a demo project for video communication with the initial handoff and discovery handled by a Phoenix application and web socket.

I would put this under “must watch” for anyone who wants to know how a service like google hangouts operates. It gave me a much bigger appreciation of video streaming services as well.

Elixir for the next 10 years - Boyd Multerer

If you are in the mood for an inspirational talk, this is the one to watch! Although very little of the actual body of the talk is focused on Elixir, it is a fantastic view of the future and what we all are placed to take advantage of as an industry and community. What about having a mesh network in Low Earth Orbit and putting your CDN on it? Is that possible? Boyd thinks it might be, and that Elixir may be the language used for some truly SciFi ideas. His energy and ideas are infectious; I know that was not the only one who walked out of the room pumped to get back to work on building the future.

Key notes (or in Boyd’s case Bets):

Power consumption drives cost, and the BEAM is well suited to low power environments

FGPAs are coming, and we should all prepare for how that will change how we design our software.

Global wireless networks (high speed even) are coming, and will change the way that our world works. Think about how you would design and distribute a truly world wide product.

Don’t be overly concerned that Erlang is not the fastest language out there. Much of the perf critical work can be done with Nifs and redundancy/robustness is the most important thing for a huge system.

Nerves is awesome.

Recap

It was a great conference, I am quite happy I went! Next year (in Bellevue, Wa) I would like to see more self employed people in attendance. This event further reinforced my feeling that Elixir/Erlang/OTP is the place to be right now within our field.