- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
- They are the people who get things done. Effective Engineers produce results.
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):
- Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
- Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
- Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
- Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
- Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
- Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht
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.
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
).
Modules are first class, so you can pass them in. Used in EEx, where passed module must implement a behaviour.
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 | |
]) |
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 |
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 |
// Use Gists to store code you would like to remember later on | |
console.log(window); // log the "window" object to the console |