Rhy Moore morewry

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.

AngularJS Directive Attribute Binding Explanation

When using directives, you often need to pass parameters to the directive. This can be done in several ways. The first 3 can be used whether scope is true or false. This is still a WIP, so validate for yourself.

Raw Attribute Strings

<div my-directive="some string" another-param="another string"></div>

Frontend Development

Attention: the list was moved to

https://github.com/dypsilon/frontend-dev-bookmarks

This page is not maintained anymore, please update your bookmarks.

	# make ad hoc compass frameworks behave (show up in list, be import-able like normal)

	# custom vars
	thisplugin_dir = (yours)

	# compass config
	extensions_dir = (yours)
	extensions_path = project_path + extensions_dir
	additional_import_paths = [extensions_dir, extensions_dir + thisplugin_dir + 'stylesheets']

	// ---------------------------------------

	/*

	http://codepen.io/morewry/pen/meBtj

	Use case for defaults:
	providing interface points to override framework defaults with more flexibility and granularity than variables can reasonably provide, ie customize normalizations without editing the stylesheet directly (@content in reverse)

	Use case for swapping extend or include:

	/*
	# Sprite (Theme)

	*/
	// ---------------------------------------

	// Config
	$disable-magic-sprite-selectors: true;
	$sprite-default-margin: 1px;
	$sprite-debug: true;

	$disable-magic-sprite-selectors: true;
	$icons-inline: false;
	$icons-sprite-base-class: "%icons-sprite";
	$icons-layout: vertical; //must in order to get the correct position! -> this appears to be a bug in Compass 0.12.2; @include background-size gives the correct posititon, $var-sprite-position($img) does not.
	$icons: sprite-map("folder-name/*.png");
	@import "folder-name/*.png";

	@each $img in sprite-names($icons) {
	%icon-#{$img} {
	@extend %icons-sprite;

	// Pop quiz!
	// 1. What will x and y be in this code?

	(function() {

	var x = 5;
	var y = 10;
	var coordinates = x, y;
	console.log('First');
	console.log(x);

	{
	"phone" : "all and (max-width: 603px)",
	"desktop": "all and (min-width: 1025px)",
	"tablet" : "all and (min-width: 604px) and (max-width: 1024px)"
	}

	// Pass in a starting view and match comparison
	function findView ( startView, searchFn ) {
	var resultView,
	viewSearch = function ( curView ) {
	curView.getView( function ( nestedView ) {
	if ( searchFn( nestedView ) ) {
	resultView = nestedView;
	}
	else {
	viewSearch( nestedView );