View gist:23fd6bddbfaacf4bc84ee43e9be6e88c
$ root@plz-playground:~/please# ./bootstrap.sh
Installing Go dependencies...
pypy not found; won't build parser engine for it.
You won't be able to build Please packages unless all parsers are present.
Building Please...
Build finished; total time 0.36s, incrementality 0.0%. Outputs:
//src:please:
plz-out/bin/src/please
//src:please_parser_python2:
View gist:825e292183f15a8e7e7f134502293b14

If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:

In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):

  1. Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
  2. Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
  3. Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
  4. Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
  5. Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
  6. Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht
View dyanmic_or_di_elixir.md

In many production systems you'll want to have one module capable of talking to many potential implementations of a collaborator module (e.g a in memory cache, a redis-based cache etc). While testing it's useful to control which module the module under test is talking to.

Here are the approaches I can see. The two points that seem to divide the approaches are their tool-ability (dialyzer) and their ability to handle stateful implementations (which need a pid).

Passing modules

Modules are first class, so you can pass them in. Used in EEx, where passed module must implement a behaviour.

View my_app.ex
defmodule MyApp do
use Application
def start(_type, _args) do
import Supervisor.Spec, warn: false
children = [
Plug.Adapters.Cowboy.child_spec(:http, MyApp.Router, [], [
dispatch: dispatch
])
View stage_inspector.ex
defmodule StageInspector do
alias Experimental.{GenStage}
use GenStage
def init(type) when type in [:consumer, :producer_consumer] do
{type, type}
end
def handle_events(events, _from, state = :consumer) do
Enum.each events, &inspect_event/1
View infra-secret-management-overview.md

Currently, there is an explosion of tools that aim to manage secrets for automated, cloud native infrastructure management. Daniel Somerfield did some work classifying the various approaches, but (as far as I know) no one has made a recent effort to summarize the various tools.

This is an attempt to give a quick overview of what can be found out there. The list is alphabetical. There will be tools that are missing, and some of the facts might be wrong--I welcome your corrections. For the purpose, I can be reached via @maxvt on Twitter, or just leave me a comment here.

There is a companion feature matrix of various tools. Comments are welcome in the same manner.

View duration.ex
defmodule Duration do
@moduledoc """
This duration module parses and formats strings
for a time duration in hours and minutes and
optionally seconds (e.g. 01:00 for an hour,
00:01:10 for one minute and ten seconds).
"""
@match ~r/^(?<hour>\d{1,2}):(?<min>\d{1,2}):?(?<sec>\d{0,2})$/
def parse(string) do
View benchmark.rb
require 'benchmark'
require 'json'
HASH = {'a'=>1, 'b'=>[1,2,3]}
class Roda
class << self
attr_accessor :opts
end
end