
Operable Erlang and Elixir [video] - okket
https://www.youtube.com/watch?v=OR2Gc6_Le2U
======
richjdsmith
I tried Elixir back during the period that the Phoenix framework (the real
draw - for me personally - to Elixir) was transitioning between v1.2 and v1.3.

Trying to figure it out while things were changing - the documentation hadn't
even been updated fully yet - with old walkthrough's referencing concepts that
were now being considered bad practice was overwhelming as a fairly junior
dev. I gave up and went back to what I knew.

With Chris McCord announcing[1] Phoenix Liveview beta and demoing it over
Christmas holiday season, I decided to give the language another try (as a
less junior dev than I was two years ago).

All I can say is wow! What a delightful language. Pattern matching is such a
joy to work with it makes me a bit frustrated it's not common in more
languages. The documentation for the language and 90% of packages I've poked
my nose into in the past week is concise and neatly organized (mostly due to
with Jose Valim's decision to treat documentation as a first-class citizen in
the language).

For anyone who has been curious and heard mentions of the language, with the
advent of LiveView, along with the maturation of the Nerves Project, I don't
think there could be a better time than now to give the language a try.

[1]:
[https://twitter.com/chris_mccord/status/1106291353670045696](https://twitter.com/chris_mccord/status/1106291353670045696)

edit: Great video even for non-elixir/erlang devs.

~~~
QuinnWilton
The transition from 1.2 to 1.3 was rough for a lot of people. It represented a
shift from the Rails-y "Phoenix is your application" school of thought, to
instead pushing people toward separating all of their business logic and
persistence concerns into a different layer than the web framework.

This was of course always possible in frameworks like Rails, but it wasn't
necessarily encouraged by the framework, and required a lot of effort to truly
achieve in practice. This change left a lot of people feeling unsure of how to
structure and architect their apps, and with a lot of libraries in flux as
best practises were still being fleshed out.

Overall it's been a positive progression in my opinion, and I think that as
the ecosystem continues to embrace lessons from domain-driven design and
patterns like utilizing Phoenix PubSub as a message queue, we're going to be
seeing a lot of really high quality and extensible libraries showing up.

It's an exciting time to be a professional Elixir developer :)

------
mononcqc
Hi, I'm the presenter in the video. If like me you prefer text formats, I have
a blog post which partially covers the same content:
[https://ferd.ca/operable-software.html](https://ferd.ca/operable-
software.html)

~~~
anbotero
I actually found this presentation (and the blog post as well) quite
interesting. If possible, it would be awesome for foreign people if you talked
just a little bit slower: Not much, just a bit. I think you have excellent
enunciation, which helps a lot already.

Thanks for sharing!

~~~
eeZah7Ux
What did you learn, if you don't mind sharing?

~~~
catwind7
The presenter shared his written version of the talk and i'd say that this is
probably this biggest takeaway:

> The important lesson is that you'll encounter multiple types of operators,
> with various mental models, and various approaches to your system. You must
> take a human-centric approach. Avoid the glass house, and provide well-
> layered observability probes that adapt to specific types of concerns, and
> provide both guidance and flexibility to operators. This will be the
> difference between a system where people can operate at various levels of
> experience, and a system where only wizards can thrive.

------
lelf
Great presentation. I highly recommend to watch it, even you don't use
Erlang/Elixir, it's for the most part is not Erlang-specific.

------
catwind7
Is this mostly written for a sysadmin / dev-tool creators audience? As a web
developer of consumer (non-technical users), while I found myself agreeing
with a lot of these points, I feel as though this was _not_ written with app
devs in mind because I don't find the advice very actionable.

For example:

> your app should mostly expose operational data for its application users,
> not its developers.

Okay, so I agree that we should provide visibility through through _some_
means specific to operators at different levels of abstraction. i.e adding
framework middleware logging (if you're building a framework for devs) for app
developers so they don't have to add logging everywhere in their app hoping to
spot something off.

What about the "end end" user - the 60 year old retiree using turbotax. I mean
- those are also people feeding input into this complex system. What
operational data do you offer them? Or are they not considered operators in
this context? (I may have answered my own question haha)

~~~
di4na
The answer is it depends. In that case i am pretty sure the main target was
libraries authors and devtools authors.

But we can consider the users as operators. It depends of the use case. For a
turbotax example, turbotax is here to give control of a fairly complex system
(US taxes) to its operators (60 years old retiree). Now can the retiree learn
about it if the optimizations are not enough? Probably not. Or maybe. That is
a UX problem right?

But think of it. If it fails, who will the retiree call for helps? Experts
operators. Hotline for turbotax or accountants. Can you provide _them_ with
that info?

I especially want to emphasize tools for your Customer Support staff. These
are rarely prioritized, but they imho have a far better RoI and customer
satisfaction impact than any UX change you can do. CS are operators.

~~~
catwind7
> That is a UX problem right?

Ah yeah - I do recall author making that distinction ("user" UX teams vs
operator UX teams).

> I especially want to emphasize tools for your Customer Support staff. These
> are rarely prioritized, but they imho have a far better RoI and customer
> satisfaction impact than any UX change you can do. CS are operators.

That's a good point. Right now my team does give tools to CS related staff but
you're right they're not prioritized, the UX is horrible (b.c it's "designed"
by developers who were tired of having to troubleshoot themselves), and devs
get pissed / act surprised when the CS people dont use the tools the "right"
way.

~~~
di4na
Yeah. These are always low priority because they are not from paying customers
right?

Except they impact your customers directly.

Bonus point: they are customers you can easily talk to and watch how they
work. Super fast feedback loop !

Want a group to test super fast prototyping and "go live" ? These people are
round the corner, will love you for it. They are the perfect place to train a
team in velocity...

