High Level Application Routing with StarLogic, StarMap, and StarShine - An idea in the making

I'm usually against using frameworks, but a few days ago I realized I could actually design a framework on top of StarShine. This framework was a fun idea I came up with while discussing top level routing of an application.

I wanted to make a Superset of the MVC framework, that focuses purely on the Business Logic part of your application, hence the name StarLogic.

This pattern models an event listener pattern, but does it in a functionally reactive way. Take the following example:

	var StarLogic = require('StarLogic');
	//create a router
	var app = StarLogic();
	function _newId(bo/*Business Object*/) {
	bo.id = new Guid();
	}
	//if id is falsy, give it a new one
	app.addRule({ id: false }, _newId);
	//returns a finished business object
	app.route({});
	//{id: [object Guid]}

view raw StarLogicExample.js hosted with ❤ by GitHub

The idea with this framework, is to define a bunch of simple rules, and have your business logic execute your functions based on the rules. In the above case, any object that passes through the app.route() function will receive an ID if it isn't set already.

High level application routing can occur when you push a route object to a router like this:

	var StarLogic = require('StarLogic');
	//create a router
	var app = StarLogic();
	//fake database module you made
	var DB = require('./DB');
	function _getUser(route) {
	//this is a shared object namespace
	this.user = DB.getUser(route.id);
	}
	function _routeApplication() {
	//do some application stuff here like change the view
	//do some databinding
	this.user;
	//is the returned user
	}
	app.addRule({ controller: "user", id: true, action: true }, _getUser, _routeApplication);

view raw HighLevelRouting.js hosted with ❤ by GitHub

Any object pushed through app will now be checked to see if every rule definition provided is correct, then it will execute _getUser and _routeApplication passing the business object in question to the functions.

Hey wait a minute, what about complex routing and nested routers? Easy. The route function is portable and doesn't rely on this being anything. Here are some examples of where the route function is placed in a proper way.

	var eventApp = StarLogic();
	var route = eventApp.route;
	//every event object will be passed to eventApp
	document.getElementById('myElement').keydown = route;
	function _42KeyDown (evt) {
	evt.preventDefault();
	}
	//this is a bad idea, but you get the idea
	eventApp.addRule({which: 42}, _42KeyDown);
	var subRouter = StarLogic();
	//some random rule
	eventApp.addRule({ bubbles: true }, subRouter.route);
	//Now any keydown event that bubbles will be passed to subRouter for execution
	//add a rule
	subRouter.addRule({ 1:true });
	//create a list of things
	var items = [];
	items.push({1:1}, {2:2}, {3:3});
	//push them to a router
	items.forEach(subRouter.route);
	//now each item will be processed by your defered logic

view raw functional.js hosted with ❤ by GitHub

Essentially you get to design data processes, define application level logic, and design a framework for your application on top of StarLogic. Move over angular, StarLogic is coming to a store near you.

StarShine - 0.1.0 API Finalized, an App Architecture Tutorial, and Factory Inheritence

Here is the presentation on how to get started on using StarShine.

I'm going to demonstrate now how to actually make an app structured on top of StarShine.

	function _eventify() {
	var handlers = {};
	this.on = function(eventName, handler) {
	(handlers[eventName] = handlers[eventName] || [])
	// add the handler to the array
	.push(handler);
	return this;
	}
	this.once = function(eventName, handler) {
	function wrappedHandler() {
	handler.apply(this.off(eventName, wrappedHandler), arguments);
	}
	wrappedHandler.h = handler;
	return this.on(eventName, wrappedHandler);
	}
	this.off = function(eventName, handler) {
	for (var list = handlers[eventName], i = 0; handler && list && list[i]; i++) {
	list[i] != handler && list[i].h != handler ||
	list.splice(i--,1);
	}
	if (!i) {
	delete handlers[eventName];
	}
	return this;
	}
	this.emit = function(eventName) {
	for(var list = handlers[eventName], i = 0; list && list[i];) {
	list[i++].apply(this, list.slice.call(arguments, 1));
	}
	return this;
	}
	}
	function _exposeThis() {
	return this;
	}

view raw eventify.js hosted with ❤ by GitHub

This _eventify method will turn the private namespace of your module into an event emitter. This is useful for many things, but mostly it's a building block for an event emitter Factory. In order to expose the event factory, we simply return this; to expose the methods to the object. Finally, we wrap it in a StarShine factory. Here are some rules to remember.

1. If the parts you create should remain private, create a closure.
2. If the parts you create should only be exposed and the rest of your closures don't rely on it, create a compound factory
3. If the parts you create should be BOTH, create a factory and create an instance in your closure

In this case, I want the event emitter to be public AND private. Option three is our target.

	var EventEmitter = StarShine(_eventify, _exposeThis);
	function _setupEventEmitter(StarShine, window, document) {
	//this turns the private namespace into an event emitter...
	return StarShine.mixIn(this, EventEmitter());
	//and exposes it to the API we are building
	}
	//Setup the app
	var myApp = StarShine(_setupEventEmitter);
	//Execute your code
	var API = myApp(StarShine, window, document);
	//now API has an event emitter

view raw app.js hosted with ❤ by GitHub

Of course, if you wanted events to be private (and therefore not exposed,) simply include the original function that created the event emitter in the first place. You don't even need the _exposeThis function.

	var APP = StarShine(_eventify);
	APP();

view raw simple eventify.js hosted with ❤ by GitHub

Finally, if I want the methods to simply be exposed without referenced internally, I can do factory re-use.

	var APP = StarShine(EventEmitter, _anotherClosure);
	var API = APP();

view raw Option2.js hosted with ❤ by GitHub

Moving on, we should create a couple of closures that define different portions of our application. I'm going to look for anything with a [data-user-control-1] attribute on my dom and put a link inside of it.

	function _renderAllUserControl1(document) {
	//app is an event emitter
	var map = [].map, app = this;
	function _createFragment (documentElement) {
	this.container = document.createDocumentFragment();
	documentElement.appendChild(this.container);
	}
	function _doSomethingWithContainer() {
	//create a bunch of elements
	var a = this.a = document.createElement("a");
	a.href="#goSomeWhere";
	a.innerHtml = "this is a test";
	this.container.appendChild(a);
	}
	//remember, you're going to be passed the index from the .map function
	function _addAnEventListener(documentElement, index) {
	this.a.onclick = function(){
	//UserControls will be defined in this context, see below
	app.trigger("UserControlClick", UserControls[index]);
	};
	}
	function _buildTheApiForMyControl() {
	var private = this;
	return {
	//these methods will be attached to the UserControls list items
	"remove": function() {
	private.container.removeChild(private.a);
	}
	};
	}
	var controlContainers = document.querySelectorAll("[data-user-control-1]");
	var ControlFactory = StarShine(_createUserControl1, _doSomethingWithContainer, _addEventListener, _buildTheApiForMyControl);
	//index and create a user control for each controlContainer
	var UserControls = map.call(controlContainers, ControlFactory);
	APP.on("UserControlClick", function(UserControl) {
	//this method was returned via _buildTheApiForMyControl
	UserControl.remove();
	});
	return {
	//this will be exposed to your global API
	};
	}
	var APPFactory = StarShine(_eventEmitter, _exposeThis, _renderAllUserControl1);
	var myApp = APPFactory(document);

view raw renderUserControl.js hosted with ❤ by GitHub

This is a lot of code to read, so take your time and re-read it.

On the highest level, we define a process. Inside this process, we define a factory for creating a dom fragment and inject it into the container AND the private namespace for later use inside of the _createFragment function.

Then we create an anchor tag using the terrible dom api (encapsulated and transparent to the API consumer!) and append it to the container defined already.

Then we add a click listener to the anchor in a separate process that triggers a global APP event. The this in the parent closure is a reference to the event emitter exposed by our app.

We define an API for the control that can be consumed by the app and anyone who has access to see the UserControl. I put a remove function into the definition of a "UserControl1" as an example.

Finally, I add an event listener to the app to listen for UserControlClick events and remove the anchor from the DOM.

If you define your Application in terms of functions, suddenly everything is modularized and is much easier to maintain. Embrace the "encapsulate and forget about it" principle because you are making building blocks and tools.

The following example is a good place to start for your app.

	StarShine(function(window, document, StarShine){
	'use strict';
	//Immediately Invoked Inline Function
	//Define your application processes
	function _ApplicationProcess(window, document, StarShine){
	var private = this;//share internal variables between other application processes
	//do some code here
	//APP will be defined here after the whole factory executes
	}
	//execute everything once
	var APP = StarShine(_ApplicationProcess)(window, document, StarShine);
	})(window, document, StarShine)

view raw APP.js hosted with ❤ by GitHub

Experiment and make the code work for you.

Now, onto factory inheritence (as promised!)

	//if your factories return an api
	//and they don't need to share their private state between them
	var myCompoundFactory
	= StarShine(Factory1, Factory2, Factory3)
	.proto(Factory1.proto(), Factory2.proto(), Factory3.proto());
	//Just remember that the parameters need to match up for both factories or you may have a problem

view raw CompoundFactory.js hosted with ❤ by GitHub

If you must accept different parameters, or some kind of state needs to be shared between the factories, maybe it would be best to make the combined factories actual private children of the parent factory. Each factory should be a unit or an encapsulated building block designed to operate all by itself.

StarShine factory composition

It's become a habit of mine to discover and re-create my libraries with a twist using a slightly different technique. The flavor of this week is starshine.

	~function(window, define, module, Array, Object){
	'use strict';
	var slice = Array.slice, create = Object.create;
	function mixIn(target, ref) {
	for (var key in ref) {
	if (ref.hasOwnProperty(key)) {
	target[key] = ref[key];
	}
	}
	return target;
	}
	function StarShine() {
	var enclosed = slice.call(arguments),
	proto = {}, type = "anonymous";
	function factory(options) {
	var obj = create(proto), item, i = 0, _len = enclosed.length;
	options = options || {};
	obj._type = type;
	for(;i<_len;) {
	item = enclosed[i++]
	obj = mixIn(obj,typeof item==='function'?item.call(obj, options)||{}:item);
	}
	return obj;
	}
	factory.proto = function() {
	if(arguments.length === 0) {
	return proto;
	}
	proto = slice.call(arguments).reduce(mixIn, proto);
	return factory;
	};
	factory.type = function(factoryType){
	type = factoryType;
	return factory;
	}
	return factory;
	}
	StarShine.mixIn = mixIn;
	if(module) {
	module.exports = StarShine;
	} else if(define) {
	define(StarShine);
	} else {
	window.StarShine = StarShine;
	}
	}(typeof window !== 'undefined'?window:{},typeof define==='function'?define:null,typeof module!=='undefined'?module:null,[], Object);

view raw StarShine.js hosted with ❤ by GitHub

It's easy to overlook a small library like this. Here are a few of it's features.

• StarShine() returns a factory. It's composed of the closures and objects that it gets passed.
• It has built in internal storage and private "shared" variables. (More on that later)
• Objects are defined by Javascript primitives:
  
  1. reusable closures
     
  2. properties
     
  3. methods
     
  4. prototypes
     
• Works like a function composer

Each function closure should encapsulate a piece of functionality like this:

	function defineA(opt) {
	opt.a = "a";
	//this gets mixed into the object
	return {
	"getA": function getA() {
	return opt.a;
	},
	"setA": function setA(a) {
	opt.a = a;
	return this;
	}
	}
	}
	function exposedA(opt) {
	//opt.a is defined here in this context too.
	//You just inherited private shared variables from another context
	return {
	"doubleA": function(){
	opt.a += opt.a;
	return this;
	}
	};
	}
	function superPrivateVaraible() {
	//functions are now like private storage you can manipulate
	var a = "n";
	//this is the object...
	this.privateA = function(){
	return a;
	}
	}
	//Chainable API...
	var AFactory = StarShine(defineA, exposedA, superPrivateVariable).type("AFactory");
	AFactory();
	//has doubleA, getA, setA, _type: "AFactory", privateA

view raw function example.js hosted with ❤ by GitHub

I cannot stress more that being able to share private variables between closures is a crazy fundamental tool that every developer should use. I have personally used something like this in my personal code:

	function _typeA(opt) {
	opt.x = 0;
	opt.y = 0;
	opt.xV = 1;
	opt.yV = 1;
	}
	function _typeB(opt) {
	opt.x = 50;
	opt.y = 50;
	opt.xV = 1;
	opt.yV = 0;
	}
	function _setType(opt) {
	//direct property writing
	this.x = opt.x;
	this.y = opt.y;
	this.xV = opt.xV;
	this.yV = opt.yV;
	//or
	return {
	x: opt.x,
	y: opt.y,
	xV: opt.xV,
	yV: opt.yV
	};
	}
	var A = StarShine(_typeA, _setType);
	var B = StarShine(_typeB, _setType);
	//Re-usable factory pieces are cool

view raw reusable factory pieces.js hosted with ❤ by GitHub

Each factory has it's own prototype, take the following example.

	function _helloWorld () {
	return {
	'hello': 'world'
	};
	}
	var factory = StarShine(_helloWorld);
	//the proto is already set to an object, so this only mixes methods into the prototype
	factory.proto({
	'getHello': function(){
	return this.hello;
	}
	});
	//this does NOT set the prototype reference
	//no arguments returns the prototype
	factory.proto();
	//{
	// 'getHello': function(){
	// return this.hello;
	// }
	//}

view raw example1.js hosted with ❤ by GitHub

There is no way to make a prototype chain using this method, or maybe there is and I'm lazy, but this seems to be the only way I know to get prototypical inheritance:

factory1.proto(factory2.proto());

view raw proto.js hosted with ❤ by GitHub

If someone comes up with a better idea, I would love to modify my code to make it more flexible. Getting access to the prototype itself is useful with instanceof, but I highly doubt it is necessary. Chances are you probably just wanted to create a new prototype and set the _type property. Given the following example:

	factory.type("CustomTypeHere");
	factory();
	//{
	// "_type": "CustomTypeHere"
	//}

view raw factoryType.js hosted with ❤ by GitHub

Accessing a simple property is probably going to be easier on your code and is simply faster.

This library is everything I love about javascript combined into one tiny little package, and I hope you like it.

Request Animation Frame Loops Demystified - How to get started

Today I'm going to start with using snowblower to make some request animation frame loops.

	~function(window, define, module, Array, Object){
	'use strict';
	var slice = Array.slice, create = Object.create;
	function partial(func) {
	var args1 = slice.call(arguments, 1);
	return function(){
	return func.apply(this, args1.concat(slice.call(arguments)));
	};
	}
	function mixIn(target, ref) {
	for (var key in ref) {
	if (ref.hasOwnProperty(key)) {
	target[key] = ref[key];
	}
	}
	return target;
	}
	function argsMixInExec(args, prev, next) {
	typeof next === 'function' ? next.apply(prev, args) : mixIn(prev, next);
	return prev;
	}
	function SnowBlower(proto) {
	var closures;
	proto = proto || {};
	closures = slice.call(arguments,1);
	return function() {
	return closures.reduce(partial(argsMixInExec, slice.call(arguments)), create(proto));
	};
	}
	SnowBlower.mixIn = mixIn;
	SnowBlower.partial = partial;
	if(define){
	define(SnowBlower);
	} else if(module) {
	module.exports = SnowBlower;
	} else {
	window.SnowBlower = SnowBlower;
	}
	}(typeof window !== 'undefined'?window:{},typeof define==='function'?define:null,typeof module!=='undefined'?module:null,[], Object);

view raw SnowBlower.js hosted with ❤ by GitHub

In whatever context you want, make a SnowBlower factory for a stage. Your runtime should create one instance of a stage for every canvas you need.

	function _animationFunctions(){
	//locally cached reference for speed
	var animationFunctions = this.animationFunctions = [],
	slice = [].slice;
	//we use this as a reference to a no Op function to give our API a way to remove animation functions later
	function noOp(){}
	//store these variable out of here so they never have to be allocated inside of your draw loop
	var _funcIndex = -1, _animationIndex = 0, _len = 0;
	requestAnimationFrame(function draw(){
	_animationIndex = 0;
	_len = animationFunctions.length;
	for(;_animationIndex < _len;_animationIndex++) {
	animationFunctions[_animationIndex]();//call the function!
	}
	//find noOps that were declared inside of the draw loop
	_funcIndex = animationFunctions.indexOf(noOp);
	while(_funcIndex > -1){
	//Always remove EVERY noOp function reference outside of the loop
	animationFunctions.splice(_funcIndex, 1);
	//get the next index
	_funcIndex = animationFunctions.indexOf(noOp);
	}
	});
	this.removeAnimationFunctions = function(){
	var idx = 0, funcIdx = -1, len = arguments.length;
	for(;idx<len;idx++){
	funcIdx = animationFunctions.indexOf(arguments[idx]);
	if(funcIdx>0){
	//this can be called INSIDE OF THE ANIMATION LOOP
	animationFunctions = noOp;
	//DO NOT SPLICE HERE
	}
	}
	};
	}
	var Stage = SnowBlower({}, _animationFunctions);

view raw RequestAnimationFrame.js hosted with ❤ by GitHub

Here it is folks. I did not write specific code for your rendering engine. You need to expose whatever stage to the objects your are creating so they can call this code:

	var myStage = Stage();
	function _drawFunc(options){
	options.stage.animationFunctions.push(function(){
	//do your draw stuff and animation here
	})
	}
	var ObjectOnStage = SnowBlower({}, _drawFunc);
	var obj = ObjectOnStage({
	stage: myStage
	});

view raw ObjectOnStage.js hosted with ❤ by GitHub

Piece of cake. Now all you have to do is pick a rendering engine, render the view in the request animation loop, and create your game.

I suggest using PIXI.js or phaser.js because it's a really great API for canvas rendering. Make sure you do all the work before adding the item to the stage. Remove as many variable declarations outside of the draw function as possible to prevent as much resource allocation and memory leaking as possible. Keep it simple. If you want to pass the draw function a parameter or use "this" as the stage, you can modify your request animation loop like this:

	//reference this for use in other functions
	var self = this;
	//modify loop....
	requestAnimationFrame(function draw(){
	_animationIndex = 0;
	_len = animationFunctions.length;
	for(;_animationIndex < _len;_animationIndex++) {
	//call the function with a reference to the stage object and some arguments
	//passing information to the animation functions can definitely be useful
	animationFunctions[_animationIndex].call(self, arguments...);
	}
	//find noOps that were declared inside of the draw loop
	_funcIndex = animationFunctions.indexOf(noOp);
	while(_funcIndex > -1){
	//Always remove EVERY noOp function reference outside of the loop
	animationFunctions.splice(_funcIndex, 1);
	//get the next index
	_funcIndex = animationFunctions.indexOf(noOp);
	}
	});

view raw modified request loop.js hosted with ❤ by GitHub

In the end, everything is logical and fun.

Have any suggestions? Feel free to comment/post on Google Plus.

Thanks!

~function(){'use awesome';console.log('josh')}();

SnowBlower and Object Composition

	~function(window, define, module, Array, Object){
	'use strict';
	var slice = Array.slice, create = Object.create;
	function partial(func) {
	var args1 = slice.call(arguments, 1);
	return function(){
	return func.apply(this, args1.concat(slice.call(arguments)));
	};
	}
	function mixIn(target, ref) {
	for (var key in ref) {
	if (ref.hasOwnProperty(key)) {
	target[key] = ref[key];
	}
	}
	return target;
	}
	function argsMixInExec(args, prev, next) {
	typeof next === 'function' ? next.apply(prev, args) : mixIn(prev, next);
	return prev;
	}
	function SnowBlower(proto) {
	var closures;
	proto = proto || {};
	closures = slice.call(arguments,1);
	return function() {
	return closures.reduce(partial(argsMixInExec, slice.call(arguments)), create(proto));
	};
	}
	SnowBlower.mixIn = mixIn;
	SnowBlower.partial = partial;
	if(define){
	define(SnowBlower);
	} else if(module) {
	module.exports = SnowBlower;
	} else {
	window.SnowBlower = SnowBlower;
	}
	}(typeof window !== 'undefined'?window:{},typeof define==='function'?define:null,typeof module!=='undefined'?module:null,[], Object);

view raw SnowBlower.js hosted with ❤ by GitHub

I'm going to talk about this "library" and why it's very useful. It takes a lot of the compositional techniques of objects and makes it really fun.

Here's an example of how to use SnowBlower.

	~function(window, SnowBlower){
	var Proto = {
	//prototype stuff here
	};
	function _defaultParameters(options) {
	if(!options){
	throw new Error("options is not defined");
	}
	options.x = options.x || 0;
	options.y = options.y || 0;
	options.width = options.width || 100;
	options.height = options.height || 100;
	}
	function _sprite () {
	//"this" is the sprite you are making
	this.x = options.x;
	this.y = options.y;
	this.width = options.width;
	this.height = options.height;
	}
	var SpriteFactory = SnowBlower(Proto, _defaultParameters, _sprite);
	window.SpriteFactory = SpriteFactory;
	}(window, SnowBlower);

view raw Sprite.js hosted with ❤ by GitHub

It takes all the functions and objects that you pass to it, and either executes it in the context of your new object, or mixes it into your new object. If you need polyfills for your environment, just define Array.prototype.reduce, Object.create, and replace the Object.prototype.hasOwnProperty function to reflect your environment.

It's designed to be small and SnowBlower assumes you have all the pieces and closures that define your object up front. If you need to compose factories, you can just create a function that does it for you.

	var proto = {};
	function PartialFactory() {
	var args1 = [proto].concat([].slice.call(arguments));
	return function(){
	return SnowBlower.apply(this, args1.concat([].slice.call(arguments)));
	};
	}
	//Now pass some arguments to PartialFactory to predefine your factory

view raw PartialFactory.js hosted with ❤ by GitHub

This is a DRY method of reusing functions you have already defined to compose objects. The sky is the limit! Just thought I would share this compositional technique with you.

~function(){console.log('josh')}();

Your Instatouch Library is Cute

I love the JS community. In fact, I think it's the best community to be in programming wise. There is so much support when you need help, especially if you have no idea what you are talking about.

I just want to point out a few things that have taken steps backwards in the past few years when it comes to mobile web experience.

There are at least a dozen different libraries like this: https://github.com/ftlabs/fastclick where the goal is to make the web more responsive. As a mobile phone user, these packages make my experience WORSE. There, I said it.

The reason why it's worse, I've found, is because I like to scroll and read content on the page. If my finger happens to press a link while I am swiping on the page, it fires the click event! This is definitely not good if that link happens to do something very permanent. At best, I found myself pressing the back button so much I gave up completely frustrated with my experience.

My recent experience on cheezburger was rather frustrating because the links take up the whole screen! Maybe I'm just too slow, or JS wasn't designed to do this. I'm willing to accept either, but I'm definitely used to the way browsers work on my phone.

Your Instatouch library is cute, but it makes my user experience more difficult in some cases, and only marginally faster in others. Thanks but no thanks guys, I'll take the DOM as it is.

-Josh

Installing Node.js on my Android Phone

I have the LG Optimus G on Sprint (LS970) and had to do a couple of things to my phone before I could start using node from the command line. I had to root, install TWRP, and then install DebianKit (the biggest offender on being a Pain In my Rear.)

Anyway, here is the steps I took to get everything working.

Some notes I had:

1. I could not install anything useful on my phone using apt-get until I resized the debian.img file on the sdcard.
   
2. I had to do a lot of trial and error before I could finally get the debian image resized correctly
   
3. Installing nvm was easy once I had space
   
4. I had fun
   

In functional health:
~function(){console.log('Josh')}()

Yet Another Gulp.js Post - Compositional Gulp

Gulp is the new build tool and I highly recommend that you use it over grunt for building things. I found that it's nice to do something like this (taken straight from the repo example):

	var gulp = require('gulp');
	var uglify = require('gulp-uglify');
	var imagemin = require('gulp-imagemin');
	gulp.task('scripts', function() {
	// Minify and copy all JavaScript (except vendor scripts)
	return gulp.src(['client/js/**/*.js', '!client/js/vendor/**'])
	.pipe(uglify())
	.pipe(gulp.dest('build/js'));
	});
	// Copy all static images
	gulp.task('images', function() {
	return gulp.src('client/img/**')
	// Pass in options to the task
	.pipe(imagemin({optimizationLevel: 5}))
	.pipe(gulp.dest('build/img'));
	});
	// The default task (called when you run `gulp`)
	gulp.task('default', function() {
	gulp.run('scripts', 'images');
	// Watch files and run tasks if they change
	gulp.watch('client/js/**', function() {
	gulp.run('scripts');
	});
	gulp.watch('client/img/**', function() {
	gulp.run('images');
	});
	});

view raw TypicalGulp.js hosted with ❤ by GitHub

I mean look at it, it's really clean, except for the anonymous callback pattern.

Yet maybe I'm missing something here. Take a look at the following snippet:

gulp.task('scripts', function() {/*Run this code*/});

view raw Sneaky_gulp.js hosted with ❤ by GitHub

Take a minute and think about it. This enables you to make command line tools that do whatever you want!

Even better, what if you used a functional composition library like... say... Composer.js?

	var composer = require('Composer.js'),
	customTask,
	gulp = require('gulp'),
	uglify = require('gulp-uglify');
	function uglifyTask() {
	// Minify and copy all JavaScript (except vendor scripts)
	gulp.src(['client/js/**/*.js', '!client/js/vendor/**'])
	.pipe(uglify())
	.pipe(gulp.dest('build/js'));
	}
	customTask = composer().phrase(uglifyTask);
	gulp.task('scripts', customTask);

view raw composer-gulp.js hosted with ❤ by GitHub

So this is really cool, and make your own judgements, but you can do some interesting things with it. For example, remember that this is the object that composer is making, right? See the following.

	var composer = require('Composer.js'),
	gulp = require('gulp'),
	uglify = require('gulp-uglify'),
	customTask,
	state;
	state = {
	//set 'this' here
	vendorJSsrc: '!client/js/vendor/**',
	JSsrc: 'client/js/**/*.js',
	JSbuild: 'build/js'
	};
	function uglifyTask() {
	// Minify and copy all JavaScript (except vendor scripts)
	gulp
	.src([this.vendorJSsrc, this.JSsrc])
	.pipe(uglify())
	.pipe(gulp.dest(this.JSbuild));
	}
	customTask = composer()
	.phrase(state, uglifyTask);
	gulp.task('scripts', customTask);

view raw stateAndClosure.js hosted with ❤ by GitHub

That was fun! Sure it may not be the best way to build your gulp tasks, but surely this allows for mix and match DRY task factories.

Are you going to use it? I'd say get back to writing fun code ;).

In functional health,
~function(){console.log(this)}.call("Josh");
"Josh"

P.S. Don't forget about Composer.symphony

Edit:

	/*
	* Requires
	*/
	var Composer = require('composer.js'),
	gulp = require('gulp'),
	uglify = require('gulp-uglify'),
	imagemin = require('gulp-imagemin');
	/*
	* Configs
	*/
	var config = {
	uglifySrc: ['client/js/**/*.js', '!client/js/vendor/**'],
	uglifyDest: 'build/js',
	imgMinSrc: 'client/img/**',
	imgMinDest: 'build/img'
	};
	/*
	* ComposerGulp
	*/
	var ComposerGulp = Composer(config).motif(gulp);
	/*
	* Define js Task
	*/
	function uglifyTask() {
	this.src(this.uglifySrc)
	.pipe(uglify())
	.pipe(gulp.dest(this.uglifyDest));
	}
	/*
	* Define image Task
	*/
	function imageMinTask() {
	this.src(this.imgMinSrc)
	.pipe(imagemin({optimizationLevel: 5}))
	.pipe(gulp.dest(this.imgMinDest))
	}
	/*
	* Setup Gulp Tasks
	*/
	var image = Composer.symphony(ComposerGulp, imageMinTask);
	gulp.task('image', image);
	var js = Composer.symphony(ComposerGulp, uglifyTask);
	gulp.task('js', js);
	var _default = Composer.symphony(ComposerGulp, uglifyTask, imageMinTask);
	gulp.task('default', _default);

view raw ComposerGulp.js hosted with ❤ by GitHub

This example shows the sheer power of symphony which give you DRY tasks given a good configuration. Watch out though, because this is a Object.created version of gulp.

That's a Novel Script

I revisited my old library NovelScript.js and realized how bad it was. No wonder nobody wanted to use it. It was insanely opinionated and had a terrible plugin system. I set out to fix these things a few days ago, and here's what I came up with.

(Note: I'm not necessarily advertising NovelScript more than I am sharing my design philosophy.)

I wanted something to give my Visual Novel a backbone, so I made a list of things I would need to create it myself:

1. An event engine that gave me a bit more control than the native one
2. I need some standard events
3. Some standard way to load images, sounds, and music
4. A good way to expose the DOM to me to make it feel more like an HTML app
5. A really good mixin/plugin engine that enclosed functionality using functions
6. A couple standard draw functions
7. Abstracted audio functions

What I did instead

I made sure that I wasn't reliant on anything except Composer.js which became the plugin engine. It allows the developer to extend NovelScript in a very meaningful way that didn't impede on the developer.

Events

I grabbed a small event engine and learned how it worked, then redesigned it to contain "Default" events that ran after the event stack ran. For instance: if I trigger "page:draw", I would want the function that actually draws the page to be the "default" one instead of one the other events on the stack. Setup events should not actually draw on the canvas.

Images

I wanted a way to expose the DOM api and use mixins to define image elements inside of the options config. A simple JSON Config looks like this:

	var options = {
	images: {
	"image1":{
	style:{
	maxHeight:"800px",
	maxWidth: "600px"
	},
	class: "classHere"
	}
	}
	}

view raw options.js hosted with ❤ by GitHub

On top of this, I added the ability to load images on demand, and an event that fires when all images are done loading.

Those options match up to the dom api, including the styles. When using the default draw functions, it will actually calculate the width/height of the image using the dom api if those values aren't specified.

Extending NovelScript? Hell yes.

Changing the way every NovelScript object works is as simple as adding a closure using Composer.js.

	NovelScript.phrase(function(){
	this; //is every NovelScript object.
	Composer.remix(this, {
	//this hash will be mixed into EVERY object.
	});
	Object.defineProperty(this, "prop", {definition here...});
	//etc...
	});

view raw NovelScript-Composer.js hosted with ❤ by GitHub

I also wanted to add some play/stop/pause functions to handle my audio.

All in all, I took a really holistic approach and made the API have a really conventional opinion on how to do things. I hope this helps you make your Visual Novel work well! Remember that no matter what you want to do on the web, you still are coding in Javascript, and you should work with what you have.

Good luck!
~function(){console.log("Josh");}();

posted from Bloggeroid

Best Practices Can Change

Spend some time today learning the concepts behind technology coupling shown in this video:



If you'd like you can spend your time complaining about definitions on coupling, or you can accept your new JSX overlords. Or maybe you should just accept that maybe your practices aren't best.

So many feels

For a long time I was victim of this myself, where I found myself writing the same code over and over again, just for the sake of consistency in my C# code. I always had the same business logic functions, calling the same functions on a separate class, yet getting similar results repeatedly, and coupling myself into a corner. I didn't see it at the time, but I was making a total mess of my code!

I found myself trying to implement interfaces on objects I designed on only two classes, with the intention of calling it just once. I found myself having to maintain my object definitions in (I counted it) 25 different places when I had to add a column on the SQL table. Sure, the procedures and parameters changed my definitions, and that part was good, but for the sake of consistency, I wrote all the lines over and over again.

This practice was the worst decision of my life.

What a total waste of my time!

I almost wished I could use LINQ to generate an array in a few lines of code instead of a ridiculous cluster of declarative parameters. (So I did, but that's totally beside the point.)

Making a Change Toward Maintainability and Fun

I actually decided enough was enough about 2 months ago when I started working on some generic Object Extension components. I was going to make C# do the overhead for me instead of relying on declarative stuff. Here are some of the reasons why:

• My front end performance was based on form loading time and not submitting time, because my organization doesn't need realtime processing, they needed data entry
• My code base was the size of a continent and I'm the only maintainer
• Some of the things I wanted could simply Extend Object using Object Extension (More on this later)
• I don't care about your feelings

That last one is a huge one. I don't care what you think, I know my code is easy to maintain and fun to work with. Here's some of the techniques I now use regularly.

• Using a procedure to grab SQL Parameters dynamically
• Using Object Method Extension to perform:
  
  • Reflection operations
  • Dynamic Column evaluation
  • Dynamic Object population
• Creating ASP.NET MVC Web forms insanely fast using reflection
• Make functional components, not structural components

In a sense, I made my C# environment more like JavaScript. There, I said it. I made C# do the JavaScript jig.

You're kidding right?

You know what happened to my code?

It shrunk in half. This code is much more maintainable, because I expressed it in terms of static functions instead of classes, objects, and data types. I practically ignored them (With the exception of the Nullable classes, I really like those.)

Here are some of the methods I implemented that now extend my objects:

• Object.get(String PropertyName) (Returns Object.PropertyName if it exists)
• Object.set(String PropertyName, Value) (returns Object and chains)
• Object.propertyExists(String PropertyName) (returns Boolean)
• new ReflectiveRecord(DbDataRecord myRecord) (returns an encapsulated DbDataRecord that does the following...)
• ReflectiveRecord.populate(Object myObject) (Applies a convention that the Object you are populating has the Same Property Names/Column Names)
• DataAccess.InsertDatabase(String ProcedureName, ParametersObject) (Grabs procedure definition from database and dynamically pulls values out of ParametersObject)

I've yet to work out casting a sql data row to a reflective data record, but there will be a time when I will call something like this...

	var dataRows =
	myCommand.ExecuteReader(CommandBehavior.CloseConnection)
	.Cast<ReflectiveDataRecord>().ToArray<MyClass>();

view raw reflectiveExecuteReader.cs hosted with ❤ by GitHub

...and I won't regret it. I won't regret it a single bit.

This kind of technology makes SELECT * FROM TABLE inside of a stored procedure actually look pretty appealing, instead of selecting a bunch of columns in an unmaintainable fashion.

In the end, I maintain my Business Objects in 2 places. Once on the database server, and once on the front end (or multiple times if I seperate out an Insert/Update object that functions differently with the same property signature.) The best part is that I can simply populate whatever object I want with my data results implicitly, with one line of code, in a repeatable fashion, and have it work in every environment as a side dll that I can include in my project.

Go home Classical Structure, you're drunk!

If you feel disgusted, mad, or think this is bad, you better have a really good reason why, because I haven't found a reason (except for maybe dealing with processor performance on a computationally expensive algorithm.) If you are using C# for something besides rendering a template and gathering your data, this clearly doesn't help you anyway. I like saving my company time and money, and it almost seems like a no brainer when dealing with a childish argument like: "Everyone is doing it."

That sounds like a drug deal to me.

~function(){console.log("Josh");}();

posted from Bloggeroid