Posts Tagged ‘ status

Encapsule Project Next Mocha/Chai Test Author(s)

If you look at my GitHub public commit logs you’ll notice that there’s been very little activity here in 2014. This is deceptive; I’ve joined a start-up in Seattle called Azuqua (http://azuqua.com) and am actively working on a major update to the service based, architecturally, on Object Namespace Manager, Software Circuit Description Language (onmd-scdl npm package), and some other for-now secret sauces (hint: graph theory).

onm npm package is stable (both in the browser via browserify) and on Node.js and I’m actively pushing bug fixes and small enhancements as I find/need them for production work. If you’re interested in using this package in your app and want more information drop me an e-mail. I am happy to answer questions and help as I’m able.

Contributing

I was talking with John-David Dalton (lodash author) after a recent SeattleJS meetup and he advised me to party on Mocha/Chai for my testing needs. So I dove in and think Mocha/Chai is really great. I’ve been writing a ton of tests for new code that derives from onm, but just don’t have the time to circle back and do the same for onm itself.

If you’re interested in learning about the onm lib, I mean really learning it, and are willing to help out writing Mocha/Chai tests please drop me a line.

Schema v0.869 Screenshot

I am currently working on something I call the “navigator” – essentially a Javascript library (compiled from Coffeescript actually)  that accepts as input a Javascript “layout” object declaration.

demo: stable demo link • latest development build

The layout is parsed to create a “tree-view” type thing. However, this isn’t an ordinary tree-view control. Not even close. The ‘navigator’ library allows each node in the tree to be annotated with additional metadata that conveys to the navigator that the menu item should semantically model a concept. “Concepts” are whatever you can declare and insert into the metadata.

The “concept” I’m interested in at the moment is modeling the structure of the SCDL data object model on top of JSON with enough precision to generate the runtime code I need to edit and manage the data objects in my model at the semantic level of SCDL, not JSON.

Starting with the simplest of Javascript objects that defines the menu names in a treeview, I’ve applied the idea of annotating each menu item with additional metadata fed into a set of object factories to allow menu items to be “conceptually bound” to nodes in a JSON object described in metadata.

A tree-view with a single root can be thought of as the root object of a JSON deserialization. Similarly, the children of the root can be thought of as sub-objects, or sub-arrays. Each menu item is annotated in metadata to set it’s associated JSON object type. Additionally, information in the metadata is parsed to determine SCDL-level schema (higher-order than JSON).

The screenshot below is of build 0.869 with the “Advanced” view selected.

Encapsule Project Schema 0.869 (test build)

Encapsule Project Schema 0.869 (test build)

It’s not time-efficient to explain further right now but the level of power the ‘navigator’ gives me is incredible… Navigator allows me to map pretty much any object model to JSON (doesn’t have to be SCDL). You can declare “navigator layout” objects (Javascript objects) for different problem domains (i.e. completely unrelated sets of objects that comprise some sort of “domain specific modeling schema”) and use them in the same application in different instances of navigator. Or, bind a single layout to multiple object models…

v1 Schema will very likely rely very heavily on ‘navigator’ as the core of the application.

Schema Day 32

Schema Day 32

I’ve been busy. The effort must be completed so that we can all design systems graphically and transform them into executing code. I’ll be really happy when this application is done enough to start sending out URI’s and explaining just what the heck this is all about with diagrams.

 

 

Rebooting Encpasule Project for the Web

Repost from: http://www.encapsule.org

Welcome to the Encapsule Project.

The Encapsule Project is an open source effort to apply electrical engineering design and modeling techniques to software development.

Quick update:

I’ve been working to re-imagine the Hyperworx prototype, or at least it’s core concepts, using modern web technologies and am preparing to launch a new single-page HTML5 called “schema” that implements an interactive data visualization and editing environment for working with JSON-encoded Soft Circuit Description Language (SDCL (pronounced “scuddle“)) models.

Briefly, “soft circuits” are the software analogue of a digital circuit board schematics. Just as a digital circuit board schematic captures the essence of a system design to be realized in hardware, a “soft circuit” schematic captures the essence of a system design to be realized in software. Given this, SCDL is a JSON serialization dialect for exchanging “soft circuit” schematics across the Internet.

So what do you do with a “software schematic” that is machine-readable? There are a lot of possibilities. But first, we need some SCDL to fuddle with…

SCDL models are cool:

  • SCDL is based fundamentally on Turing Machine models.
  • SCDL can be used to model any system regardless of its scale.
  • SCDL is not tied to a hardware platform, operating system, or programming language.
  • SCDL is not actually even tied to software: it can be used to model hierarchical systems in any domain (although we’re primarily interested in its application to the software domain here).

SCDL is transformative:

SCDL models are machine-readable abstract system specifications which are exactly what’s required to write a software program that transforms SCDL into an executable runtime that implements your design given a binding to a specific target runtime environment.

For example, it would be possible to write a “transformer” that converts SCDL into a C++ program, or creates a single-page HTML5 application that performs the “transformation” on the client by operating directly on the SCDL JSON.Or, on the server via node.js. Or, all of the above. Maybe we want to model our entire cloud-based enterprise in SCDL and “transform” the clients, custom back-end servers that execute app logic on metal, and everything that glues it all together.

The possibilities are endlessly cool. Please stay tune for updates. The SCDL editor is coming soon!

– Chris

Deprecated to ‘Junk':