Tuesday, April 8, 2014

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:


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:


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.


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.

Wednesday, April 2, 2014

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.


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.


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.


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


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.


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.


Experiment and make the code work for you.

Now, onto factory inheritence (as promised!)


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.

Tuesday, March 25, 2014

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.


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: 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: Each factory has it's own prototype, take the following example. 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: 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:
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.

Friday, February 28, 2014

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.


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.


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:


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:


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')}();

Monday, February 24, 2014

SnowBlower and Object Composition


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.


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.


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')}();

Wednesday, February 19, 2014

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

Tuesday, February 18, 2014

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')}()