snippet comm | |
{# ${1} #} | |
snippet tw | |
{% ${1} %} | |
snippet ifel | |
{% if ${1} %} | |
${2} | |
{% else %} | |
${3} | |
{% endif %} |
class MoneyType extends AbstractType implements DataMapperInterface | |
{ | |
public function buildForm(FormBuilder $builder, array $options) | |
{ | |
$builder | |
->add('amount', 'integer') | |
->add('currency', 'string') | |
->setDataMapper($this) | |
; | |
} |
This is in response to a conversation between a few engineers I consider experts in their respective fields:
- Jeffrey Way (of Laracasts) as a technical educator aiming to investigate exposing newcomers to DDD in an easier-to-digest/grasp way.
- Konstantine Kudryashov (Behat, phpSpec, Inviqa) as a BDD consultant
- Mathias Verraes (dddinphp.org, http://verraes.net/) as a significant DDD resource and independent consultant.
Additional context can be sought reading backwards from https://twitter.com/mdwheele/status/527233999744557056. The stream is a bit broken, but the general gist/context is there.
Uncle Bob 11 May 2014 Craftsmanship Frameworks are powerful tools. We'd be lost without them. But there's a cost to using them.
The relationship between a programmer and a framework is similar to the relationship between an executive and an administrative assistant. The framework takes care of all the necessary details, so that the executive can focus on high level decisions.
Think of Rails, or Spring, or JSF, or Hibernate. Think about what writing a web system would be like without these frameworks to help you. The idea is disheartening. There'd be so many little piddling details to deal with. It'd be like endeavoring to construct a mnemonic memory circuit using stone knives and bearskins[1].
And so we gleefully use those glittering frameworks. We joyously intermingle our code with the frameworks' in anticipation of all the benefits they promise. We make the mistake that so many executives have made before us. We marry our secretary.
In preparation for a new gig I'm reading up on the terms Domain-Driven Design, Command-Query Responsibility Segregation, and Event Sourcing. Here are a list of useful texts and talks that I've discovered so far. If anything is missing please leave a comment.
- Eric Evans: What is a model? - "A model is not a UML diagram nor a certain layer of the software. [...]. It is a system of abstractions, it describes selected aspects of a domain, and can be used to solve problems related to that domain."
- Eric Evans: What I've learned since the book - slightly longer talk on Eric's findings since he co-authored the book on DDD.
- Eric Evans: Domain-Driven Design - As far as I can tell, the book on DDD. Haven't read it though.
- architecture was always:
- box - box - cylinder
- then layers:
- ideally:
On M1 machines, Docker for Mac is running a lightweight linux ARM VM, then running containers within that, so containers are essentially running natively. Don't be fooled by the fact the UI or binary CLI tools (e.g. docker
) might require Rosetta.
Within that VM is an emulation layer called QEmu. This can be used by docker to run Intel containers. This does not use Rosetta at all, and has a roughly 5-6X performance penalty. (If you just upgraded your CPU this may result in a similar performance to your old machine!)
Many images in public registries are multi-architecture. For instance at the time of writing on Docker Hub the php:8.0-cli
image has the following digests: