Mathias STRASSER roukmoute

tmux cheat sheet

(C-x means ctrl+x, M-x means alt+x)

Prefix key

The default prefix is C-b. If you (or your muscle memory) prefer C-a, you need to add this to ~/.tmux.conf:

remap prefix to Control + a

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

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.

ANNOUNCEMENT

I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!

\

	<?php

	class AbstractManagerBase extends \PHPUnit_Framework_TestCase
	{
	protected function getEmMock()
	{
	$emMock = $this->getMock('\Doctrine\ORM\EntityManager',
	array('getRepository', 'getClassMetadata', 'persist', 'flush'), array(), '', false);
	$emMock->expects($this->any())
	->method('getRepository')

	// Source: http://code.google.com/p/gflot/source/browse/trunk/flot/base64.js?r=153

	/* Copyright (C) 1999 Masanao Izumo <[email protected]>
	* Version: 1.0
	* LastModified: Dec 25 1999
	* This library is free. You can redistribute it and/or modify it.
	*/

	/*
	* Interfaces:

	<?php

	use JMS\Serializer\Naming\PropertyNamingStrategyInterface;
	use JMS\Serializer\Metadata\PropertyMetadata;

	class PassThroughNamingStrategy implements PropertyNamingStrategyInterface
	{
	/**
	* Translates the name of the property to the serialized version.
	*

	<html lang="en">
	<head>

	</head>
	<body>


	<pre>
	<script type="text/javascript">

	git branch -m old_branch new_branch # Rename branch locally
	git push origin :old_branch # Delete the old branch
	git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote