myronmarston

defmodule MyMacros do
  defmacro my_macro() do
    module = __CALLER__.module
    Module.get_attribute(module, :foo) |> IO.inspect(label: "outside quote")

    quote do
      Module.get_attribute(unquote(module), :foo) |> IO.inspect(label: "with unquoted module")
      Module.get_attribute(__MODULE__, :foo) |> IO.inspect(label: "with __MODULE__")
    end
  end

myronmarston

Using OTP's observer (appmon replacement) remotely

$ ssh remote-host "epmd -names"
epmd: up and running on port 4369 with data:
name some_node at port 58769

Note the running on port for epmd itself and the port of the node you're interested in debugging. Reconnect to the remote host with these ports forwarded:

$ ssh -L 4369:localhost:4369 -L 58769:localhost:58769 remote-host

myronmarston

RSpec.configure do |rspec|
  if ENV["CI"]
    rspec.before(:example, :focus) do
      raise "Do not commit examples tagged with :focus"
    end
  else
    rspec.filter_run_when_matching :focus
  end
end

myronmarston

alias Experimental.GenStage

defmodule WorkerPool.Worker do
  @type subscription_options :: Keyword.t
  @type producer :: pid | {pid, subscription_options}

  @doc """
  Starts a worker, subscribed to the provided job producers.
  """
  @spec start_link([producer], Keyword.t) :: {:ok, pid}

myronmarston

    @doc """
    Will ensure the processes with the test does not complete until the process with the
    provided pid has exited. This is necessary when writing multiple tests that start the
    same named process. See https://github.com/elixir-lang/elixir/issues/3854 for more info.

    This accepts either `{:ok, pid}` or just `pid` so that you can use it in a pipeline
    after a `start_link` call.
    """
    def synchronize_death_on_exit({:ok, pid}) when is_pid(pid), do: synchronize_death_on_exit(pid)
    def synchronize_death_on_exit(pid) when is_pid(pid) do

myronmarston

defmodule Registry do
  # ...

  def handle_call({:execute_against_shard, campaign_id, fun}, from, state) do
    {shard_process, state} = find_or_create_shard(campaign_id, state)
    ShardProcess.execute_and_reply(shard_process, fun, from)
    {:noreply, state}
  end
  
  # ...

myronmarston

TL; DR: "mock" and "stub" were the common terminology when RSpec's API was first created but we've realized that using them to create fake objects causes confusion and that double is a much better term.

I wasn't around when RSpec's original APIs were created, so this is a bit of guess work, but here's my understanding.

When RSpec's mocking API was first created, the two common terms used for what we now commonly call "test doubles" were mocks and

myronmarston

require 'rspec/core/rake_task'

RSpec::Core::RakeTask.new(:specs_prep) do |t|
  t.rspec_opts = "--out tmp/specs_task.out"
end

task :specs => :specs_prep do
  results = File.read("tmp/specs_task.out")
  # do something with results
end

myronmarston

RSpec.configure do |config|
  # Either put conditional logic in the hook...
  config.around(:example) do |ex|
    unless ex.metadata[:slow]
      puts "Not tagged slow"
    end

    ex.run
  end

myronmarston

require 'benchmark/ips'
require 'allocation_stats'

def access_slashed_string
  "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis molestie " \
  "elementum urna, a accumsan nunc euismod et. Aliquam porttitor, leo in " \
  "aliquet aliquam, magna quam venenatis nulla, vel sagittis nisi nisi et " \
  "nulla. Nulla quis facilisis turpis, vel blandit risus. Maecenas ut ante " \
  "quis velit pretium pharetra ac rhoncus massa. Nulla quam dui, placerat " \
  "eget quam vel, ultricies eleifend sem."