If your company is hiring for Elixir and need help sourcing great candidates or you want a reliable contract Elixir dev. Respond to this email and we can talk.

Railway programming?

I made two or three PRs to ash_authentication during my train-ride to Berlin. That felt good, felt nice. Part of it is that I feel really accomplished when I can improve something that other people use and solve problems people have not run into yet but are bound to hit later. Another part is that I can upstream the fixes to my problems. It was one of those moments where I had to dive into library code to fix my problems. If you want one lesson about programming from this newsletter, it is to read and understand the library code whenever it misbehaves or gives you grief. You can find so much leverage this way.

I have a new client taking up some of my time with a very unusual approach to green field development and so far I really like it. I'm building towards a prototype for them but the goals is also to research the feasability of the larger idea within the Elixir ecosystem, find out what is missing, what could be built out, what is inconvenient to work with. A true prototype in that the research is as important or more important than the specific software. The software prototype has a purpose (as per usual, securing funding) but the process is important. This client is also pretty happy with me publishing things about the journey. Expect more on this.

So I've been making sure Ash can authenticate with Google over OAuth 2.0 and learned a bunch about that along the way. I've been poking the intersection between Goth (Google auth library) and what ash_authentication actually produces. And I've been exploring some Google APIs.

This was another moment of poking under the covers and figuring out how a library ticks. I couldn't believe the Google API I was going to be poking didn't implement a particular endpoint. Looking at examples it seemed like it definitely does but it was missing in the Elixir client. The instructions for regenerating an API client took me most of the way there. If I didn't scratch the surface I would have been stuck. The fabulous thing about open source is that you can very often unstick yourself.

Elixir is the only ecosystem I've consistently done this in. If you've never tried it, this is what you do:

• Find a problem that might be related to a library you use.
• Look in the issues, etc and determine that you are the only one currently suffering from it or the only one motivated enough to address it.
• Go into "deps/evil_dependency" and add all the IO.inspect your heart desires to figure out the problem. `mix deps.compile evil_dependency --force` is a sweetheart when doing this kind of hacker bs.
• When you get sick of hacking your dep and the changes are getting significant you clone the github repo into a sibling directory of your project. You probably want to check out the exact release tag for your version so you don't get a half-broken main branch.
• In mix.exs you can do a path dependency: `{:evil_dependency, path: "../evil_dependency"}` and you should no longer need to force the compile.
• To contribute back you typically fork the main repo on github, add your fork as a remote, push an updated branch to your fork and then in Github PR your branch to the original repo with some nice explanation of what you are doing.

After a while you can enjoy the feeling of changing the dependency to the normal released version again as your fix has been integrated. With Elixir I find all this easier than anything I've done before. There is a standard way projects are built. There is not a ton of variance and usually you don't need a bunch of odd build deps or anything.

Later y'all, I need to do a small spike on how hard it is to generate Google libraries..

Do you go into library code to understand? Have you ended up fixing libraries you rely on? If not, why not? You can reply to this email or poke me on the fedi @lawik@fosstodon.org, I enjoy hearing your thoughts.

Thanks for reading. I appreciate your attention.