No fancy new releases from me. Pre-parental leave is upon me (vacation before parental leave). I'm down to this newsletter and some video-work. Unfortunately I've had repeated throat-troubles so my video-adventures have been challenging. I hope to find my way back to some writing though.

I'm going to Code BEAM STO this May. That is the Erlang and Elixir conference in Stockholm, Sweden. If you are going and you can be there a day early for a special event, I have something for you. The perfect opportunity to try some Nerves and/or Phoenix LiveView. I'm bringing my team and myself. Frank Hunleth will be there to help with Nerves learning. Seating is limited. I really hope to see some of you there :)

I'm technically not on the hook for mentioning my sponsors during this month but I'm happy to, since they are supporting my work.

It is still West Arete, the custom software agency focused on higher education that are looking for Elixir & Ruby developers in the US.
And Bzzt the startup making deliveries in inner cities with small and light EVs that want developers in Sweden. Not necessarily Elixir experienced, but for Elixir work. 

I tackle certain things very differently

How do you tackle it when you sit down to build a library for other people to use?

How does it differ to sitting down to build a product?

All projects can have their unique angles of course and I certainly set a variety of levels of ambition in my projects. The nerves_node and keylight repos are both libraries. I didn't finish them up, they are fairly quick implementations, I didn't push a version to Hex. Meanwhile inky was more thoroughly worked and is probably along my ideals for what I should do with a library.

When building a product or otherwise web app I'm much more focused on getting some kind of initial prototype, working my way towards MVP and generally keeping a high velocity. Part of this is to reach an interesting result before I get bored and move on. My peculiarities aside it is also because the thing is useless all the way up to the point where it first becomes useful. That's pretty much a tautology. The application is trying to fulfill a purpose that has very little to do with programming and until it can do that it is entirely useless.

Corners can be cut to reach the point where you figure out if it is a good idea. Especially if the surface area of the app in the longer term is big enough that there is significant gain in cutting those corners.

I don't do that in the same way building a library that I intend for serious consumption. I'll definitely hack together a core piece of the challenge and try to verify that it does what I want before going further. The purpose of a library is often more general and open-ended than the purpose of an application. Consumers of your library likely care more about how you've implemented it than the users of your application. It affects them more clearly.

If your library controls a piece of hardware the purpose of most libraries would be to expose the offered functionality fully and the most common functionality conveniently. For the keylight library I had limited time so I covered the typical needs you'd have once you've set an Elgato Keylight up. I did not cover the setup process itself. 

I've currently been looking at a spec for a binary format and considering if I should write a library for it (I got a neat offer about doing it). This means I've been reading the spec, figuring out if it seems difficult, how I'd want to go about it. I also looked if there were already implementations in Elixir. And yes, there are, for reading but not writing and many of them aren't native. Further digging into one of them I realized I have some opinions about what makes a sensible library. This would be a job of decoding and encoding a well-defined format. I saw at least one approach I didn't like.

If you have to start a stateful process to run this type of library I'm not on board. The approach I'm looking at has one potentially stateful component and that's if you choose to read the file as a Stream, then you have the Stream that's a bit stateful in itself. In my eyes a library for reading/writing a format should be as deterministic as possible and ideally not do a whole lot of fancy state-wrangling. If it turns out to be useful and easy to parallelize I'd consider that a bonus functionality to offer. If I need to run a start_link for your library I'd hope it has reason to hold  ongoing state.

Inky is a stateful library, it holds a bunch of SPI and GPIO things, a buffer of previous pixels so the user can do partial updates and stuff. I'd expect Inky to be in your supervision tree.

There are a ton of ways of building and structuring an application that can work really well. Making a really inappropriate choice can certainly affect the experience of your users but overall the design choices of your backend isn't the first or strongest impact on the user. Your users won't know the difference if you've built on Event Sourcing and CQRS or with a monolithic web framework approach, microservices, MVC or PHP4 with .txt files for a database. If you've done a decent job it shouldn't really be noticeable.

The layers that are up for scrutiny are different with different consumers. For software libraries it's typically your API surface and the design choices there and that's a far more technical domain than your application UI and the user experience.

Actually, different individual consumers will also apply different levels of scrutiny. Some devs will never look at library code. I personally have gotten into the unfortunate habit of having opinions about the languages and frameworks of things I plan on running self-hosted. I'm pretty happy if it's Elixir or Go. I'll accept well-packaged PHP. I'm really not thrilled if it's Node.js because I don't trust that the deps will hold up. I don't recommend caring about this. It won't make you happier. It does go to show that beyond the difference between different types of software there is also the different types of people you'll be dealing with. 

Maybe this is all obvious but it came to mind. Let me know if you have thoughts at lars@underjord.io or on Twitter where I'm @lawik.

I appreciate you. Thanks.

- Lars Wikman