Skip to content

Instantly share code, notes, and snippets.

View tobiasoberrauch's full-sized avatar
😀
Working

Tobias Oberrauch tobiasoberrauch

😀
Working
View GitHub Profile
@tobiasoberrauch
tobiasoberrauch / gist:2942715
Created June 16, 2012 22:56 — forked from BenExile/gist:2923448
Parsing FTP LIST Command Responses
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]
@tobiasoberrauch
tobiasoberrauch / gist:2942716
Created June 16, 2012 22:56 — forked from BenExile/gist:2923448
Parsing FTP LIST Command Responses
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]
@tobiasoberrauch
tobiasoberrauch / robot.js
Created December 10, 2012 14:57
Zolmeister
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));
};
@tobiasoberrauch
tobiasoberrauch / LICENSE.txt
Last active August 29, 2015 14:26 — forked from eliperelman/LICENSE.txt
140byt.es polyfill for Array.filter
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
@tobiasoberrauch
tobiasoberrauch / xdebug.php.ini
Created June 23, 2016 20:47 — forked from larsvegas/xdebug.php.ini
xdebug php.ini default config
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
@tobiasoberrauch
tobiasoberrauch / ddd.md
Created July 23, 2016 02:04 — forked from zsup/ddd.md
Documentation-Driven Development (DDD)

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.