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.
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 :)
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
Thanks for the text version. For the curious, here's my take-away:
> The thing that you can extract from this is that generally, logs, metrics, and tracing are not provided to explain how the thing you are using works: they are meant to let you debug your usage of it. Let me repeat that and put it in bold: most applications and components you use that are easy to operate do not expose their internals to you, they mainly aim to provide visibility into your interactions with them.
> This means that if you want to make your system operable, you shouldn't aim to just expose all the innards you can. You shouldn't ask people to be aware of how you've implemented things. Instead, you have to think about who is consulting the data you expose, and why. We have entire departments dedicated to User Experience (UX), but nearly no concept of Operator Experience (OX, or OpEx?) even though operators keep the lights on and are critical power users.
Great video! I don't suppose there is an online version of your presentation for Tout est terrible[1] is there? I looked but couldn't find one. Ca va si c'est suelement en francais.
I've looked a bit for it and it appears nobody has put it anywhere. I personally do not have a copy either. I thought CodeMesh in 2017 had it, but it was never published.
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.
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.
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)
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.
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.
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...
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
edit: Great video even for non-elixir/erlang devs.
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 :)
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
Thanks for the text version. For the curious, here's my take-away:
> The thing that you can extract from this is that generally, logs, metrics, and tracing are not provided to explain how the thing you are using works: they are meant to let you debug your usage of it. Let me repeat that and put it in bold: most applications and components you use that are easy to operate do not expose their internals to you, they mainly aim to provide visibility into your interactions with them.
> This means that if you want to make your system operable, you shouldn't aim to just expose all the innards you can. You shouldn't ask people to be aware of how you've implemented things. Instead, you have to think about who is consulting the data you expose, and why. We have entire departments dedicated to User Experience (UX), but nearly no concept of Operator Experience (OX, or OpEx?) even though operators keep the lights on and are critical power users.
Great video! I don't suppose there is an online version of your presentation for Tout est terrible[1] is there? I looked but couldn't find one. Ca va si c'est suelement en francais.
[1]: https://ferd.ca/tout-est-terrible.html
I've looked a bit for it and it appears nobody has put it anywhere. I personally do not have a copy either. I thought CodeMesh in 2017 had it, but it was never published.
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!
You can actually ask YouTube to play at slower speeds, say 0.75x
What did you learn, if you don't mind sharing?
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.
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.
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)
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.
> 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.
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...