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:



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.



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...

...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

jshint is good, but...

Let's just be upfront here because I don't want to hurt peoples feelings on jshint (which is apparently known for hurting people's feelings.) I can say many things about jshint , and 99% of them are good. In fact, there are a LOT of good practices that jshint enforces that I think are absolutely invaluable. Yet, here I am really just annoyed with a bunch of these "Code errors." Let me give you some examples.

1. I'm a NodeJS developer working on a test suite, using SHOULD and MOCHA, and I use jshint to test and make sure I use good coding practices. Here's what happens:


Well SCREW YOU TOO. Look at all these unmeaningful errors. I mean, require is definitely defined. I shouldn't have to deal with the jshint output like this.

2. I'm working on a token reader for the front end.



What happened here? I expected an assignment and a falsy check to occur during a while loop, and I got this lame output. Sure it's scrutiny and you can easily rewrite it to something like this:


The question is "Why?". So some novice developer can come in and see what your code does faster? Chances are this small obscurity will teach the novice developer about javascript and the things you can do with it. Sure it's "cute" and silly, but is it really worth your time to change your coding style like this? Just document it.


See, that wasn't so hard. I'd rather teach the beginner the "rules" and then break them.

The following example kills me every time:


Expected a 'break' statement before 'default'.

What if I wanted it to bleed over into the cases and use spaghetti code? Apparently novice coders are too dumb to spend time and figure it out for themselves. Chances are if your code is more complicated, you wanted another statement anyway. Yet, what if the offending sample is simple? What if the code happens to be easier to write and read with the switch statement? That's a matter of your opinion and really the decision should be left up to you.

(It also told me console was not defined but that's arbitrary.)

Look, just make a decision for yourself and use jshint to let it find your bugs before you do. Just make sure you read the error and make a determination for yourself if it's worth "fixing."

I probably spend more time sifting through 'console' is not defined more often than I would personally like to.

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

Classical Inheritance is dead and what you can do about it

There is nothing new in this blog post, but all of this is worth mentioning to everyone repeatedly. If javascript was meant to have classes, it would have had them in the first place. Instead we are stuck with the following clunky syntax and keywords to do type checking.



Instead you probably just wanted this.



Look at how simple that is! It's so much faster. Even to a beginner programmer, the hint that this.name may actually be the name property of the object literal.

Need to do instanceOf? Why not do something like this instead?



Seriously! There's so much less code. In fact, why not just  forget the whole "new" paradigm? Well, maybe not forget, but use it wisely. It also begs the question, how do you make objects repeatedly? Don't you need some kind of overhead? What about applying prototypes to already created objects? Or worse. What about multiple linear inheritance?

Your goal when making applications is get the banana. Not the gorilla, not the jungle, and not everything else. See the following video.

Perhaps it might be overstated that using stampit is quite useful. It is also very close at getting the banana. At 10kb I found that stampit was the correct solution on the back end where we control  the modules. Size doesn't matter on the back end. On the front end, it might be more like a fruit salad to a mobile phone. I also have nothing but respect for Eric's library, because it really showcases the fundamental units of object creation.

Could you perhaps have wanted something smaller? (Yeah it's a pretty shameless plug.)

After all, passing callbacks should be really terse.

We should always remember the few components that comprise our objects and functions: Properties, values, closures, functions, prototypes, and contexts.

Edit:
Don't forget to check out the npm registry for my library composer.js.

Canvas Clickable Regions - Demystified

Let's face it, canvas stuff is never terse and annoying. Creating buttons on a canvas is even harder. First you have to draw the button, change it's state, and other complicated things.

For instance, if the user pushes the mouse down on one clickable region, and drags it over to ANOTHER clickable region, the "click" event will still fire and (therefore) fire the second region's click event.

So what kinds of things do we actually need to figure this stuff out?

Well, for starters, let's demystify the mouse event positions.



This will give you a way to get the mouse location of any click event. So let's build our clickable region first.



Cache the canvas and draw an image...



..and the only things that are missing are the click events...



and put it all together!



The final product looks a bit like this, because you totally took the code and made it work for your project.. right? Get coding people!

In functional health,
Josh

Array forEach Synergy

Today I wanted to share another nice and small use case for the forEach loop for the intermediate/beginner javascript developer.



As a disclaimer, my code isn't perfect, it can be optimized, and my goal isn't give you snippets of code to steal. However, I do this to show you how to make your own javascript functions yourself. Take my code and tweak it, add some useful functions that may help you finish your project.

I hope my samples help grow and motivate you to strive and become a better programmer.

In functional health,
-Josh

Sharing: Self Invoked Object Literals

Some techniques aren't new or novel. They are just fun. This isn't really new, or novel either, but it's quite fun.

In fact, some people would probably criticize that it is essentially the same thing as an Immediately Invoked Functional Expression. There are some key differences here though. Take a look at the following code.

It's starting to look like the module pattern, but it creates an object and ships it via function baz to the variable foo with bar's prototype. Alas, the this keyword shows it's confusing head again, but look closely. "this" is the object literal itself.

Finally I'll leave you with a working example.

Sometimes, the "new" keyword is overrated when making objects anyway.

In functional health,
-Josh

Defining Plugin Architecture for Constructor Libraries

Even in a hypothetical world where objects are packaged into black boxes it would seem that convention and configuration butt heads repeatedly until developers are quite frustrated with their code. In the real world it's even more difficult to package up black boxes because the language architecture design is fundamentally flawed. (I'm looking at you Javascript global namespaces!)

So, I've personally set out to develop quick easy ways to make boxes that appear to be black boxes, but are highly configurable.

Here were some of the goals I had in mind for designing my personal plugin Architecture.

1. Had to be easy!
2. Had to be quick!
3. Plugin Convention over configuration
4. Boilerplate-able
5. Should give access to constructor options to determine where the construction of the object goes
6. Should provide a local scope for hidden variables relative to each object.

Here's a boilerplate you can use to create something like I'm describing.

If some of that code looks confusing to you, I suggest looking at the concept of functional expressions. They give you a "pseudo-blackbox" that can see the global namespace.

If you are good on closures, then we move on to the next step. Actually defining the code to make plugins work. Here's what I personally use:

This code is rather simplistic, but lets take a look a bit deeper to see the real beauty of it.

This little function right here is where ALL the magic happens. Let me show you an example of why this is "magic." Writing a plugin is very easy to do here.

Boom! Now you can call this:

As if that wasn't enough... let's go back and look at another example. A full on event emitter API.

Take some serious time to learn what just happened here. Each one of the functions created in that script are local to the object itself, because the plugin constructor code is called only once. This allows you to enclose private variables into a black box namespace. It's completely abstracted away to the developer behind the curtain.

In functional health,
-Josh

EMCA Sub Arrays - An Interesting Technique

Dealing with javascript arrays can be a breeze, or it can be bothersome. The array.length property having the ability to change the array is VERY difficult to replicate. You almost cannot make your own typed arrays. At least you can get pretty close. Take the following code snippet I am investigating.

Running this code will make a ZOMBIE array (as I call it.)

(Warning, I am not responsible for unintended "features" your code exhibits.)

function SubArray(length){
   Array.call(this); //"Magic"
   if(typeof length == "number" && length%1==0&&arguments.length==1){
     this.length = length; //Length has to be set manually for some reason.
   }
   else{
     var _len = arguments.length;
     this.length = _len;
     for(var i = 0; i<_len; i++)
        this[i] = arguments[i];
   }
}

SubArray.prototype = [];

var x = new SubArray();

Presto Change-o!

Suddenly you have a strongly typed array, albeit with a few small caveats.

//Evaluate the following
var x = new SubArray();

typeof x; //"object" -- Just like when you declare a new Array....
Object.prototype.toString.call(x); //"[object Object]" -- To be expected
x instanceof Array;//true -- This is the way the Array functionality would be identified

x.push(1); //2
x;//[undefined, 1]
x[2] = "test";

//Drum roll please....
x;//[undefined, 1]

Wait... what? The property wasn't even set! It just disappeared. Or did it? Check console.log(x[2]); . So what really happened is the .length property wasn't set and the array wasn't updated. However, if this particular limitation does not hold you back, it's very easy to work with it because you haven't done ANYTHING to modify a native prototype.

I would probably use this technique for some fun stuff, but what you really wanted was an Array in the first place... so just return an array and add some properties to it instead. It's lame, but it works.

Or you could simply wait for Native Object inheritance in some later version of EMCAscript that is coming down the pipeline.

In functional health, Josh

Replacing the jQuery.each function

http://api.jquery.com/jQuery.each/

Compare the following examples:

Example 1 (Using jQuery):

   $("section").each(function(index, element){
       //do something with element
   });

Or even better

   $.each($("section"), function(index, element){
       //do something with element
   });

Example 2 (Native javascript):

   var elements = document.querySelectorAll("section");
   for(var i=0;i<elements.length; i++){
      var element = elements[i];
   }

Note that these pieces of code do the exact same thing.  They loop through all the elements in an array.  In fact the first solution looks very elegant.  Some might even argue it's the functional way a javascript developer should code.

Nobody, however, should argue which one gets better performance when run in browser.

Honestly, anyone can read the examples, but who really benefits from code like Example 1?  It's not the page viewer, because the client had to download a 45kb library to get "foreach" functionality that makes the page run slower.  It's also not the developer, because the developer missed out on making their code faster. I guess the answer is that nobody truly benefits except for beginners, who get shortchanged unknowingly.

There is however one more suggestion:

 [].forEach.call( nodeListReference, function (node) {
  // now do whatever you want to do with node
});

Feel free to comment below. All opinions are valid and welcome.