I’ve released the first version of CredoPlus. It’s a place for cool features not in Credo - but that you want anyway.

This release adds:

• the report_card command (with HTML output!)
• a check for code coverage

https://hex.pm/packages/credo_plus

My latest post about looping in #Elixir through recursion. I rebuilt a few Enum functions as a learning exercise. It was super interesting seeing pattern matching, function clauses, and the cons operator all work together.

https://davidtang.io/2019/01/13/learning-how-to-loop-in-elixir-through-recursion.html

Use IO.write/2 to craft cool CLI output

https://dennisbeatty.com/2019/01/09/cool-clis-in-elixir-with-io-write-2.html

See how to use Telemetry to hook into your app and record Prometheus metrics. This is a continuation of the previous post on instrumenting your app for Prometheus.

https://blog.smartlogic.io/instrumenting-with-telemetry/

I created a dynamic message board using Nerves and Uderzo.

https://nerves.build/posts/uderzo_msg_board

At Badi, we open sourced a few weeks ago Bolt Routing Driver, the Bolt+Routing Neo4j driver that supports clustering for Elixir using bolt_sips.

It means that you can send a read query to the driver and using one of the load balancing strategies will forward it to a chosen core.

# We need to specify when we are sending a write query that will require to be sent to the leader
iex> Bolt.RoutingDriver.write_query("CREATE (n:Person { name: 'Adrian' })")
[debug] [Bolt.RoutingDriver] localhost:7687 query...
{:ok,
 %{
   stats: %{"labels-added" => 1, "nodes-created" => 1, "properties-set" => 1},
   type: "w"
 }}

# Then we can send read queries, that will be executed in a different follower each time
iex> Bolt.RoutingDriver.read_query("MATCH (n:Person {name: 'Adrian'}) RETURN n")
[debug] [Bolt.RoutingDriver] localhost:7688 query...
{:ok,
 [
   %{
     "n" => %Bolt.Sips.Types.Node{
       id: 0,
       labels: ["Person"],
       properties: %{"name" => "Adrian"}
     }
   }
 ]}

# Now, it will run in a different follower
iex> Bolt.RoutingDriver.read_query("MATCH (n:Person {name: 'Eduard'}) RETURN n")
[debug] [Bolt.RoutingDriver] localhost:7689 query...
{:ok, []}

Any feedback or suggestion is more than welcome!

Morphix, a small library for working with Tuples and Lists, has a new release this week, adding stringmorphification (converting atom keys to map keys) to the list of available functions. Many thanks for the pull request from github/bryanhuntesl.

https://hex.pm/packages/morphix/0.6.0

It is a well-know topic within the Elixir community: “To mock or not to mock? :)”

Every alchemist probably has his / her own opinion concerning this topic. José Valim and Plataformatec has published the Hex package Mox which complies with his article on mocking in Elixir.

Personally, I’m not convinced in having to change the code “in service of” testing certain modules. Why would one add abstraction to code of which its purpose isn’t supposed to be interchangeable (with mock modules for instance)?

After some Googling, I found Espec of which I thought that that’s a little bit too much. Finally, I found Mock which could have done the job. But there are two downsides:

1. You cannot use async: true
2. Defining the mock functions could have been done in a more readable way

Based on that, I decided to write MecksUnit which solves just that. An example:

# (in test/test_helper.exs)

ExUnit.start()
MecksUnit.mock()

# (in test/mecks_unit_test.exs)

defmodule Foo do
  def trim(string) do
    String.trim(string)
  end
end

defmodule MecksUnitTest do
  use ExUnit.Case, async: true
  use MecksUnit.Case

  defmock String do
    def trim("  Paul  "), do: "Engel"
    def trim("  Foo  ", "!"), do: "Bar"
    def trim(_, "!"), do: {:passthrough, ["  Surprise!  !!!!", "!"]}
    def trim(_, _), do: :passthrough
  end

  defmock List do
    def wrap(:foo), do: [1, 2, 3, 4]
  end

  mocked_test "using mocked module functions" do
    task =
      Task.async(fn ->
        assert "Engel" == String.trim("  Paul  ")
        assert "Engel" == Foo.trim("  Paul  ")
        assert "Bar" == String.trim("  Foo  ", "!")
        assert "  Surprise!  " == String.trim("  Paul  ", "!")
        assert "MecksUnit" == String.trim("  MecksUnit  ")
        assert "Paul Engel" == String.trim("  Paul Engel  ", " ")
        assert [1, 2, 3, 4] == List.wrap(:foo)
        assert [] == List.wrap(nil)
        assert [:bar] == List.wrap(:bar)
        assert [:foo, :bar] == List.wrap([:foo, :bar])
      end)

    Task.await(task)
  end

  test "using the original module functions" do
    task =
      Task.async(fn ->
        assert "Paul" == String.trim("  Paul  ")
        assert "Paul" == Foo.trim("  Paul  ")
        assert "  Foo  " == String.trim("  Foo  ", "!")
        assert "  Paul  " == String.trim("  Paul  ", "!")
        assert "MecksUnit" == String.trim("  MecksUnit  ")
        assert "Paul Engel" == String.trim("  Paul Engel  ", " ")
        assert [:foo] == List.wrap(:foo)
        assert [] == List.wrap(nil)
        assert [:bar] == List.wrap(:bar)
        assert [:foo, :bar] == List.wrap([:foo, :bar])
      end)

    Task.await(task)
  end
end

Mocking module functions is pretty straightforward and done as follows:

1. Add use MecksUnit.Case at the beginning of your test file
2. Use defmock as if you would define the original module with defmodule containing mocked functions
3. Use mocked_test as if you would define a normal ExUnit test after having defined all the required mock modules
4. Add MecksUnit.mock() in your test/test_helper.exs file

The defined mock modules only apply to the first mocked_test encountered. So they are isolated (despite of :meck having an unfortunate global effect) as MecksUnit takes care of it. Also, non-matching function heads within the mock module will result in invoking the original module function as well. And last but not least: you can just run the tests asynchronously.

Enjoy using MecksUnit (if you prefer unobtrusive mocking). A Github star is very welcome, haha ;)

In this post, we’re going to look at capturing functions and expressions, which can make Elixir code more concise.

https://davidtang.io/2019/01/10/capturing-functions-and-expressions-in-elixir.html

As well as having Ecto use UUIDs as primary keys it is also possible for Ecto to configure PostgreSQL so that it generate the UUIDs:

http://www.swwritings.com/post/2019-01-11-ecto-and-binary-ids-generated-by-postgresql

New version of ExCampaignMonitor (0.9.0) to start working through the transactional API: https://hexdocs.pm/ex_campaign_monitor/0.9.0/ExCampaignMonitor.html#send_smart_email/2

When you have a service module that does something with a third party using a mock module can prove to be a great tool for testing when you don’t want to depend on that external service. In my post I show you how to do that without dependency injection but rather with elixir’s application configuration.

https://polymorphic.productions/posts/using-configuration-to-swap-modules-for-mocks-in-your-elixir-tests

Thoughts from one month of functional programming in Elixir

Elixir has an impressive feature set and a fast-growing community. Coming from an object-oriented background using mostly Java and Javascript, Elixir syntax and structure is both familiar and not.

Processing Large CSV files with Elixir Streams

Elixir Streams are a powerful and elegant way to process large CSV files. In this article I compare the greedy and the lazy approach with memory and cpu benchmarking.

no_touching provides a way to check if your code is calling private functions from other libraries/dependencies! Highly configurable, extremely fast, and a really nice check to add to CI.

https://hex.pm/packages/no_touching

https://medium.com/@blackode/how-to-perform-hot-code-swapping-using-distillery-2-a-live-demo-genserver-state-update-53d8344d9147

This article will guide you to perform hot code swapping in Elixir using the Elixir package distillery-2.0 (at the moment of writing this article).

A live demo on updating GenServer state will stand out as a good example.

Complete instruction set support, 67% increase in efficiency over previous version, and more. View the release notes here

In the latest ElixirCast episode we’ll look at Phoenix contexts. This is a great episode for anyone new to Phoenix or wanting to see how contexts work.

https://elixircasts.io/phoenix-contexts

Phoenix 1.4 Chat Server, Part 4.

This episode covers building an Auth Plug. It will let us restrict any action in any controller to only logged-in users or to only admins. We also set up a special function plug for the user controller for restricting actions to the correct user. E.g. users can edit their own accounts but not each others.

Slides and Video for my CodeMesh talk this year.

http://crowdhailer.me/2018-11-08/message-passing-for-actors-and-humans/