Attending Code BEAM

Last week, Miriam Pena from the Erlang Ecosystem Foundation’s education working group mentioned in the Elixir Slack’s channel for women and other minority genders that Code BEAM V America was coming up. She said the working group had a handful of tickets available for students, folks who can’t otherwise afford to go, and people in groups that are underrepresented in tech.

I’ve never applied for a “diversity” ticket to a conference before, but she said they’d pre-purchased them, and the conference was 6 days away. Also, the 2020 Elixir survey results say the community is 2% women, which is rather like the open source numbers back when I started doing that. (I hope the open source numbers have grown?) So, I figured it was probably ok to claim one.

I know I’ve traditionally been pretty bad at taking notes at conferences, so this time I looked for advice online and landed on a modified version of the Cornell System. The outer margin has keywords, and the main area has notes. The bottom has a summary.

Conference tech

The conference used Whova as a platform for connecting between attendees. Actual presentations were done with Zoom, but it was embedded in Whova. Videos were uploaded the same day, which was great! That really handles the “oh no, I want to go to two at the same time” problem nicely. They used Toucan for the hallway track. Toucan was really cool. It did a good job of the “several groups of people standing around together” feel. The next DC Elixir meetup is going to use it.

The actual conference

Observability

Anyway, about the content. I went to a couple sessions on observability. I already use Grafana and Honeycomb at work. I was more interested in the advice about what and how to monitor than in how to set it up, since I’m already using them. (Though I did go looking into how to get per-function spans in Honeycomb, and I landed on Telemetry Decorator.)

Tech debt

Jessica Kerr and Chelsea Troy talked about “addressing escalating risks in our code base,” which was mostly a fancy way of saying “tech debt.” The big tip they started with was that talking about “risk” makes management listen. Plus, “debt” can sound like it all has one solution, whereas risks are more clearly differentiated.

The ability to change the code does not lie in the code; it lies in the relationship between the code and the developers who understand it.” — Jessica Kerr at Code BEAM V

I liked the holistic view of they brought to the discussion. Incomplete, out-of-date, and hard-to-find documentation are all risky. Lost institutional knowledge is risky. And updates you didn’t install because “if nothing changes, it’s stable” is risky, since there may be security holes in your libraries.

Phoenix Live View

I really want to try Live View in my next personal project. Sophie DeBenedetto & Bruce Tate have a new book on Live View coming out later this year, and it’s already available for beta readers. I’d pick it up right away, if I didn’t feel like I ought to read the basic Phoenix book first. (Yes, I’ve been using Phoenix for the last year, but only to build a GraphQL API, not using the rest of the functionality.)

Machine Learning

I am not a math person, so I didn’t get a whole lot out of this. The basic thing sounded like Nx is supposed to bring Elixir up to NumPy’s speed. It’s supposed to be compatible with TensorFlow, and they talked about GPUs doing calculations. So, that’s really neat, and I hope mathy people are able to make good use of Elixir for their machine learning magic.

Software Correctness

There are two sessions I think fit this category. One was on property-based testing. The other was on contract programming.

Property-based testing is meant to mimic the random stuff real users do. It’s like fuzzing for functionality. The idea is that instead of writing test cases, which (let’s face it) often tend to focus on the “happy path,” you write a model of how it should work, then throw random data at it and see if it stays within its constraints. I imagine this involves a finite state machine.

I’ll need to grab Fred Hebert’s new book on property-based testing.

Contract programming is something I just read about in The Pragmatic Programmer. It’s about ensuring a contract between the calling and answering function. Strong typing is at least a part of it. In Elixir, Dialyxir provides static analysis of types.

Elixir Adoption

Sundi Myint and Ben Marx had a session on Elixir adoption. I work in a company that adopted Elixir a year ago, but I still wanted to go to this. I was surprised to hear that recruiters say finding Elixir engineers is easy (thanks to the concentrated community resources, such as the Slack server), since “how will we find such niche-language programmers?” is a common concern.

Of course, learning a new programming language isn’t all that hard, so you can just hire people for general programming skills and have them learn the language later. I wasn’t hired to write Elixir, after all.

Generalized solutions > *

Randall Thomas gave a keynote full of insights into modern programming. I thought he made a good point about a language only being as good as its tooling. I wouldn’t want to work in a language with no unit testing framework, for instance. The larger point, though, was about generalization versus specialization. He referenced the books Infinite Game and Range: Why Generalists Triumph in a Specialized World. If you buid solutions that are too specialized, you’re stuck when the problem space expands. At some scale, it was like the open/closed principle, applied to entire codebases or problem spaces instead of just to individual modules.

Other stuff

From the “What Ruby can learn from the BEAM” talk, I got a reminder that I really need to learn about the actor model. It’s how concurrency works in Elixir and Erlang, and Ruby has recently added it, and I have absolutely no memory of learning about it in school.

I skipped Melvin Cedeno’s presentation on teaching functional programming with Elixir, only because I saw him present it a few weeks ago at the Triangle Elixir meetup. I do recommend it, though.

I need to go back and watch some of the double-booked sessions, like the one on infrastructure and maybe the security ones. (It’s been so long since I got out of infosec, I’m not sure I’d still understand those, though.)

Overall, my “to read” list increased by at least 3 books in the last week, and that is simply not a sustainable pace for non-fiction.