Because it’s come up a few times on the Elixir slack I figured I should write down a short post on a simple pattern (or two, I guess) for how to handle health checks in a convenient way while avoiding spamming logs.
A post was merged into an existing topic: Erlang Blog Posts
Hi,
I have just written Classical Propositional Logic in Elixir and any feedback is welcome!
Regards,
Adolfo
Oh hey another teacher! ^.^
You might find this interestingly related.
Why not use Polish notation for logic?
In the first of a series of Oban recipes we look at a couple of techniques for enforcing unique background jobs.
Blog post that try to describe what I like in Common Test and features it has that I lack in the ExUnit
In the second of a series of Oban recipes we look at using finite recursive background jobs for backfilling data.
Here’s how to spend less time managing & running all the tools that assist in developing top-notch Elixir code.
Read more about the new ex_check
library: One task to rule all Elixir analysis & testing tools
The third recipe looks at patterns for recursively scheduled jobs without any duplication and the mechanisms that make it possible.
I wrote a post on cleaning up your elixir code using some functional design patterns:
Hope it helps!
The fourth recipe looks at how to keep applications feeling responsive by reporting progress from long running background jobs.
I am in the process of putting together a in depth 2 part blog series on setting up Prometheus and Grafana along side a PostGIS powered Phoenix application. I published Part 1 yesterday: https://akoutmos.com/post/prometheus-postgis-and-phoenix/
Stay tuned for part 2!
Hey! I wrote a post on my first experience with Property based tests in Elixir… It was my first medium post so feedback is very appreciated, hope u like it!
@grufino I liked reading it, easy to follow and understand.
A definite Guide On
10 Common Code Refactoring | Elixir
This article comprises of common Elixir coding techniques that you may or may not know.
A Jist of the Article
We usually encounter a situation like we expect a map has certain key and if not we need to send some default value.
Immediately, we will end up using Map.has_key?
like in the following way
currency =
if(Map.has_key? price, "currency") do
price["currency"]
else
"USD"
If you see any such lines in your code then it is time to refactor them as
currency = Map.get(price, "currency", "USD")
However, you can also take this to the next level like
currency = price["currency"] || "USD"
Except these will not work in the same way when price = %{"currency" => nil}
, and this is an important difference.
Enum.map(pickup, fn
{"latitude", lat} -> {"lat", lat}
{"longitude", long} -> {"long", long}
{"pickupId", pickup_id} -> {"pickup_id", pickup_id}
{"stopName", stop_name} -> {"stop_name", stop_name}
{"zip", zip} -> {"zipcode", zip}
anything -> anything
end)
|> Enum.into(%{})
Every time someone does Enum.map(map, function) |> Enum.into(%{})
Map.new/2
cries.
Of course you are right. I just considered no-key and key with value as nil
are both same. I will update like you said.
Anyway, Good Catch