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’ 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
* 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.
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.
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!
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!
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.
runtime_toolsin 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.
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.
Renan discussed the current monitoring stack for his employer Xerpa.
Out of these tools,
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.
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.
mix xreffor initial pass link
withor multiple function definitions relying on pattern matching
Ecto key points:
Repo.Aggregatefor basic aggregation fragments like
count(id)which may be hiding in your queries
Ecto.Multifor grouping multiple statements together link This strut in this module is designed to be passed to
Ecto.Transactionso that all statements can be inspected/validated and then executed together.
Phoenix key points:
Repoout of your controllers. (See my notes above on the 1.3 changes)
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.
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.
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):
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.