You've got some shared front-end code that you would like to share between different projects. You want to abstract this shared code out into a library, thereby making it easy to install, share, or even pick-and-choose which JS modules to import.

I think that it pays to have an optimized workflow of the actual learning process. After all, if you learning efficiency is only at 60%, then that means that out of 10 hours that you put into learning a particular piece of knowledge, you would only retain 60% of the information spread out across those 10 hours, leaving gaps within your knowledge after that 10 hours (meaning that you would have to go back and revise parts that you are not sure of again…).

So, you've got lots of Python code being executed from your Elixir app, and lots of ad-hoc calling of your Python code. On one hand, you want to dynamically scale to manage demand, but at the same time, you don't want to accidentally crash your application by starting too many Python processes. So... what what's a frazzled developer gotta do to save himself some headache? The key problem that we are trying to solve here pooling, which is the the management of limited resources kept at the ready for any ad-hoc requests for usage.

I think that it isn't a well kept secret that I'm a fanboy of Elixir. Almost half of my blog posts (at point of writing) are related to Elixir and its ecosystem. But, how exactly did I get to this point? And why? In this post, let's deep dive into what makes Erlang/Elixir so special and why the latest innovations out of this ecosystem keeps me coming back for more.

Structs in Elixir are great, they let you define some data structure and lets you do all sorts of nifty stuff like default values. But what if you want to use this particular struct inside of an Ecto query and then preload associations based on a given field?