Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
- For your local dev, create a
Dockerfile
that is based on your production image and simply installxdebug
into it. Exemple:
FROM php:5
RUN yes | pecl install xdebug \
&& echo "zend_extension=$(find /usr/local/lib/php/extensions/ -name xdebug.so)" > /usr/local/etc/php/conf.d/xdebug.ini \
/** | |
* # Some Demo API Service | |
*/ | |
var restify = require('restify'); | |
var map = require('map-stream'); | |
var csvify = require('../helpers/csvify'); | |
var Team = require("../models").Team; |
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
This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)
The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array
it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array
part of it away. So how does that work?
The key here is that objects usually have a predefined set of keys, whereas arrays don't:
<?php | |
/** | |
* @author Marco Pivetta <ocramius@gmail.com> | |
*/ | |
use Zend\ServiceManager\ServiceManager; | |
use Zend\Mvc\Service\ServiceManagerConfig; | |
use DoctrineORMModuleTest\Framework\TestCase; | |
use ContentTest\Util\ServiceManagerFactory; | |
use Zend\Loader\StandardAutoloader; |
Mar 2nd, 2009
An efficient workflow for developers in Agile teams that handles features and bugs while keeping a clean and sane history.
At Hashrocket we use git both internally and in our Agile mentoring and training. Git gives us the flexibility to design a version control workflow that meets the needs of either a fully Agile team or a team
//------------------------------------------------------------- | |
// | |
// Hypothesis: | |
// | |
// Promises/A is a Monad | |
// | |
// To be a Monad, it must provide at least: | |
// - A unit (aka return or mreturn) operation that creates a corresponding | |
// monadic value from a non-monadic value. | |
// - A bind operation that applies a function to a monadic value |