Yi Wang's Tag: February 2012

Ender.js - The open submodule library

tags: ender js
Introducing Inject, an open source JavaScript dependency management library for the browser | LinkedIn Engineering
- Takes advantage of modern browser features where possible (e.g. postMessage and localStorage)
Continuous Integration for Mobile | LinkedIn Engineering

Help

tags: CI mobile linkedin
Introducing Inject, an open source JavaScript dependency management library for the browser | LinkedIn Engineering

tags: linkedin inject post
- Modularity and reusability were at the heart of our decision to create Inject. LinkedIn has several dozen front-facing "properties" (pages, sites, products, modules, etc), some with overlapping JavaScript needs and some with unique ones. Before Inject, we would create one "global" JS payload with resources common to all pages, plus a page-specific payload for each property. While this kept the total number of http requests down, it was difficult to manage the dependencies. Moreover, we couldn't load things on demand, which is increasing in importance as we move more logic to the client.
Refactoring towards testable JavaScript, part 1 | The If Works

tags: javascript test
Organizing a project with JS.Packages | The If Works

tags: JS package project
- We use JS.require() to load our codebase onto static pages for running unit tests without the Rails stack, and we use jsbuild and AssetHat to package it for deployment. Nowhere in our setup do we need to manage lists of script tags or worry about load order.
Black-box criteria | The If Works

So if side-effect-heavy programs cause large API surfaces to be a problem, what should we do about it? The answer comes down to something I think of as ‘avoiding framework-isms’. This means that any time you have a framework or host environment in which user input or third-party code drives your application, the sooner you can dispatch to something you control the better. The classic example of this is the ‘fat model, skinny controller’ mantra popular in the Rails community: rather than dump lots of code in a controller that’s only invoked by the host server and framework, turn the request into calls to models. This way, the bulk of the logic is in objects that you control the interface to, and that are easy to create and manipulate, properties that also make them easy to test.

tags: black box criteria
- So if side-effect-heavy programs cause large API surfaces to be a problem, what should we do about it? The answer comes down to something I think of as ‘avoiding framework-isms’. This means that any time you have a framework or host environment in which user input or third-party code drives your application, the sooner you can dispatch to something you control the better. The classic example of this is the ‘fat model, skinny controller’ mantra popular in the Rails community: rather than dump lots of code in a controller that’s only invoked by the host server and framework, turn the request into calls to models. This way, the bulk of the logic is in objects that you control the interface to, and that are easy to create and manipulate, properties that also make them easy to test.
- It means making sure orthogonal components of a user interface do not talk to each other directly, but publish data changes via a message bus.
- If a static type system helps you with that then have at it, but recognize when it’s a symptom of a deeper problem.
ongoing by Tim Bray · Type-System Criteria

tags: type system API surface size
The If Works | This dirt was a building before

tags: javascript blog tech if works
Loading JavaScript Asynchronously

tags: load JS async
On the role of JS.Packages | The If Works

tags: JS package list vs blog post tech
Prototypal Inheritance

tags: javascript prototypal inheritance crockford object
reinh.com: Git Push: Just The Tip

tags: git push