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