Summary of Phoenix workshop at Visuality

NOTE: This article was initially published on the Phoenix on Rails blog.

Recently, I took it upon myself to prepare and lead the Phoenix workshop for the Visuality developer team as part of the company's investment day held on July 15. A total of seven developers participated, six of which were Rails devs and the last one a Django dev.

It was quite an effort to prepare the code, exercises and the guide, but it was well worth it. I've had a priceless chance to share my excitement about Phoenix and Elixir. To teach and explain basics of both. And, best of all, to see everyone just as excited and hard at work to get a grasp of functional programming, pattern matching, plugs, Mix, Ecto and all. Here's how I've created the workshop, how it proceeded and what were the results.

Preparations

I've developed the workshop to meet the following main criteria:

1. I couldn't make any assumptions as to existing Elixir proficiency of participants. Therefore, the workshop was supposed to be approachable even by those completely unfamiliar with it. On the other hand, I knew that there will be at least two participants that did begin learning Elixir and Phoenix already, so I wanted them to enjoy it and learn from it as well.
2. I wanted to involve participants with writing own code and solving own problems, while being backed up by my support, by a list of useful links as well as by the complete solution code.
3. Exercises were supposed to be the most basic daily challenges of typical Rails project. The workshop was not supposed to focus on channels, OTP or other features exclusive to Phoenix at this stage. This was in order to first persuade experienced Rails devs that it's not that hard to approach their existing, typical web app projects and problems with Elixir and Phoenix.
4. Although Rails devs were a majority of my audience, I wanted the workshop to be just as approachable to web developers experienced in other frameworks, like Django.
5. The workshop was supposed to be approachable without my personal assistance, in case if someone couldn't attend it in person at the office on the investment day and/or if they wanted to do it on another date. Also, I wanted it to be a valuable resource for everyone on the web.

I must say: meeting all those criteria required some time, effort and patience to reiterate and fix issues as they became apparent or pointed out to me. Here's how I've proceeded with it and also how I'd advise others to approach the development of such a workshop:

1. Make an list of main features that you'd like to introduce to the participants.
2. Group those features by problem domain and difficulty level.
3. Think of a sample project that could cover as many of those features as possible.
4. Sort features by their time/value ratio and by their fitting into the sample project.
5. Keep only as many top features as you'll be able to cover in the workshop (read more below).

By "covering in the workshop" I mean inventing exercise for particular feature, writing such exercise, finding linkable materials on the web for the participants to learn from (adequate to their knowledge level) and finally implementing it yourself in the solution code included in the workshop for the participants to lean on.

I've decided to go with yet another todo list application. Here's the final result: todox-phoenix. In the end, it consists of three obligatory exercises that bootstrap the project and of six extra exercises of varying focus and difficulty for everyone to pick freely.

Workshop in action

I've started with leading my audience through three obligatory exercises. I've hooked to a projector, initialized a new Phoenix project, configured it and implemented basic features which included HTML-based todo item management and then some front-end tasks that also involved creating a JSON API action. I've stopped as often as possible to let everyone catch up and of course to answer questions about the project structure, philosophy behind it and the Elixir syntax involved in there. This part took us about 4 hours to finish.

After a lunch break, I've described the extra exercises that the participants were supposed to approach on their own and advised those undecided about which exercise might be best for them. We spent remaining 3 hours implementing those exercises and solving issues as we stumbled upon them. Most people picked the custom authentication exercise, so I mostly had to answer questions about plugs, assigns and the connection lifecycle.

Conclusions

Sharing the passion and knowledge about Phoenix is one thing, but for me this workshop was also an unique chance to have an initial insight into practical challenges of convincing the Rails team into using Phoenix and then actually converting them to the new stack.

Motivation

It shouldn't be a problem to motivate existing web developers to switch to Phoenix. For sure it wasn't in my case. Everyone was really enthusiastic and eager to participate. It seems Elixir and Phoenix communities have created enough buzz and awareness around the technology to make it a hot next thing to learn.

Here's the list of things that impressed my audience the most during the workshop:

• Phoenix development performance: response time measured in microseconds, speed of recompiling changes and serving them, same for Brunch and changes in assets
• Ecto: the syntax for expressing database queries that brings together SQL naming and structure with compilation safety, expressiveness and plain beauty of Elixir
• Phoenix package: we've found all features that we'd need during the workshop including app config, models backed by database, migrations, router, templates or generators
• Online resources: we've found an impressive amount of online resources including tutorials or Stack Overflow answers to issues that we've stumbled upon

Common problems

Here's the list of problems that we've challenged during the course:

• Understanding Plug.Conn flow: there's a bunch of new concepts that caused an initial confusion including adding app-wide or controller/action specific before-action calls and loading data once, storing it in assigns and accessing it in controllers, views or templates
• Switching to ES6: the knowledge about the newest JS standard is well-spread among today's front-end devs but not so much among those focusing more on the server-side; the main concern seems to be the switch from global variables to imports and exports
• Asset compilation bug: projects initialized with newly installed Phoenix version had the babel-presets-es2015 NPM package missing, so we had to install it manually with npm install --save command to make the assets compile properly
• Hot asset reload on Ubuntu: in order to make the hot reload during development work on Ubuntu, we had to install inotify from APT which was made easy by the helpful error message displayed in the console
• Inventing the project structure: it's not just eye-opening but also challenging to leave behind the Rails autoload facility and start structuring the app with concious decisions about problem domains specific to the project instead of conventions as the main driving force

Next steps

Obviously, a one-day workshop is not enough to make any serious judgement about switching a team or a company to Phoenix. Still, I was happy to have made this first step and to have seen my fellow programmers eager to try new things and extend their toolbelt. Now, it's up to them to continue learning, possibly by getting back to the basics and learning more about Elixir and OTP before jumping into further Phoenix tasks. The excellent Programming Elixir book and the exercises included within it would be my first recommendation in this regard.

Also, I hope that the MIT-licensed workshop repo complete with instructions and exercises in the README and with this rather positive summary of its results will encourage others to propagate the technology in their own teams and companies.

As to me, I was surprised to find the role of a coding teacher to be joyful and rewarding beyond measure. Surely, I hope to do it again sometime soon. We've already talked within the team about a follow-up workshop or talk about Elixir, OTP, actor model, observer and more. The list of possible topics seems to be both long and interesting.