Tobias Oberrauch tobiasoberrauch

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.

	var response = '', // FTP LIST response as a string
	lines = response.trim().split("\r\n"),
	parsed = [],
	regexp = new RegExp(
	'^([\\-dbclps])' + // Directory flag [1]
	'([\\-rwxs]{9})\\s+' + // Permissions [2]
	'(\\d+)\\s+' + // Number of items [3]
	'(\\w+)\\s+' + // File owner [4]
	'(\\w+)\\s+' + // File group [5]
	'(\\d+)\\s+' + // File size in bytes [6]

	var response = '', // FTP LIST response as a string
	lines = response.trim().split("\r\n"),
	parsed = [],
	regexp = new RegExp(
	'^([\\-dbclps])' + // Directory flag [1]
	'([\\-rwxs]{9})\\s+' + // Permissions [2]
	'(\\d+)\\s+' + // Number of items [3]
	'(\\w+)\\s+' + // File owner [4]
	'(\\w+)\\s+' + // File group [5]
	'(\\d+)\\s+' + // File size in bytes [6]

	var robots = new Array();



	//FightCode can only understand your robot
	//if its class is called Robot
	var Robot = function(robot) {
	};

	Robot.prototype.start = function( ev ){

	function namespace (ns) {
	var parts = ns.split('.'),
	root = window \|\| this;

	return (function walk (obj) {
	if (!root[obj]) { root[obj] = {}; }
	root = root[obj];
	if (parts.length) { walk(parts.shift()); }
	return root;
	}(parts.shift()));

	// Generated on <%= (new Date).toISOString().split('T')[0] %> using <%= pkg.name %> <%= pkg.version %>
	'use strict';
	var moment = require('moment');

	var LIVERELOAD_PORT = 35729;
	var lrSnippet = require('connect-livereload')({port: LIVERELOAD_PORT});
	var mountFolder = function (connect, dir) {
	return connect.static(require('path').resolve(dir));
	};

	DO WHAT THE **** YOU WANT TO PUBLIC LICENSE
	Version 2, December 2004

	Copyright (C) 2011 Eli Perelman http://eliperelman.com

	Everyone is permitted to copy and distribute verbatim or modified
	copies of this license document, and changing it is allowed as long
	as the name is changed.

	DO WHAT THE **** YOU WANT TO PUBLIC LICENSE

	xdebug.auto_trace=1
	;;Type: boolean, Default value: 0
	;;When this setting is set to on, the tracing of function calls will be enabled just before the script is run. This makes it possible to trace code in the auto_prepend_file.

	xdebug.cli_color=1
	;;Type: integer, Default value: 0, Introduced in Xdebug 2.2
	;;If this setting is 1, Xdebug will color var_dumps and stack traces output when in CLI mode and when the output is a tty. On Windows, the ANSICON tool needs to be installed.
	;;If the setting is 2, then Xdebug will always color var_dumps and stack trace, no matter whether it's connected to a tty or whether ANSICON is installed. In this case, you might end up seeing escape codes.

	;xdebug.collect_assignments=0