So You Want Your JavaScript Library to Run Everywhere?

Guess this is going to be a running-edit post as the more I dig, the more I find… Damn it, this should be easier.

Originally I wrote:

A very helpful post on SitePen.com: Run-Anywhere JavaScript

All I have to say is what a #*&^Q mess… Suppose it’s not too bad once you work through the details and arrive at stable implementation pattern for your library but it’s a serious mess if you just wander in cold off the street and try to understand the various JavaScript module packaging options in use.

One fairly straight-forward example that seems to cover the bases is is available in the node-uuid module (boofa/node-uuid) on GitHub. I’m reading the SitePen.com blog post in one browser instance and looking at the node-uuid source in another to audit my understanding. Helpful.

Edit (and I’ll leave it here and cover what I learn in another post):

node-uuid seems to be leveraging a boilerplate approach. The SitePen.com blog post is several years old and the most recent comment (a year old) on uRequire appears to be the correct vector from my starting point in the zone of ignorance.

This also will drag me through several topics on the list of things I need to know. For example Yeoman (and everything else required to set up an actually defensible/sensible build and test environment for the ONMjs library which today, although it “works” in the browser, and encapsulates a bunch of really useful ideas (says me) is not the holistic little generally useful library I want it to be).

Posted in Open Source, Software | Tagged , , , , , | 3 Comments

MacBook Pro Trackpad Goes Berserk, Fixed By SMC & PRAM Reset

The trackpad sensor on my 2011 MacBook Pro recently went berserk making my laptop virtually unusable. I had read about the device’s sensitivity to moister and was concerned that I had damaged the sensor recently by getting a few rain drops on it.

Problem symptoms: random cursor movement, random clicks, failure to recognize or correctly identify mutli-touch gestures…

First thing I tried was to shut the laptop down, covering the keyboard with a phone book, and letting the unit sit with rice poured over the trackpad for 30-hours in an attempt to dry out any moister that could have worked its way into the trackpad sensor (water droplets can easily get through the seam around the trackpad). But this didn’t work.

I then tracked down directions to reset the unit’s system management controller (SMC) and reflash its internal PRAM. This worked like a charm for me. I’m not exactly sure what went wrong but this latest procedure solved my problem.

Here’s what I did to reset the SMC and PRAM:

Note: These directions are specific to unibody MacBook’s that do not have a removable battery. If you have a different model MacBook, you’ll need to track down the model-specific “secret handshakes” required to affect SMC/PRAM reset. Also, make sure your data and hard work is backed up! I had no problem that does not mean you won’t.

SMC Reset

  1. Plug the unit in and ensure it’s powered OFF
  2. Press and release LEFT-SHIFT + CTRL + LEFT-OPTION + POWER and then release

PRAM Reset

  1. Ensure the unit is powered OFF
  2. Press and hold LEFT-COMMAND + LEFT-OPTION + ‘P’ + ‘R’ + POWER (continue to hold this key combination through the power-up boot cycle)

If you have a similar issue, hopefully the above procedure works for you as well as it did for me.

Proactive Tip

Note that in OSX Mavericks, in System | Accessibility you can select an option that disables the trackpad if an external mouse is connected (e.g. Bluetooth). I’ve selected this option proactively so that if this ever happens again, simply connecting my Bluetooth mouse will disable the trackpad and allow me to use the laptop.

Good Luck!

If this doesn’t help you, your trackpad might actually be fried. Nobody would give me an exact quote but ballpark you’re looking at $150+ repair and a week w/out your MacBook. Or, $50-75 in parts and an afternoon watching YouTube repair videos and tinkering with small screws to affect the fix yourself.

Posted in Compute, Devices | Tagged , , , , , | 4 Comments

TodoMVC, Model-View-Whatever, and MSOFS

One of my local tech meetup acquaintances showed me TodoMVC.com last night while we were discussing my new ONMjs library. The purpose of TodoMVC.com is to help developers compare and choose among the many open source model-view-* pattern frameworks available today as FOS JavaScript libraries.

TodoMVC presents a simple Todo application template, and challenges the MV* framework authors to implement the missing functionality with their library and then add it to the growing list of options. That’s a cool idea and there’s a lot to be learned by going through the examples and backing source code.

The suggestion was that I should take the challenge and write an ONMjs-based Todo app and bring it to the party. But is ONMjs a model-view-controller (MVC), model-view-view-model (MVVM) or model-view-whatever framework? Or, is it something else entirely?

The short answer is OMNjs is neither a MVC nor MVVM framework.  It’s an MSOFS framework. MSOFS?

MSOFS

MSOFS is an acronym that stands for Model-Store-Observe-Feedback-Signal that you have never heard of because I made the moniker up. In spirit MSOFS builds from and derives from the core concepts of MVC but is more granular, and pedantically insists on using the term ‘model‘ in its canonical sense to mean “a schematic description of a system, theory, or phenomenon that accounts for its known or inferred properties and may be used for further study of its characteristics.”

I think in patterns and consider all efforts to codify general truths worthy. But computer scientists need to stop forking the language and work harder, and think more deeply about explaining these truths in terms that don’t force us all to remap the lexicon depending on what we’re reading and who we’re speaking with. Parenthetically there are others who share this pet peeve of mine, but seemingly we’re a small minority.

 Let’s break MSOFS down into its constituent parts and discuss each in relation to patterns and concepts that are likely familiar to everyone who made it through the first paragraph of this post.

Model – a data model, or model for short, describes the structure (as in topology) and properties (as in attributes) of a data structure in sufficient detail such that a generic software algorithm can manufacture an instance of the modelled data structure, traverse its hierarchical structure, and ascertain if an instance of some randomly sourced data structure instance conforms to the constraints embodied by the model.

Models in MSOFS do not encapsulate the details of operating on an instance of a data structure as they do in MVC. MSOFS models do not take commands; they are used for reference when constructing, traversing, and validating data. As well, models are the basis of data introspection and addressing – two extremely powerful allies in the never-ending battle to write less, more generic, easily testable code.

In the ONMjs library implementation of MSOFS, models are simple JavaScript objects that adhere to some simple syntax and structure rules. That’s it. No magic.

Store – a data store, or store for short, stores an instance of a modelled data structure and embodies the generic algorithm mentioned above that leverages the model to automate the construction, initialization, traversal, and validation of the data instance it contains.

You can liken a MSOFS store to a little industrial robot that does what it does according to an external program without any concern or knowledge about what it’s actually doing. A MSOFS store, like a robot, is designed to perform a fixed set of generic (although not necessarily trivial) functions, is specialized to the task at hand by an external program, and is controlled by external operator.

In the ONMjs library implementation of MSOFS, a store is represented by a run-time instance of the generic ONMjs.Store object. ONMjs.Store implements the generic functionality described above, is specialized by a MSOFS model,  and controlled externally by your application via its API.

In slightly more detail, ONMjs.Store exposes a simple API that allows you to add, remove, enumerate, access, and introspect the data contained within the store. Additionally, ONMjs.Store’s API provides a sophisticated implementation of the observer pattern that your application leverages to monitor and react to changes in store’s contained data.

Readers familiar with the concepts of inversion of control (IoC) and dependency injection will recognize a lot of similarity between a MSOFS store and an object assembler.

Observe – a MSOFS observer is an application-specific subroutine that is called by an ONMjs.Store instance to notify the subroutine that its contained data has been modified. At a high-level of abstraction writing observer subroutines is very similar to writing an event handler that responds to the occurrence of some semantically meaningful condition (e.g. the addition or removal of an object from the store, the mutation of a property value…) in some application-specific way.

MSOFS is deliberately vague about the specific role of observer subroutines. Unlike MVC that formally defines the responsibilities of controller and view subsystems, MSOFS is agnostic to this distinction. This is not because MVC’s formal notion of view and controller is flawed but rather because MSOFS deals at a lower level of abstraction. This means that a MSOFS observer subroutine may occupy either, both, or neither of these roles.

I am personally fascinated by recursive design patterns that can be re-applied at various levels of abstraction because they afford such great opportunities to write generic and re-usable code. MVC is recursive pattern but in my experience it’s rather difficult to build and maintain hierarchical MVC’s (e.g. the top-level MVC’s model is itself an MVC and so on…) As well, attempting to document and explain the details of such systems is an onerous task.

MSOFS suggests a more granular, lower-level separation of concerns, roles, and responsibilities  than MVC  that, to my way of thinking, is much simpler to  understand and apply recursively .

Feedback – feedback is the act of mutating the data contained within a MSOFS store. The term was chosen because it is typical in systems that leverage the MSOFS pattern that data mutation is affected by MSOFS observer subroutines responding to a data change event. Insofar as data mutation originated the change event in the first place, an observer who reacts by further mutating the data establishes a feedback loop.

Feedback is not solely limited to observer subroutines however. Routines that handle user input, network request completion etc. that mutate the contents of a store are also considered to be part of the feedback loop.

Signal – MSOFS signals are essentially callbacks to observer routines dispatched by a store in response to a data change event. Data change signals differ from data change events in that a change event actuates, typically, more than one signal.

For example, the addition of a new data object instance to a store is considered a change event that initiates multiple signal callbacks. Specifically, adding a new data object to a store dispatches a series of signal callbacks notifying observers of the addition of the object, its constituent namespaces, and the modification of parent objects and their namespaces.

MSOFS in Action

My new ONMjs library is based on the MSOFS pattern and is now available on GitHub (sources, documentation (in progress), and download links).

Edit: Since I wrote this post I’ve received some great feedback alerting me to all kinds of stupid rookie JavaScript ECMAScript mistakes manifest in the  ONMjs implementation. ONMjs is not production code yet. This post coincides with v0.1.00 alpha release and is intended primarily to foster discussion about  the MSOFS  pattern and the ONMjs API. Performance issues notwithstanding, the API is unlikely to change much if at all based on the feedback I received so far.

Additionally, I’ve posted several simple JSFIDDLE projects that demonstrate these concepts in action.

I’m still on the fence about building an official TodoMVC app (we worked out the basic data model and built a functional todo list (minus routing and persistence) in about 5-minutes last night using ONMjs and I sort of lost interest after that because it’s not really a big enough problem to merit all the abstraction). But I should probably do it as a learning exercise (when I’m done with the library docs…)

MVVM

I mentioned the Model-View-View-Model (MVVM) pattern earlier this article but focused mainly on Model-View-Controller (MVC) in the discussion above because it’s more widely known and more closely related to MSOFS than is MVVM.

As an aside, I’ve spent quite a lot of time this year playing with the fantastic Knockout.js MVVM framework and highly recommend this library for client-side UI work.

The way I’ve been using Knockout.js is rather unique however. Rather than relying on MVVM to manage my data, I leverage MSOFS (via ONMjs) to manage my data and leverage observers to initialize and update my model views, and select view models in response to data change signals.

Using these two patterns together is extremely powerful. In particular ONMjs’ support for data addressing and introspection allows me to author exceptionally flexible and re-usable Knockout.js code.

You can see a ridiculously complicated and abstract example of this in action in the Encapsule Project Schema HTML 5 SPA that currently comprises several data models, and a dozen or so lines of JavaScript code that initializes ONMjs and connects all the observers that are 100% generic (i.e. they leverage introspection to adapt dynamically to whatever data model you throw into the app). It’s currently kind of a mess (sorry) but at this point it’s really nothing more than a fancy test harness for ONMjs and the observer subroutines I’ve written with Knockout.js.

Comments & Questions?

I would welcome comments and questions on this article but not here on this blog please. If you’re interested in this topic and have questions I’ve set up the ONMjs Google Group for this purpose.

Posted in Compute, Internet, Open Source, Software | Tagged , , , , , , , , , , | Leave a comment

GoIntoTheWoods.com

Here’s a great web app for locating trails in Washington State. According to what little information is available from the authors, they’re leveraging data from the Washington Trails Association website and overlaying on the map with killer search features. Very cool.

http://www.gointothewoods.com/

Posted in Hiking, Outdoors, Sport | Tagged , , | Leave a comment

Linux Screencasting

Super useful how-to: http://nienhueser.de/blog/?p=469

Posted in Open Source, Software | Tagged , | Leave a comment

Presenting ONMjs @ SeaLang on 2013.11.06

I’ll be doing my first public talk on the forthcoming ONMjs library at the Seattle Programming Languages Meetup group on November, 6th 2013 in Redmond, WA. If you’re local, I encourage you to come.

Details are posted on the Encapsule Project blog here:

http://blog.encapsule.org/2013/10/03/presenting-onmjs-sealang-on-2013-11-06/

Posted in General | Leave a comment

Bossie Awards 2013: Best Open Source App Dev Tools

Bossie Awards 2013: The best open source application development tools

I’ve extracted the list and links from the slides for easy reference. A couple I haven’t heard of before here.  I am most interested in the top Javascript libraries personally but something for everyone here.

  1. Bootstrap
  2. LESS
  3. AngularJS
  4. Backbone.js
  5. Enyo
  6. JQuery
  7. Ember.js
  8. Emscripten
  9. D3
  10. X3DOM
  11. PhoneGap/Cordova
  12. Modo Labs Kurogo
  13. Node.js
  14. OpenShift
  15. Cloud Foundry
  16. XAMPP
  17. Adobe Brackets
  18. Notepad++ 8|
  19. Apache Shiro
  20. Jenkins
  21. Enalean Tuleap
  22. Scala
  23. Ruby (link broken in the slides)
  24. Python
  25. Django
  26. IPython
  27. Raspberry Pi
  28. Arduino

I would like to see my work up on this list someday… Back to work – the damn code doesn’t write itself (yet).

Posted in Compute, Design, Internet, Open Source, Software | Tagged , , , , | Leave a comment

Preparing to Release Yet Another Javascript Framework

Seems there are a lot of popular Javascript frameworks out there. But none up to the task of building a CAD program in HTML 5.

My work on Encapsule Project Schema (a single-page HTML 5 app that wants to be a CAD program someday) has evolved over the course of this year’s hacking efforts to become a little test harness around a new library I call ONMjs.

STABLE LINK: http://www.chrisrussell.net/html5/schema-13-ONMjs/schema.html#/ (archived snapshot of the app as of this afternoon).

Here’s a little bit about ONMjs:

ONMjs is an Object Namespace Manager designed to simplify the task of building reactive, data-driven web components and applications in Javascript.

ONMjs manages data on behalf of your web application, brokers communication between your application’s subsystems, and provides an architectural framework based the principles of Separation of ConcernsSignal Programming, and Component-Based Software Engineering that makes it easy to build elegantly modular, inherently decoupled applications.

ONMjs was created to simplify the development of complex client-side HTML 5 data visualization and editing applications. The library is designed to work well with popular client libraries such as D3js, and Knockout.js. But, you can use ONMjs in many different types of applications, alone or in combination with other Javascript libraries, and in any environment that supports the execution of Javascript code (e.g.Node.js).

The library comprises a small collection of required Javascript classes, and a collection of optional plug-in modules that provide a baseline client-side UI.

With that little background, now go look at the  Encapsule Project Schema app and realize that the only only non-generic part of the entire app is a declaration of the application’s data model. Huh?

In this example the data model defines an extensible “object model” for Encapsule Project’s Soft Circuit Description Language (SCDL) (the declaration is a Javscript object).  This “model” is fed to ONMjs which manages all the runtime data of the app. All the visual elements in the Schema app are currently “observer” plug-ins; they react to changes and leverage meta-data from the model, and data from ONMjs to update the DOM.

This means that you can trivially change the Schema app into a custom editor for whatever type of data you want simply by initializing it with a different model for the data.

I’m working on the docs and getting the code split out of Schema this week for publication of a preview on GitHub. Please follow @Encapsule on Twitter for updates if this subject interests you. Thanks!

ONMjs test harness build.

ONMjs test harness build.

Posted in Compute, Design, Internet, Open Source, Software | Tagged , , , , , , | Leave a comment

http://artzub.com/ghv/#repo=schema&climit=1010&user=Encapsule

Link | Posted on by | Tagged | Leave a comment

Alexander Hamilton is Rolling In His Grave

Michael Arrington’s (@arrington) blog post on UNCRUNCHED caught my attention today.

(TRYING TO) FACE DOWN THE EVIL AT TECHCRUNCH DISRUPT

There’s a lively debate going on in the comments on his blog.

I wrote (awaiting moderation):

Although I can understand the inclination to believe that the existence of covert domestic spying programs are necessary to protect the republic, I feel it’s absolutely unacceptable to subvert the constitution in order to protect it. The ends do not justify the means; by any reasonable reading of the Federalist Papers these are acts of tyranny.

“If the federal government should overpass the just bounds of its authority and make a tyrannical use of its powers, the people, whose creature it is, must appeal to the standard they have formed, and take such measures to redress the injury done to the Constitution as the exigency may suggest and prudence justify.”
Alexander Hamilton – Federalist No. 33

When I studied American History I had an excellent teacher who emphasized the importance of reading, and understanding the intent of the Federalist Papers. Recent revelations seem to be quite at odds with the core tenets of our democracy as elucidated in these essays.

THE FEDERALIST PAPERS

I cannot answer the question if domestic spying programs are in fact necessary to protect the republic or not. I have no first-hand knowledge about the details of the programs or the threats they’re designed to combat. But this is a damn slippery slope. And, it’s of great concern to me that the administrative branch appears to be acting with impunity unchecked by congress or the courts.

Alexander Hamilton

+$0.02 – now back to software…

Posted in Politics | Tagged , , | Leave a comment