The first link under “Data Structures” doesn’t work anymore.
By accident found this while reading the overall good articles at http://no-kill-switch.ghost.io
Designing a P2P Lending platform with Elixir in mind
Open your text editor with the migration file when you run mix ecto.gen.migration: https://goodcode.in/ecto/1/open-your-text-editor-with-the-migration-file-when-you-run-mix-ecto-gen-migration
In the internal terminal of visual studio code one can also simply cmd + click the path in the terminal to open the migration
Clustering your Elixir application on AWS inside an Auto Scaling Group
Choosing Elixir for the Code, not the Performance - mainly thoughts about how often performance, scalability etc. is praised as what makes elixir great but there’s just so much more and even arguably more important
I’ve been having similar thoughts recently
Elixir is introducing and making easy so many fantastic ‘best practices’ which have been slowly answering my burning curiosity of “surely there is a better way of developing???” that I frequently had when I was using Rails.
Things like easily being able to build your app as a series of components, or preferring not to use if/else’s (and multiple function defs with pattern matching instead) meaning functions do one thing
If you have some suggestions on other topics I could cover there, I’m open to suggestions!
I’d be interested in reading about how to make a library reusable. As per the Ecto repository pattern where you
use Ecto.Repo in your own module to allow multiple repositories in a single Elixir application. To also cover how best to supervise processes, and their naming conventions.
So there’s a few blog posts about Elixir on our blog at www.amberbit.com/blog that I wasn’t posting here and you may like:
Accessing priv directory
You probably have some migrations and other stuff inside /priv directory, to access it use Application.app_dir(app, [“priv”]) in your Elixir code and OTP machinery would make sure you won’t loose files inside of it.
To get the priv directory always use only
:code.priv_dir(:my_app_name)! Though ‘most’ of the time
priv will be in the app’s directory, it ‘could’ also be elsewhere, renamed, and variety of other things, and as such this will break in certain situations (like, say, running from inside a tar file or so)… >.>
Application.app_dir does exactly the same
:code.priv_dir does minus appending of the
priv part. There is no difference between them.
There is last I saw. Last I checked
:code.lib_dir(:app), which returns the path to the app library directory (which might be a tar file for example, but without the extension), and then it uses
Path.join/2 to append it. Where calling
:code.lib_dir(:app) instead queries the
:code_server directly, which then properly puts the path on to the end of the lib_path, using something similar to Path.join when it is a path, or doing something ‘else’ when it is a packaged file (like a tar file). In addition some custom BEAM builds use a priv directory located and named elsewhere for embedded systems (admittedly this was a decade ago).
Well I just wrote a summary of the Elixir.LDN conference https://zorbash.com/post/elixirldn-2017/
But I think folks might also find this post about Docker multi-stage Distillery releases useful. https://zorbash.com/post/docker-multi-stage-elixir-distillery-releases/