Interface Vision

Javascript and Homoiconicity: Source-code that is a Data-Structure

2014-09-18T00:00:00+00:00

Introduction

You can mess around with a demo project in github.

Homoiconicity is a feature of a language where the language’s “program code is represented as the language’s fundamental data type” (also see Homoiconic Languages on c2).

Javascript is a loosely typed language whose fundamental datatypes are primitives (strings, floats, etc.) and functions (lambdas) with properties (meaning functions can also be used as objects). From these fundamental data-types, we will create a single fundamental data type for Javascript (called a message).

Homoiconic source-code is a data-structure in and of itself. Programming becomes the composition of this single fundamental datatype which results in the new algorithm (the program) and data-structure at the same time.

Why is Homoiconicity So Cool

Programming is the automation of process. We take real world processes and define them in algorithms that operate against data structures.

Data-structures and algorithms are cool. All the software we see today, and other abstractions like objects and functions, are built from these two abstractions: data-structures and algorithms.

The cool thing about data-structures is the things you can do with them. You can:

store them
load them
traverse them
order them
duplicate them
give them “meaning” in context
pass them between algorithms
search them
splice them
MERGE them
insert elements
delete elements
multiple visual representations
every element has the same signature (no specialization: it’s just data)

and a lot of other cool things.

Imagine then a program whose source-code is a data-structure in and of itself. There is a one-to-one mapping of your source-code with the allocated instances of objects on the heap during run-time. This means anything you can do with a data-structure, you can do to a program: even during run time.

Want to inject behavior at any point in a program: even during run-time? Easily done.
Want to persist any part of your program? Easily done.
Want to check for lack of error handling in a program? Run an agent against the data structure.
Want to merge two programs during run-time? Yep! You can easily merge two programs.
Want to scale your program to support thousands of users? Just make as many copies of the program as you want and run each one in their own thread (say goodbye to issues like re-entrance).

And this:

You can display and edit your program using different visual representations!

Just like you can display and edit trees in many different visual formats, you can display and edit source code visually. You can have multiple visual representations of the same program: each one tailored towards the reader of your program!

It really surprises me that we have gone this far without Homoiconicity going main stream.

Why is Homoiconicity Hard To Do in Languages?

I think I know why it is hard to find languages that are really Homoiconic. However, I have a really hard time articulating the reasons why. Perhaps it could be articulated as follows:

Homoiconic languages don’t need parameterized sub-routines.

If you are creating a language, and remove parameterized sub-routines as the core abstraction for communication of data between sub-routines, you end up with a Homoiconic language.

The fundamental datatypes (messages) take the place of parameterized sub-routines and passing of information between messages becomes an inherent part of the data-structure you create when programming.

Javascript and Homoiconicity

Here is Javascript code that is also a data-structure (both the code and the instances on the heap are a data-structure):

// Write the addition of ((3 + -1) + -1) to the console.
var msgWrite = writeToCon ({
  text: add({
     left: add({
       left: num(3),
       right: num(-1)
     }),
     right: num(-1)
  })
});

msgWrite.go; // invoke the program

How about we persist it:

var persistIt = persist ({
  fileName: "/somefile",
  fileType: "json",
  program: msgWrite
});

persistIt.go; // invoke the program

How about we persist it using a file name and file type entered by a user on a form:

var persistIt2 = persist ({
  fileName: formFieldGet ({
    formName: "persist_form",
    formField: "file_name"
  }),
  fileType: formFieldGet ({
    formName: "persist_form",
    formField: "file_type"
  }),
  program: msgWrite
});

persistIt2.go; // invoke the program

How about we inject behavior to write a message to the console when the file_type form field is accessed:

var persistIt3 = persist ({
  fileName: formFieldGet ({
    formName: "persist_form",
    formField: "file_name"
  }),
  fileType: writeToCon ({
    text: formFieldGet ({
      formName: "persist_form",
      formField: "file_type"
    }),
  }),
  program: msgWrite
});

persistIt3.go; // invoke the program

That’s kinda cool. When the persister-message runs go on the writeToCon-message placed in the fileType property, writeToCon runs the message in the text property.

That eventually causes the text in the form field to propagate up to the writeToCon-message which then writes that text to the console.

The writeToCon-message then propagates the text up to the persist-message which uses the text to determine the file type.

If you look back, you will notice that no matter how complex the program, the interface to it is the exact same. To invoke the behavior of any program you simply call go on that program.

Standardization of behavioral interface is an emergent property of any Homoiconic language and may be a good litmus test to determine if a language is Homoiconic.

But This Looks More Like a Framework Than a Language

Exactly!

In a Homoiconic language, there is no way to distinguish the language itself from the software frameworks built in the language because everything is a fundamental datatype (a message): even scope (see Difficult to Read below).

In my opinion, separation of language and framework is a red-flag that we are doing something wrong.

Fundamental parts of the language are key words (loop, between, forEach, withEach, doWhile, etc.) but the structure of the code does not give any hint as to what those key words are.

var msgLoop = between {
  from: num(2),
  to: num(8),
  by: num(2)
  do: writeToCon({
    text: str("Hello world!")
  })
}

msgLoop.go; // invoke the program

Traditional code would give us a hint as to what the keywords are:

for (int i=2; i<=8; i++) {
  Console.WriteLn ("Hello world!")
}

Difficult to Read

As pointed out by this great blog post on the subject by blue, “it is hard for humans to visually parse as the uniformity of the language often removes any visual cues that we are familiar with in most of the languages”.

You can see an example of a web server configured from scratch here using a Homoiconic language called SipCoffee. In 50 lines of code, we compose a multi-threaded web server that supports socket routing. But it is a little difficult to read at first due to a lack of visual cues. However, remember that since the code is a data-structure, we can display the code in anyway we like: even a visual representation of the code (hint hint).

Perhaps, some day, we will end up with visual programming languages that, behind the scenes, are simply manipulating code that is a data-structure.

Conclusion

Although there is still debate as to what makes a language Homoiconic, I think we have shown that it is indeed possible to program in Javascript using only a fundamental datatype (a message).

Our programs are indeed data-structures both in code and when instantiated on the heap.

Our code being a data-structure gives us the ability to manipulate code just like any data-structure. This means we can join, cut, copy, merge, delete, search, sort, load and save code: even during runtime!

If you find our work on Homoiconicity interesting, please follow us @interfaceVision and/or @erichosick.

Message-Oriented Programming With Javascript

2014-09-03T00:00:00+00:00

Introduction

We are going to talk about Javascript and message-oriented programming (MOP). Javascript is a beautiful language and is a perfect candidate for message-oriented programming.

Why Message-Oriented Programming

The purpose of message-oriented programming is to standardize the behavioral interface of objects. This means, invoking the behavior of any object is the exact same: irrelevant of the behavior we are trying to invoke.

Invoking the addition of two numbers is the same as invoking the behavior to push data through a socket. As we will see below, this also means programming becomes the composition of data structures.

Finally, we are able to fully disconnect mechanism (the framework) from the business behavior (using the framework).

What is Message-Oriented Programming

We use abstractions when we program. The types of abstractions we use generally fall under different programming methodologies.

In object-oriented programming, we use objects as the core abstraction along with attributes, methods, variables and parameters (to name a few).

In functional programming, the core abstraction is functions along with parameters and variables (to name a few).

In message-oriented programming (not to be confused with messaging systems and frameworks), messages and properties are the only abstractions. There are no methods, functions, parameters, variables and so on. A property of a message contains a single message or a composition of messages.

A composition of messages is really a data structure. This means that our programs are actually data structures and, as such, can be manipulated just like you would any data structure. Want to duplicate and run part of a program in it’s own thread? Just copy the program from that point, as you would any data structure, and run it.

Want to store part of your program? Just point at any part of your program and save it as you would any data structure.

Why Abstractions Are Important

How we form mental models of the real world is shaped by the abstractions we use to describe the real world. An object-oriented mental model of a real world system will feel very different from a mental model formed by a functional approach to describing a real world system. The same can be said about different maths.

Messages are, in our opinion, a great way of forming a mental model of real world systems because they are conceptually simpler than functions or objects and require fewer abstractions (no methods, functions, parameters, variables and so on.).

Implementation

Prototypal Inheritance

We need to be able to create instances of messages and we are going to do this using prototypal inheritance.

The general pattern for prototypal inheritance looks something like this:

function object(o) {
  function F() {}
  F.prototype = o;
  return new F();
};

However, the behavioral interface of messages is going to be the exact same so let’s be a little more descriptive of what it means to create a message.

function message(behavior) {
  function Msg() {}
  msg.prototype = behavior;
  return new Msg();
};

Common Behavior For All Messages

In our existing C# framework, we came up with a list of common behavior across all message. In this post, we’ll only provide a few of these common behaviors for brevity.

For now, let’s consider go, asNum and asStr as our common behavior.

go - Accessing this property causes the message’s behavior to run.
asNum - Accessing this property causes the message’s behavior to run as a numeric message.
asStr - Accessing this property causes the message’s behavior to run as a string message.

The behavioral interface for any message will look something like this:

var Message = {
  get go() {
    // code goes here
    return something;
  }
  get asNum {
    // code goes here
    return numeric;
  }
  get asStr {
    // code goes here
    return string;
  }
};

You can also add data to the interface which will be shared for that message type.

Data And Messages

So, we have a way to define the behavior for all messages in our framework. However, how do we get information required by a message into that message to run the message’s behavior? After all, we aren’t using parameterized functions.

What if we pass both behavior and data to create a message. Something like this:

function msg(behavior, data) {
  var Msg = function() {}; 
  Msg.prototype = behavior; // shared behavior and data (if any)
  var msg = new Msg();
  msg.data = data; // instance specific data
  return msg;
};

So, now within one of our behavior properties we could do something like this:

...
get asNum {
  return this.data.val; // where example data was { val: 5 }
};

To create a new Numeric message we could do something like this:

var Num = {
  get go() { return this.asNum; },
  get asNum() { return this.data.val; },
  get asStr() { return this.data.val.toString(); }
};

var newMessage = msg (Num, {val:4})

newMessage.go; // returns 4
newMessage.asNum; // returns 4
newMessage.asStr; // returns "4"

Notice that any data required for a message is located neatly in one property.

Describing Addition Using Messages

To build up an understanding of message-oriented programming, we’re going to add two numbers using messages.

This will look like we aren’t gaining anything by using MOP to implement something as simple as addition but just stick with us.

Programming in MOP is done through the composition of messages. It is very similar to creating a data structure.

To add we will need two messages. A message that knows how to Add and a message that represents a Numerical data type.

// Behavior for a numerical value (same as above)
var Num = {
  get go() { return this.asNum; },
  get asNum() { return this.data.val; },
  get asStr() { return this.data.val.toString(); }
};

// Behavior for addition
var Add = {
  get go() { return this.asNum; },
  get asNum() { return this.data.left.asNum + this.data.right.asNum; },
  get asStr() { return this.data.left.asStr + this.data.right.asStr; }
};

To compose addition we do the following:

var addMsg = msg( Add, {
  left: msg (Num, {val:23} ),
  right: msg( Num, {val:44} )
});

Finally, to use the message we could do one of the following:

addMsg.go; // returns 67;
addMsg.asNum; // returns 67;
addMsg.asStr; // returns "2344"

What is really cool about this is that you can run the same message as different primitives. In this case, we are able to run the Add message as a string or a numeric.

One more example.

var addMsg = msg( Add, {
  left: msg( Sub, {
    left: msg (Num, {val:0} ),
    right: msg( Num, {val:44} )
  }),
  right: msg( Num, {val:44} )
});

Adding Two Numbers Entered Into a Form

Here is where we can start seeing some of the strengths of message-oriented programming.

Let’s create some messages that are able to access HTML input elements:

// Access an HTML Input Element using JQuery
var FormFieldGet = {
  get go() { return this.asNum; },
  get asNum() { return $(this.data.id).val(); },
  get asStr() { return $(this.data.id).val().toString(); }
};

// Update an HTML Input Element using JQuery
var FormFieldSet = {
  get go() { return $(this.data.id).val(this.data.val.go); },
};

Please note that these messages are part of a framework. We can look at them as mechanisms that we use to compose business behavior.

We have html as follows:

<form>
  <input type="text" name="left"> +
  <input type="text" name="right"> =
  <input type="text" name="result">
</form>

When programming using MOP, we will take a different approach to solving problems than we would using traditional OOP or functional programming methodologies. We need to think about composition of behavior. Taking a bunch of small messages and hooking them up to get new types of behavior.

In this specific case, we need to update a field on a form so we will be using a FormFieldSet message:

msg( FormFieldSet, {
  id: "result",
  val: ???
}).go;

Calling go let’s us run the message immediately.

But what do we put in place of val? What value are we trying to set? The value we want is the addition of two things.

msg( FormFieldSet, {
  id: "result",
  val: msg( Add, {
    left: ????,
    right: ????,
  }),
}).go;

The things we want to add are the other two form fields. So, let’s access them and get their values:

msg( FormFieldSet, {
  id: "result",
  val: msg( Add, {
    left: msg( FormFieldGet, { id:"left" } ),
    right: msg( FormFieldGet, { id:"right" } ),
  }),
}).go;

// Using custom Prototyes for FormFieldSet, Add,
// FormFieldGet instead of the shared msg Prototye

FormFieldSet ({
  id: "result",
  val: Add ({
    left: FormFieldGet ({ id:"left" }),
    right: FormFieldGet ({ id:"right" }),
  }),
}).go;

And we are done.

Please note that what you are looking at is 100% business behavior. The structure of the code itself looks very different form the code we used to create the messages in the first place.

There is almost a complete disconnect between how we describe business behavior and the mechanisms that do the work for us. We have 100% encapsulation and a 100% decoupled system (because all messages have the exact same behavioral interface). This is the holy grail of object-oriented programming promised so many decades ago.

Take a moment to look at how clean that Javascript looks. Very consistent in look. Very dry.

The javascript program itself is also a data-structure that can be easily persisted or even traversed. During run time, we can alter the behavior of our program by changing the message composition (this is actually very different from code generation).

We could dump that javascript in a key/value store for easy re-use.

And the code looks so clean. So pure.

Conclusion

Javascript is a very versatile, and awesome, language that supports message-oriented programming. Using MOP, we are able to compose programs that can be manipulated as if they were data-structures.

There is a lot more we can do with this to clean things up. For example, our msg() function could do boxing of primitive data types for us making our message configurations easier to read. We would place this in a library.

If you find our work on message-oriented programming interesting, please follow us @interfaceVision and/or @erichosick.

A Simple Webserver That Could Some Day Challenge the Big Names

2014-06-23T00:00:00+00:00

Introduction

One question we’ve been asked is how fast is the Vision framework? To answer that, we’ve created parts (aka messages) that can be used to configure a web server from scratch. The results are shown below.

The Results

We ran siege on a single 15” macbook pro (C# mono):

sudo siege -b -c300 -r50 http://localhost:3050

with the following results:

Transactions:             15000 hits
Availability:             100.00 %
Elapsed time:             9.55 secs
Data transferred:         12.47 MB
Response time:            0.13 secs
Transaction rate:         1570.68 trans/sec
Throughput:               1.31 MB/sec
Concurrency:              199.18
Successful transactions:  15000
Failed transactions:      0
Longest transaction:      4.39
Shortest transaction:     0.00

the same siege test was ran by Centmin Mod with the following results:

Transactions:             15000 hits
Availability:             100.00 %
Elapsed time:             20.20 secs
Data transferred:         43.89 MB
Response time:            0.27 secs
Transaction rate:         742.57 trans/sec
Throughput:               2.17 MB/sec
Concurrency:              199.77
Successful transactions:  15000
Failed transactions:      0
Longest transaction:      7.43
Shortest transaction:     0.00

We realize the comparison is not apples to apples but we wanted to have something we can start comparing to.

Let’s look at the SipCoffee message-configuration that gave us these results.

Quick Introduction to SipCoffee

SipCoffee is a message-oriented programming language. By that, we mean that all parts within the language are considered messages. A message contains some specific behavior and an aggregate of named-message (a class (message) with computed properties (named-messages)).

A program is created by composing messages. This can also be viewed as creating a data structure which contains both data and behavior (behavior and data-structures are inseparable: as they should be).

When a message is activated, the behavior composed within the message is executed. This may cause named-message (those computed properties of the message) to also active.

We call SipCoffee programs message-configurations because we’ve completely separated mechanisms from the business domain. Any changes you make in a program are directly related to the business domain.

In the message-configuration below, you can twiddle with the Web Server at any level. You can change queue sizes, time out periods, the server port and uri, the number of parts in a part pool, and even the cache size of the socket reader.

Building A Web Server From Scratch

The following is the message-configuration of a very very simple, but complete, WebServer in only 50 lines of SipCoffee.

Scope ( scopeId -2
  ins (
    File ( named "Http200.Body.Html" fileUriStr "./Html/200.html" )
    ArrayByteBuilder ( named "Http200.Header"
      replace Byte ( byte 120 )
      part ArrayByte ( withArrayByte byte ( 72 84 84 80 47 49 46 49 32 50 48 48 32 79 75 13 10 68 97 116 101 58 32 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 13 10 83 101 114 118 101 114 58 32 86 105 115 105 111 110 13 10 67 111 110 116 101 110 116 45 84 121 112 101 58 32 116 101 120 116 47 104 116 109 108 59 32 99 104 97 114 115 101 116 61 85 84 70 45 56 13 10 67 111 110 110 101 99 116 105 111 110 58 32 107 101 101 112 45 97 108 105 118 101 13 10 67 111 110 116 101 110 116 45 76 101 110 103 116 104 58 32 120 120 120 120 120 120 120 120 120 120 120 120 13 10 13 10 ) )
      items ArrayList (
        ins (
          DateTimeNow ()
          WithLength ( part ScopeGet ( withName "Http200.Body.Html" scopeId -2 ) )
        ) ) ) )
  part SocketRouter ( named "restServ" 
    streamSource SocketListener ( backlogQueueSize 2000 
      ipEndPoint IPEndPoint ( port 3050 
        ipAddress DNSLookup ( hostEntryStr "localhost" )
      )
    )
    socketFactory PartPool ( initialSize 500
      item FactoryInstance (
        part PartPoolDecorator (
          part RunWorkerWithTimeOut ( waitTime 60000
            part Scope (
              ins (
                Socket ( named "socket" )
                ArrayByteBuffered ( named "requestBody" sizeGrowBy 1024 sizeInitial 1024 )
                ScopeGet ( named "respHead" scopeId -2 withName "Http200.Header" )
                ScopeGet ( named "respBody" scopeId -2 withName "Http200.Body.Html" )
                HttpHeader ( named "httpHeader" )
              )
              part Array ( run true
                ins (
                  SocketReaderHeaderBody ( autoOpen true
                    streamSource ScopeGet ( withName "socket" )
                    data ArrayByteBuffered ( sizeGrowBy 1024 sizeInitial 1024 )
                    body ScopeGet ( withName "requestBody" )
                    headerEncoder ScopeGet ( withName "httpHeader" )
                    buffer ArrayByteBuffered ( sizeInitial 1024 sizeGrowBy 1024 )
                    terminator ArrayByte ( withArrayByte byte ( 13 10 13 10 ) )
                  )
                  SocketWrite ( autoOpen false 
                    streamSource ScopeGet ( withName "socket" )
                    data ScopeGet ( withName "respHead" )
                  )
                  SocketWrite ( autoOpen false 
                    streamSource ScopeGet ( withName "socket" )
                    data ScopeGet ( withName "respBody" )
                  )
                  NamedMessageGet ( withName "close" 
                    part ScopeGet ( withName "socket" callBehavior false )
                  ) ) ) ) ) ) ) ) ) )

Example messages are Scope, File, ArrayByteBuilder, ArrayByte and Socket (all implemented as classes). Example named-messages are ins, named, sizeGrowBy and withName (all implemented as computed properties).

Let’s break the message-configuration down into smaller parts we can easily explain.

The SocketRouter Message

The SocketRouter message, when activated, listens to a data stream on a given port. Any new connections on that data stream are forwarded to another data stream for handling.

The SocketRouter has two named-messages:

streamSource - The source of all data streams.
socketFactory - The message-configuration that handles reading from and writing to of any incoming data streams.

The message-configuration for the streamSource named-message is very simple.

streamSource SocketListener ( backlogQueueSize 2000 
  ipEndPoint IPEndPoint ( port 3050 
    ipAddress DNSLookup ( hostEntryStr "localhost" )
  )
)

The streamSource named-message is a SocketListener message with a backlogQueueSize named-message of a 2000 message (Yep! 2000 is also a message) and a configured ipEndPoint which is easy to figure out.

The socketFactory named-message is a bit more complicated. We could configure our Web Server to handle one request at a time. However, that isn’t very practical and scales worth shit. We need a way to allow messages to run on multiple threads at the same time.

To do this, we can use factories and part pools.

The FactoryInstance, PartPool and PartPoolDecorator Messages

A FactoryInstance message, when activated, will return a copy of the message-configuration located in the part named-message.

part - The message-configuration we’ll make a copy of.

Our message-configuration is as follows:

FactoryInstance (
  part PartPoolDecorator (
    ...
  )
)

In the above message-configuration, the FactoryInstance message creates a copy of a PartPoolDecorator and all messages configured in the PartPoolDecorator message. This is one of the advantages of programming using data structures as opposed to parameterized functions. Want to create a copy of a program? Just duplicate it (Functions are great at manipulating data structures but don’t make for very good data-structures in and of themselves).

We could implement our Web Server using only the FactoryInstance message-configuration. Each time a request comes in, a copy of the message-configuration to handle the request is made and ran in it’s own thread (more on that below). However, why keep making copies of our message-configuration for every request by a client? Allocating and freeing memory are expensive operations. We should be able to re-use our copied message-configurations. This is where the PartPool and PartPoolDecorator messages come into play.

The messages PartPool and PartPoolDecorator, together, allow any message-configuration to be re-used multiple times throughout the execution of a program.

The PartPool message is simple:

initialSize - The initial number of parts in the pool. If all the parts in the pool are in use, a new item is created and added to the part pool.
item - The message-configuration that is pooled by the PartPool message. This is always configured with some kind of factory. The item’s message-configuration is activated initialSize number of times and the result pooled inside the PartPool message.

The PartPoolDecorator message, when activated, activates the message contained in the part named-message. When the configured-message in part finishes, the PartPoolDecorator message automatically returns itself to it’s part pool.

part - The configured message to activate. When the message is finished, the PartPoolDecorator places itself back into the PartPool.

Using these two messages in conjunction with a factory, we can take any message-configuration and make it re-usable. This allows us to configure very scalable message-configurations.

Our specific message-configuration is as follows:

PartPool ( initialSize 500
  item FactoryInstance (
    part PartPoolDecorator (
      part RunWorkerWithTimeOut (
        ... 
      ) ) ) )

The PartPool message starts out with an initialSize named-message of 500. When the PartPool is first activated, the FactoryInstance message is activated 500 times (on as many threads as we can) and the results are placed in the PartPool message. The PartPool pulls a single message from it’s pool and activates it.

In this case, the PartPoolDecorator is configured to contain a RunWorkerWithTimeOut message. This means the PartPoolDecorator is actually activated in a new thread meaning the PartPool returns control, almost immediately, to it’s parent message: the SocketRouter message. The SocketRouter message is now ready to handle the next incoming request.

The RunWorkerWithTimeOut Message

Here are where things get even cooler. The RunWorkerWithTimeOut message is able to run any message-configuration in a thread. Yep. Multi-threaded programming in SipCoffee is just that simple.

waitTime - The time in milliseconds before the worker thread times out.
part - The message-configuration to run within the worker thread.

The Scope and ScopeGet Messages

Take a quick look at the original message-configuration. What you will notice is that there are no functions, parameters or variables. In message-oriented programming, everything is a message. Even the context/scope that a message is activated in, usually defined with a language using { and } (Defining context in a language isn’t very data-structure friendly), is a message.

To support context, we have a Scope message to define the context a message-configuration runs in.

part - The configured-message to activate within the context.
ins - One or more configured-messages contained within the context of the scope. These can also be viewed as Variables.
scopeId - When configured with a negative numeric message, the scope is “global” in nature. When not configured, the scopeId is based on the managed thread id a message-configuration is ran in (this is really powerful and explained below in detail)

In our message-configuration we have the following Scope message configured:

part Scope (
  ins (
    Socket ( named "socket" )
    ArrayByteBuffered ( named "requestBody" sizeGrowBy 1024 sizeInitial 1024 )
    ScopeGet ( named "respHead" scopeId -2 withName "Http200.Header" )
    ScopeGet ( named "respBody" scopeId -2 withName "Http200.Body.Html" )
    HttpHeader ( named "httpHeader" )
  )
  part Array ( ... )
)

The part named-message contains an Array message (more on that later). The ins named-message contains 5 messages, something like variables, each with a unique name within that Scope’s context:

A Socket message named “socket” - The socket we use to read and write to the stream within the current thread.
An ArrayByteBuffered message named “requestBody” - The buffer where the body of the request from the client is placed.
A ScopeGet message named “respHead” - The header that will be sent to the client.
Another ScopeGet message named “respBody” - The message body that will be sent to the client.
An HttpHeader message named “httpHeader” - The http header received from the client.

Here comes some programming power! A “variable” can be a single message like Socket or it can be another configured message! Yep! Just think of the power you have as a programmer. Variables are actually configured-messages!

Notice that, for this Scope message, the scopeId named-message is not defined. This means, the context of the Scope will be based on the current named thread. Yep! Even more POWER! We can run this message-configuration in as many threads as we want and there is no chance of the “variables” being accessed from multiple threads. You no longer need to worry about re-entrance or things being thread safe within this Scope (this isn’t the case when a Scope message is configured to be global).

In message-oriented programming, accessing a “Variable” is also done using messages. SipCoffee has no equals (=) operator. To access a “Variable” within the current scope, you use the ScopeGet message.

withName - The name of the “Variable”.
named - The unique name of the ScopeGet message (so we can access a ScopeGet message from another ScopeGet message if we like).
scopeId - When configured with a negative numeric message, the scope is “global” in nature. When not configured, the scopeId is based on the managed thread id a message-configuration is ran in (this is really powerful and explained below in detail).

In this example:

ScopeGet ( named "respHead" scopeId -2 withName "Http200.Body.Html" )

The ScopeGet message locates and activates a message named “respHead” in a scopeId of -2. This is configured as follows:

Scope ( scopeId -2
  ins (
    File ( named "Http200.Body.Html" fileUriStr "./Html/200.html" )
  )
)

Awesome! It looks like we have a “global variable” named ‘Http200.Body.Html’ that, when activated, reads from a file named ‘./Html/200.html’.

In this example:

SocketReaderHeaderBody ( autoOpen true
  streamSource ScopeGet ( withName "socket" )
)

the streamSource named-message of the SocketReaderHeaderBody is a ScopeGet message. That message is configured to locate a message named “socket” configured as follows:

part Scope (
  ins (
    Socket ( named "socket" )
  )
)

Even more Awesome! It looks like we have not configured the scopeId meaning that this Scope is based on the managed thread id. When the SocketReaderHeaderBody is activated within a managed thread, the Scope is also contained within that managed thread.

Reading from and Writing to the Stream

To activate messages in a given order, we can use an Array message setting the run named-message to a true message (Yep, even true is a message).

Array ( run true
  ins ( ... )
)

Any messages in the ins named-message of the Array message are activated in the order they were inserted.

Let’s look at how the message-configuration works.

First, we activate a SocketReaderHeaderBody message:

SocketReaderHeaderBody ( autoOpen true
  streamSource ScopeGet ( withName "socket" )
  data ArrayByteBuffered ( sizeGrowBy 1024 sizeInitial 1024 )
  body ScopeGet ( withName "requestBody" )
  headerEncoder ScopeGet ( withName "httpHeader" )
  buffer ArrayByteBuffered ( sizeInitial 1024 sizeGrowBy 1024 )
  terminator ArrayByte ( withArrayByte byte ( 13 10 13 10 ) )
)

autoOpen true - Automatically open the stream source.
streamSource ScopeGet ( withName “socket” ) - the source of the stream is located in a Scoped “Variable” named ‘socket’
data ArrayByteBuffered ( sizeGrowBy 1024 sizeInitial 1024 ) - The header data of the message is an ArrayByteBuffered with an initial size of 1024 bytes and grows by 1024 bytes to place the header data in.
body ScopeGet ( withName “requestBody” ) - The body buffer is located in a Scoped “Variable” named ‘requestBody’
headerEncoder ScopeGet ( withName “httpHeader” ) - The message to encode and decode the header is located in a Scoped “Variable” named “httpHeader”
buffer ArrayByteBuffered ( sizeInitial 1024 sizeGrowBy 1024 ) - The buffer used directly by the socket is an ArrayByteBuffered with an initial size of 1024 bytes and grows by 1024 bytes to place the header data in.
terminator ArrayByte ( withArrayByte byte ( 13 10 13 10 ) ) - The terminator between a message header and body is this ArraByte of 13 10 13 10 which happens to be the terminator between the header and body of html.

Second, we write to the socket the response header:

SocketWrite ( autoOpen false 
  streamSource ScopeGet ( withName "socket" )
  data ScopeGet ( withName "respHead" )
)

autoOpen false - Don’t auto open the data stream because we did that with the read above.
streamSource ScopeGet ( withName “socket” ) - the source of the stream is located in a Scoped “Variable” named ‘socket’. Yep. The same streamSource as above.
data ScopeGet ( withName “respHead” ) - Oh man! Awesome. We are accessing a Variable named “respHead” which is a ScopeGet message which accesses a “Variable” named “Http200.Header”. Of course, in future message-configurations, the response header to write could change.

Third, we write to the socket the response body:

SocketWrite ( autoOpen false 
  streamSource ScopeGet ( withName "socket" )
  data ScopeGet ( withName "respBody" )
)

autoOpen false - Yep! Still don’t auto open the data stream because we did that with the read above.
streamSource ScopeGet ( withName “socket” ) - the source of the stream is located in a Scoped “Variable” named ‘socket’. Yep. The same streamSource as above.
data ScopeGet ( withName “respBody” ) - Oh man! Awesome. We are accessing a Variable named “respBody” which is a ScopeGet message which accesses a “Variable” named “Http200.Body.Html”. We are writing to our socket the information located in a file.

Finally, we close the socket:

NamedMessageGet ( withName "close" 
  part ScopeGet ( withName "socket" callBehavior false )
)

The NamedMessageGet message causes a named message to activate. In this case, the named-message close (implementation is a calculated property accessed using reflection) of that same socket is activated.

And, once all of that runs we “fall-up” the message-configuration and the PartPoolDecorator message returns us to the PartPool to be used again!

Conclusion

Message-oriented programming kicks ass. In 50 lines of code, we are able to create a scalable web server that is able to keep up with the big names. We haven’t even started to optimize our underlying technology and it was written in C#. Imagine if it was implemented in something like Rust (aww please add calculated properties rust people!).

We have a data-structure of messages that is also the behavior of the program. That makes the message-configuration very easily re-used in a multi-threaded environment. We aren’t allocating memory all the time and we are able to activate message-configurations without the overhead of locking and worrying about re-entrance. We get the speed of “single threaded” programming in a multi-threaded environment. Woo hoo!

If you find our work on message-oriented programming interesting, please follow us @interfaceVision and/or @erichosick.

There is No Single Mental Model For Programming

2014-03-18T00:00:00+00:00

Forward

Let’s use biological classification as our taxonomy.

The way mental models are formed between the three domains of literature, music and art are very different. Similar then is textual programming languages and visual programing languages: both different domains.

For each domain, there are different ways to form mental models. For example, within the kingdom of textual languages we have functional, declarative, and object oriented. These also greatly differ in how we understand and form mental models of the programs being created.

This blog is within the context of mental models between different domains. Not different kingdoms.

If music and art were considered “fringe” and we wanted to talk about mental models at the domain level we could say:

Literature is textual causing people to lean towards a single approach to forming mental models within the arts.

Introduction

A majority of programmers will make the point that textual languages are the only way to program a computer: noting that textual languages are remarkable in their compactness.

Textual languages are used to program computers and used by programmers to form mental models. This is why you shouldn’t interrupt a programmer. However, people form mental models using more than just textual languages.

The point we are raising is this:

Programming languages are textual causing people to lean towards a single approach to forming mental models of programs.

Why have we put some much time and effort into using a single approach to program computers, textual languages, when people form mental models in so many different ways?

I was lucky to have a chat with Paul Morrison, the inventor of flow-based programming, and he had this to say on the directions computers could have taken (a perspective from 1968):

Computers evolved out of machines with one instruction counter. Computers could have been anything so if we had trouble giving them instructions it was our fault. We essentially became brainwashed into believing that computers, and computer languages, had to be that way, and generations of programmers were trained to think this way. But there was a time early on when we could have gone a different way.

So, let’s step back some and see if there are other practical approaches to programming computers.

Music, Math and Mental Models

Music

I can’t read sheet music.

I can imagine that people who read sheet music can not only play a song on instruments but also hear that song in their head by simply looking at the sheet music.

Image-1.1: Sheet music (image source){#id-i1-1}

###### Image-1.2: Tibetan musical score (image source) {#id-i1-2}

It is only after years of practice that people are able to build a mental model of music by reading sheet music. Sheet music has been around for hundreds of years remaining basically unchanged. Considering current day technology, is it really the best way to represent music today?

My guess is that one of the reasons why sheet music is still so prevalent is because millions of people have put a lot of effort into being able to read it.

Math

An experienced mathematician doesn’t just see an equation when looking at the Pythagorean theorem. They see much more.

###### Image-1.3: The Pythagorean theorem (created using Codecogs) {#id-i1-3}

A mathematician is able to manipulate the pythagorean theorem in their head building out new ideas and new understandings. They are able to form mental models of what these equations mean. Again, this takes years of study and practice to master. Similar to sheet music, a lot of resources have been invested in training people to use math to build mental models.

So, if I am an experienced mathematician programming mathematical equations into a computer, which representation would I prefer?

###### Image-1.4: What if Mathematicians could program a computer using actual mathematical symbols? {#id-i1-4}

Mental Models and Textual Languages

For math and music, people are using different ways to communicate information between their peers. Not only is the representation different, but the understanding built around the mental models is also different.

To argue that one of these approaches could be used universally would be difficult. How would maths compactness hold up as sheet music?

Perhaps, then, we should reconsider the argument that textual languages are the way to program because they are so compact. Perhaps there are situations where other representations are much more effective at helping programmers build mental models.

Perhaps, like sheet music, textual languages are so prevalent because millions of people hours have been spent learning and using textual languages to program computing devices?

Programming and Mental Models

SQL

SQL is a textual language, an algebra, used to describe relationships between relations. A SQL statement to query the database looks something like this:

SELECT A.*, B.*
FROM A
INNER JOIN B ON B.key = A.key

Yet, that same statement above can be represented visually using sets.

###### Image-1.5: What if sets could be used to program a computer (Image Source)? {#id-i1-5}

It takes a while to master SQL. Often, when people learn SQL, they are shown something like Image-1.5 to help them form a mental model of what the SQL statement is actually doing (Visual Representations of SQL Joins).

Why use sets to teach people how to program only to end up using a textual language, SQL, to actually program the computer? Is the compactness of SQL really so great as to ignore all the prior knowledge and skill people have acquired learning set theory?

Flow-based programming

Flow-based programming is an approach to programming that uses asynchronous systems as opposed to the more synchronous nature of traditional computing devices.

I wanted to create an image similar to the “which visual representation would mathematicians prefer” but wouldn’t even know where to start in trying to represent asynchronism using a textual language (there are just so many approaches).

Image-1.6 is showing more than just a program to list some files. It is showing us a fully scalable, big data-esque, highly asynchronous, highly scalable program to list files.

###### Image-1.6: Flow-based programming is great at representing asynchronous systems (image source). {#id-i1-6}

In fact, describing asynchronous execution using textual languages is really difficult. Using flow-based programming, and the associated visual representation, we are able to quickly build out a mental model of what is happening within the computer.

We do need to be careful to not make the mistake of pushing FBP as the “one way” to represent a program. It is a great way to represent asynchronous manipulation of big-data. However, it might not be the best way to represent a mathematical equation: even if that equation could be executed asynchronously.

Interface Vision, VPLs and Mental Models

It is becoming apparent that there is really no one best way to help people form mental models of what a computer program is doing. In some cases sets may be better, sometimes flow-based programming would do the job, in other cases a mathematical equation and sometimes we need to fall back to textual languages.

Instead of the “one VPL to rule them all” approach to the representation of a program, Interface Vision is building out a domain-agnostic VPL that is able to represent programs in a multitude of visual representations. A VPL for VPLs.

###### Image-1.7: Interface Vision’s VPL is able to show multiple representations of the same program logic. {#id-i1-7}

The light blueish area of Image-1.7 contains a mathematical equation (Yes. We are looking for help from UX/UI designers).

The same blueish area could contain other types of VPLs including a finite state machine, a flow-based program and even source code.

We are able to build upon our users particular domain experiences as opposed to requiring them to learn one or more textual languages.

Conclusion

One of the pain points of learning how to program is learning how to form mental models of problems using textual languages. There is no single mental model for programming (something VPLs have also been guilty of by trying to create single representational models).

Providing an environment that allows people to program a computer within their field of expertise opens up computers to more people and is one more step towards the democratization of programming.

The next pain point to melt away is the technological aspects of creating a VPL for VPLs. The solution is almost as old as computers themselves: messages.

If you find our work interesting and look forward to reading our next post on messaging, please follow us @interfaceVision and/or @erichosick.

The Bay Area Visual Programming Group

2014-02-27T00:00:00+00:00

Introduction

Please help evangelize Visual Programming Languages by joining The Bay Area Visual Programming Group or create a Visual Programing Group meetup in your area.

It’s a new meetup (please read below on why) so there might not be many people there.

Why a New Meetup Group?

I had no idea there would be so much interest in Visual Programming Languages when we made the post Visual Programing Languages - Snapshots.

There didn’t appear to be any groups that focused on Visual Programming Languages in meetup.com so we have created one for the Bay Area and Santa Cruz, CA.

Why Join?

VPLs are not new and the computer industry was heading in that direction in the late 60’s and early 70’s. There were a lot of challenges to overcome: many of which have now been solved.

We are now able to shift back to the VPL/GPL paradigm we strayed from.

Computers can now easily support the load visual programming languages put on them.
Children and students are being introduced to programming through visual programming languages (like Sketch). This means there are a large # of people who are starting to become comfortable with VPLs/GPLs and not just coding.
There have been technological advantages in the IT industry making VPLs/GPLs feasible.
User Experience is a lot better because designers and artists are more involved. Designers are ready to take on the challenges brought about by VPLs/GPLs. Proof? 1990s internet vs 2010s.
We have a better understanding of Human Computer Interaction.
Computers are ubiquitous.

And really because:

You want to fix programming. You know, in your heart, that it makes no sense to have something as amazing as computers, and used by practically everyone on the planet, programmed by coding out complex software frameworks in abstract programming languages only understood by a few.

Conclusion

Just do it.

Visual Programming Languages - Snapshots

2014-02-20T00:00:00+00:00

Introduction

Please take a moment to join a Visual Programming Group in your area.

There didn’t seem to be a place on the net where someone could easily see what all the different visual programming languages (Graphical Programming Languages) look like.

A lot of Snapshots now. It is worth the download wait (I don’t want to split this into multiple pages: it would wreck the experience).

So, this post is just a lot of really cool screenshots and images of different visual programming languages. Have fun checking them all out.

If anyone feels we are breaking any copyright and wants us to remove any of these images, please send us an email. We’ve referenced the images.

If you have a visual language you would like to add to this post, then please send us an email.

If you find our work interesting, please follow us @interfaceVision and/or @erichosick for more posts on visual programming languages.

Discussion on Hacker News.

Visual Programming Languages

There are a lot of domain specific visual languages available to play with and check out. Over the years, we’ve been collecting a list of different environments that we feel, in one way or another, could be viewed as visual programming languages.

We aren’t associated with any of the groups below. We just find their solutions interesting. A lot of these were found by browsing Wikipedia’s Visual Programming Language entry.

{#sketchpad} ### SketchPad Direct Link, Image Source, Wikipedia and Web Site

Maybe the first. 1963.

{#grail} ### GRaIL (Graphical Input Language) Direct Link, Image Source, Youtube and Web Site Kinda

First “iconic” programing ~ 1968

{#aardappel} ### Aardappel Direct Link, Image Source and Web Site

{#adl} ### ADL Direct Link, Image Source and Web Site

{#agentSheets} ### AgentSheets and AgentCubes Direct Link, Image Source, Wikipedia, Youtube and Web Site

{#agilent-vee} ### Agilent VEE Direct Link, Image Source and Web Site

{#alice} ### Alice Direct Link, Image Source, Wikipedia and Web Site

{#amici} ### Amici Direct Link, Image Source and Web Site

{#appacitive} ### Appacitive Direct Link, Image Source and Web Site

{#apple-shake} ### Apple Shake Direct Link, Image Source and Web Site

{#appware} ### AppWare Direct Link, Image Source, Wikipedia and Web Site

{#app-inventor-for-android} ### App Inventor For Android Direct Link, Image Source, Wikipedia and Web Site

{#analog-box} ### Analog Box Direct Link, Image Source and Web Site

{#andescotia} Commercial Use via Andescotia

{#arcgis-model-builder} ### ArcGIS Model Builder Direct Link, Image Source and Web Site

{#audulus} ### Audulus Direct Link, Image Source and Web Site

{#automagic} ### Automagic Direct Link, Image Source and Web Site

{#automator} ### Automator Direct Link, Image Source, Wikipedia and Web Site

{#babuino} ### Babuino Direct Link, Image Source and Web Site

{#blender-sverchok-add-on} ### Blender: Sverchok add on Direct Link, Image Source and Web Site

{#blender-textures-nodes} ### Blender: Textures Nodes Direct Link, Image Source and Web Site

{#blockly} ### Blockly Direct Link, Image Source and Web Site

{#bloodhound} ### BloodHound Direct Link, Image Source and Web Site

{#bounce} ### Bounce Direct Link, Image Source and Web Site

{#cognitoy-mindrover} ### Cognitoy’s Mindrover Direct Link, Image Source and Web Site

{#chipwits} ### ChipWits Direct Link, Image Source and Web Site

{#copper-thoughts} ### Copper Thoughts Direct Link, Image Source and Web Site

{#coral} ### Coral Direct Link, Image Source and Web Site

{#cortex} ### Cortex Direct Link, Image Source and Web Site

{#cybertoolbox} ### CyberToolbox Direct Link, Image Source and Web Site

{#designscript} ### Designscript Direct Link, Image Source and Web Site

{#drakon} ### DRAKON Direct Link, Image Source, Wikipedia and Web Site

{#drawfbp} ### DrawFBP Direct Link, Image Source, Wikipedia and Web Site

Flow-based programming implemented visually by the creator of flow-based programming: John Paul Morrison.

{#dream-maker} ### Dream Maker Direct Link, Image Source and Web Site

{#drupal} ### Drupal Direct Link, Image Source and Web Site

{#dynamo} ### Dynamo Direct Link, Image Source and Web Site

{#engijs} ### Engi JS Direct Link, Image Source, Live! Use It Now and Web Site

{#etoys} ### Etoys / Squeak Direct Link, Image Source, Wikipedia and Web Site

{#eyeon-fusion} ### Eyeon Fusion Direct Link, Image Source and Web Site

{#eyesweb} ### EyesWeb Direct Link, Image Source and Web Site

{#field} ### Field Direct Link, Image Source and Web Site

{#fl-studio} ### FL Studio Direct Link, Image Source, Wikipedia and Web Site

{#flowlab} ### FlowLab Direct Link, Image Source and Web Site

{#foundry-modo} ### Foundry Modo Direct Link, Image Source and Web Site

{#flexmonkey} ### ReDiLab:Node {#redilab-node} Direct Link, Try It Out Here, Calculator, Image Source and Web Site

{#flow-hub} ### Flow Hub and NoFlo Direct Link, Image Source 1, Image Source 2 Web Site 1 and Web Site 2

{#flowstone} ### FlowStone Direct Link, Image Source, Youtube and Web Site

{#generativecomponents} ### GenerativeComponents Direct Link, Image Source and Web Site

{#godot-engine} ### GoDot Engine Direct Link, Image Source and Web Site

{#google-web-designer} ### Google Web Designer Direct Link, Wikipedia and Web Site

{#grasshopper-3d} ### Grasshopper 3D Direct Link, Image Source, Wikipedia and Web Site

{#hopscotch} ### Hopscotch Direct Link, Image Source, Wikipedia and Web Site

{#houdini} ### Houdini (Node Based Workflow) Direct Link, Image Source and Web Site

{#hypercard} ### HyperCard

Note: see also LiveCode

Direct Link, Image Source, Wikipedia and Web Site???

{#hypergraph} ### Hypergraph Direct Link, Image Source and Web Site

{#softimageice} ### ICE (Interactive Creative Environment) Direct Link, Image Source, Wikipedia and Web Site

{#IFTTT} ### IFTTT Direct Link, Image Source, Wikipedia and Web Site

{#ilab-neuromorphic-robotics-toolkit} ### iLab Neuromorphic Robotics Toolkit Direct Link, Image Source and Web Site

{#illumination-software-creator} ### Illumination Software Creator Direct Link, Image Source, Wikipedia and Web Site

{#infosphere-streams} ### InfoSphere Streams Direct Link, Image Source and Web Site

{#intentional-technology} ### Intentional Technology Direct Link, Image Source and Web Site

{#isadora} ### Isadora Direct Link, Image Source and Web Site

{#java-studio} ### Java Studio 1.0 Direct Link, Image Source and Web Site ???

{#jeskola-buzz} ### Jeskola Buzz Direct Link, Image Source, Wikipedia and Web Site

{#kimono} ### Kimono Direct Link, Web Site

{#klieg} ### Klieg Direct Link, Image Source and Web Site

{#knime} ### Knime Direct Link, Image Source and Web Site

{#kodu} ### Kodu (Boku) Direct Link, Image Source, Wikipedia, Youtube and Web Site

{#kyma} ### Kyma Direct Link, Image Source and Web Site

{#labview} ### LabView Direct Link, Image Source, Wikipedia and Web Site

{#ladder-logic} ### Ladder Logic Direct Link, Image Source, Wikipedia and Web Site

{#lamdu} ### Lamdu Direct Link, Image Source and Web Site

{#lava} ### Lava Direct Link, Image Source, Wikipedia and Web Site

{#learnable-programming} ### Learnable Programming

More of a post on different ways to learn programming.

Direct Link, Image Source and Web Site

{#lily} ### Lily Direct Link, Image Source, Wikipedia and Web Site

Really cool and hard to describe. You need to visit their demo web page and watch their videos.

{#limnor-studio} ### Limnor Studio Direct Link, Image Source, Wikipedia and Web Site

{#little-big-planet} ### Little Big Planet Direct Link, Image Source, Wikipedia and Web Site

Someone built an An 8-bit Mechanical Adder in LittleBigPlanet

{#livecode} ### LiveCode

Direct Link, Image Source, Wikipedia and Web Site

Looking for an image.

{#mamba-fx} ### Mamba FX Direct Link, Image Source and Web Site

{#max-msp-jitter} ### MAX/MSP Jitter

Direct Link, Image Source and Web Site

{#marten} ### Marten

Marten is an implementation of the Prograph language.

Direct Link, Image Source and Web Site

{#metaedit-modeler} ### MetaEdit+ Modeler Direct Link, Image Source and Web Site

{#miceonabeam} ### MiceOnABeam Direct Link, Image Source and Web Site

{#mindplus} ### Mind+ Direct Link, Image Source and Web Site

{#mvpl} ### Microsoft Visual Programming Language MVPL Direct Link, Image Source and Web Site

{#mindspider} ### MindSpider Direct Link, Image Source and Web Site

{#minecraft} ### Minecraft Direct Link, Image Source, Wikipedia and Web Site

Considering someone has created a fully programmable computer using Minecraft.

{#minibloq} ### Minibloq Direct Link, Image Source, Wikipedia and Web Site

This has a really cool looking interface.

{#minkoshaderLab} ### Minko ShaderLab Direct Link, Image Source, Youtube and Web Site

{#modkit-arduino-visual-programming} ### Modkit Arduino Visual Programming Direct Link, Image Source and Web Site

{#morphic} ### Morphic Direct Link, Image Source, Wikipedia and Web Site

{#mozilla-appmaker} ### Mozilla Appmaker Direct Link, Image Source and Web Site

This was discussed quite a bit on Ycombinator.

{#mst-workshop} ### MST Workshop Direct Link, Image Source, Wikipedia, Youtube and Web Site

{#neattools-visual-programming-environment} ### NeatTools Visual Programming Environment Direct Link, Image Source and Web Site

{#nevo-studio} ### Nevo Studio Direct Link, Image Source and Web Site

{#nodebox} ### NodeBox Direct Link, Image Source and Web Site

{#nuke} ### Nuke Direct Link, Image Source, Wikipedia and Web Site

{#num3sis} ### Num3sis Composer Direct Link, Image Source and Web Site

{#NXT-G} ### NXT-G Direct Link, Image Source, Youtube Wikipedia and Web Site

Legos!!!

{#openalea-visualea} ### OpenAlea Visualea Direct Link, Image Source and Web Site

{#opendx} ### OpenDX Direct Link, Image Source and Web Site

{#openflippers} ### OpenFlippers Direct Link, Image Source and Web Site

{#open-modelica} ### Open Modelica Direct Link, Image Source and Web Site

{#open-music} ### Open Music Direct Link, Image Source, Wikipedia and Web Site

{#openwire} ### OpenWire Direct Link, Image Source, Wikipedia, Youtube and Web Site

{#orange} ### Orange Direct Link, Image Source and Web Site

{#origami} ### Origami Direct Link, Image Source and Web Site

{#piet} ### Piet Direct Link, Image Source, Wikipedia and Web Site

{#pipes} ### Pipes Direct Link, Image Source, Wikipedia and Web Site

{#pypes} ### Pypes Direct Link, Image Source and Web Site

{#praxis-live} ### Praxis LIVE Direct Link, Image Source and Web Site

{#programming-without-coding-technology} ### Programming Without Coding Technology Direct Link, Image Source and Web Site

{#prograph} ### Prograph Direct Link, Image Source, Wikipedia and Web Site??

{#pseint} ### PSeint Direct Link, Image Provided By Email and Web Site

{#pure-data} ### Pure Data Direct Link, Image Source, Wikipedia and Web Site

{#pygmalion} ### Pygmalion Direct Link, Image Source and Web Site Info Only

{#quadrigram} ### Quadrigram Direct Link, Image Source and Web Site

{#quartz-composer} ### Quartz Composer Direct Link, Image Source, Wikipedia, Youtube and Web Site

{#rapidminer} ### RapidMiner Direct Link, Image Source and Web Site

{#reactable} ### Reactable Direct Link, Image Source and Web Site

{#reaktor} ### Reaktor Direct Link, Image Source, Wikipedia and Web Site

{#redwire} ### Redwire Direct Link, Live! Use It Now and Web Site

{#scheme-bricks} ### Scheme Bricks Direct Link, Image Source and Web Site

{#scratch} ### Scratch Direct Link, Image Source 1, Image Source 2, Wikipedia, Youtube and Web Site

{#sextante} ### Sextante Direct Link, Image Source and Web Site

{#simulink} ### Simulink Direct Link, Image Source, Wikipedia and Web Site

{#sikuli} ### Sikuli Direct Link, Image Source, Wikipedia and Web Site

{#snap} ### Snap! Direct Link, Image Source and Web Site

{#sprog} ### Sprog Direct Link, Image Source and Web Site

{#substance-designer} ### Substance Designer Direct Link, Image Source and Web Site

{#synopsis} ### Synopsis Direct Link, Image Source and Web Site

{#synthedit} ### SynthEdit Direct Link, Image Source and Web Site

{#sql-server-integration-services} ### SQL Server Integration Services

Direct Link, Image Source, Wikipedia and Web Site

{#streamtools} ### Streamtools Direct Link, Image Source and Web Site

{#stroycode} ### StroyCode Direct Link, Image Source and Web Site

{#stylus-studio} ### Stylus Studio Direct Link, Image Source and Web Site

{#tersus} ### Tersus Direct Link, Image Source and Web Site

{#textit} ### TextIt Direct Link, Image Source and Web Site

{#thyrd} ### Thyrd Direct Link, Image Source and Web Site

{#touchdesigner} ### TouchDesigner Direct Link, Image Source, Wikipedia and Web Site

{#touch-develop} ### Touch Develop Direct Link, Image Source and Web Site

From Microsoft research.

{#tydlig} ### Tydlig Direct Link, Image Source, Youtube and Web Site

{#thymio} ### Thymio VPL Direct Link, Image Source, Youtube and Web Site

{#tynker} ### Tynker Direct Link, Image Source, Youtube and Web Site

{#udk-kismet} ### UDK Kismet Direct Link, Image Source and Web Site

{#udk} ### UDK Direct Link, Image Source and Web Site

{#unix-tools} ### Unix Tools Direct Link, Image Source and Web Site

{#vplus} ### V+ Direct Link, Image Source and Web Site

{#videolangpi} ### Video Processing Language for the Raspberry Pi Direct Link, Image Source and Web Site

{#vistrails} ### VisTrails Direct Link, Image Source and Web Site

{#visual-jforex} ### Visual JForex Direct Link, Image Source and Web Site

{#viscuit} ### Viscuit Direct Link, Image Source, Youtube and Web Site

{#vrl-studio} ### VRL-Studio Direct Link, Image Source and Web Site

{#vuo} ### VUO Direct Link, Image Source and Web Site

{#vvvv} ### VVVV Direct Link, Image Source 1, Image Source 2, Wikipedia and Web Site

{#windows-workflow-foundation} ### Windows Workflow Foundation Direct Link, Image Source, Wikipedia and Web Site

{#world-machine} ### World machine Direct Link, Image Source and Web Site

{#xpresso} ### Xpresso Direct Link, Image Source and Web Site

{#zaluum} ### Zaluum Direct Link, Image Source and Web Site

Conclusion

That’s it for now. Please submit any languages you would like to see snapshots of.

A Ux Layout Engine for a Gui Based Development Environment

2014-02-19T00:00:00+00:00

Introduction

We had a difficult choice to make. Use OS native controls for layout or roll our own. We chose to roll our own engine for different reasons. We learned a few things from this:

This could not have been done without using Behavior and Test Driven Development (around 6,000 lines of code so far).
One does not simply try to create an html + css layout engine.
It is totally cool having our own ux layout engine based on html + css.

The Results

The results themselves aren’t impressive really. This is just an engine to layout elements using CSS and HTML.

In future posts, we will show what type of UI/UX we can create using the layout engine. After all, the purpose of this is to create a visual programming language. A very robust UI/UX system to display a program visually is really important.

Building An Engine From Scratch

Requirements

We aren’t currently trying to implement all of HTML5 + CSS3 as defined within the specifications and we will probably never go for backwards compatibility. However, we have implemented a decent bit of HTML5 + CSS3.

We drew our ‘requirements’ from w3schools. We iteratively built out functionality starting out with a single div and ending up with support of margin, borders, padding, top, bottom, left, right, auto, etc.

Using these these requirements, we sketched out what a UxControl consists of along with some Pseudo code to get our heads around all of the stuff that needs to happen in a layout engine.

Figure-1.1: Sketch of frames required: frame, bounds, content.

Figure-1.2: Sketch of layout when css position:absolute; is defined.{#id-s1-2}

Test Driven Development

We can’t emphasize enough how much behavior driven development and test driven development helped us with building the layout engine. The engine itself is currently around 850 lines of code with tests running around 6,000 lines of code. It takes around a quarter of a second to run all the tests natively. We have not optimized the layout engine in any way yet but will when needed.

We also did visual inspection of the results of the layout engine with Google Chrome (some day we will automate this).

Some of the output of the automated tests are shown below.

Figure-1.3: Test vs Chrome generated screens.{#id-s1-3}

Comparing Expected and Actual Results

In a nutshell, BDD basically starts with a given state like “If the window is 768 pixels by 1024 pixels and we have the following ux configuration then all of these things should be true.”

For a given ux part we need to verify calculations like:

the top, right, bottom and left position
the top, right, bottom and left margin
the top, right, bottom and left padding
the top, right, bottom and left border-width
the x, y, width and height of the frame-area.
the x, y, width and height of the content-area.
the x, y, width and height of the bounds-area.
the correct scaling of the above calculations.
the correct calculations when css position is static or absolute
margin folding
Box sizing of border and content.
the way auto affects width, height, margin-left and margin-right and how left and right positions affect auto

To validate these hundreds of calculations, we will setup a simple configuration. The configuration can run within a Scope expecting an array of properties to test, the expected value and the actual value. We also provide some context info so we can print a nicely formatted message if the values don’t match up.

PartNamedString ( keyStr = "testPart"
  ForEach (
    part PropScopeGet ( nameStr "propToTest" )
    action WhenNot (
      condition IsNearlyEqFloat (
        left PartIndexStringGet ( nameStr "valExp"
          part PropScopeGet ( nameStr "current" ) )
        right PropGet (
          name PartIndexStringGet ( nameStr "propName"
            part PropScopeGet ( nameStr "current" ) )
          part PropScopeGet ( nameStr "uxControl" ) ) )
      action ConsoleWriteLine (
        text TextFormatter (
          text Vision.Core.String (
            withStr "@testName@: The @propName@ of @uxControlName@ should be @valExp@ but was @actualValue@." )
          parameters ArrayList (
            insert PartNamedString ( keyStr "@testName@"
              part PropScopeGet ( nameStr "testName" ) )
            insert PartNamedString ( keyStr "@propName@"
              part PartIndexStringGet ( nameStr "propName"
                part PropScopeGet ( nameStr "current" ) ) )
            insert PartNamedString ( keyStr "@uxControlName@"
              part PropScopeGet ( nameStr "controlName" ) )
            insert PartNamedString ( keyStr "@valExp@"
              part PartIndexStringGet ( nameStr "valExp"
                part PropScopeGet ( nameStr "current" ) ) )
            insert PartNamedString ( keyStr "@actualValue@"
              part PropGet (
                name PartIndexStringGet ( nameStr "propName"
                  part PropScopeGet ( nameStr "current" ) )
                part PropScopeGet ( nameStr "uxControl" ) ) ) ) ) ) ) )

Let’s see how we use this configuration.

Scope (
  properties HashTable (
    insert PartNamedString ( keyStr "uxControl"
      part PropScopeGet ( nameStr "winNative" ) )
    insert StrKeyStr ( keyStr "controlName" withStr "winNative" )
    insert StrKeyStr ( keyStr "testName" withStr "Test001" )
    insert PartNamedString ( keyStr "propToTest"
      part ArrayList (
        insert HashTable (
          insert StrKeyStr ( keyStr "propName" withStr "marginTop" )
          insert FloatKeyStr ( keyStr "valExp" withFloat 0.0f ) )
        insert HashTable (
          insert StrKeyStr ( keyStr "propName" withStr "marginRight" )
          insert FloatKeyStr ( keyStr "valExp" withFloat 0.0f ) )
        insert HashTable (
          insert StrKeyStr ( keyStr "propName" withStr "marginBottom" )
          insert FloatKeyStr ( keyStr "valExp" withFloat 0.0f ) )
        insert HashTable (
          insert StrKeyStr ( keyStr "propName" withStr "marginLeft" )
          insert FloatKeyStr ( keyStr "valExp" withFloat 0.0f ) ) ) ) )
  part PropScopeGet ( nameStr "testPart" required false ) )

Our above scope has 4 properties named uxControl, controlName, testName and propToTest. Each of these is a different type:

uxControl - A PartNamedString part which is a reference to the uxControl we are testing values on.
controlName - A String part which is the name of the control. Displayed in the test results if the test doesn’t pass.
testName - A String part which is the name of the test running. Displayed in the test results if the test doesn’t pass.
propToTest - A PartNamedString part which contains an array of hash tables. Each hash table contains the name of the property to test and the expected value of that property.

The “testPart” configuration is declared somewhere above our test configuration. When this scope runs, it runs whatever is located in the part property which is the “testPart” configuration:

part PropScopeGet ( nameStr "testPart" required false ) )

The testPart configuration starts with a ForEach part. This part is defined as follows:

ForEach (
  part ( ... ) // The list of items
  action ( ... ) // The action to run against each part.
)

In our testPart configuration, for part we have the following configuration:

part ( PropScopeGet ( nameStr "propToTest" ) )

This is really cool, because if we look for the scope property named “propToTest” we will see it is the ArrayList of HashTables of each property to test and their values. Ok, so we run through each item of this array. Where do we read the current item from in the ForEach loop?

The for each loop places it’s current item in a scope property named “current”. This is why you see the following scattered throughout the configuration:

PropScopeGet ( nameStr "current" )

For the action on each item within the “propToTest” array we check if the value within the actual property is equal to the expected value. The IsNearlyEqFloat part

IsNearlyEqFloat (
  left ( ... ) // Item on the left of the comparison.
  right ( ... ) // Item on the right of the comparison.
)

Since each current part is a HashTable, we want to get one of the elements from the hashtable. We can do this using the PartIndexStringGet Part:

PartIndexStringGet (
  nameStr "..." // The hash code/index
  part ( ... ) // The hash table, array and/or collection
)

In the above configuration, we have the left property of IsNearlyEqFloat configured as follows:

left PartIndexStringGet ( nameStr "valExp"
  part PropScopeGet ( nameStr "current" ) )

Isn’t that cool? We are saying that we want the part named “valExp” located in the “current” property which happens to be one of our hash code definitions like:

insert HashTable (
  insert StrKeyStr ( keyStr "propName" withStr "marginTop" )
  insert FloatKeyStr ( keyStr "valExp" withFloat 0.0f ) )

The right configuration is a little more complex. We are using the PropGet part which gives us access to the property of a part instance (using reflection).

PropGet (
  name ( ... ) // A configuration that returns the name of the property
  part ( ... ) // The instance that contains the property.
)

This is also cool, because the name we want is in our hash table with the hash code “propName”. So, let’s configure the name property as follows:

name PartIndexStringGet ( nameStr "propName"
  part PropScopeGet ( nameStr "current" ) )

This is also kinda cool! We are getting the item at index “propName” within the hash table located in the “current” scope property.

When name is accessed by PropGet, withStr of that part is accessed. As we see above, withStr is set to “marginTop”

So, in this case, the name of the property being used by PropGet is “marginTop”! The actual part is really easy to access and is configured as follows:

part PropScopeGet ( nameStr "uxControl" ) ) )

When the expected value does not equal the actual value, we write something to the console using the ConsoleWriteLine part. It is configured with a very interesting part called a TextFormatter part. This part is easy to configure.

TextFormatter (
  textStr ( ... ) // the text we need to format.
  parameters ( ... ) // Configured with an array of "named" properties used to format text.
)

One of our parameters is configured as follows:

insert PartNamedString ( keyStr "@testName@"
  part PropScopeGet ( nameStr "testName" ) )

This configuration, when called, would return the name of the test, which could be something like “Test001”.

The textStr in this configuration is defined as follows:

"@testName@: The @propName@ of @uxControlName@ should be @valExp@ but was @actualValue@."

Basically, the TextFormatter goes through each item in the array, gets the value of the item, matches the string in the text with the keyStr of the item and replaces it. In this case, the part named “@testName@” returns a vale of “Test001”. All matched text is then replaced with “Test001” as follows:

"Test001: The @propName@ of @uxControlName@ should be @valExp@ but was @actualValue@."

and so on.

Of course, you could use any format you like for keyStr. We could have just as easily done something like:

"<<testName>>: The <<propName>> of <<uxControlName>> should be <<valExp>> but was <<actualValue>>."

and defined our parameters as:

insert PartNamedString ( keyStr "<<testName>>"
  part PropScopeGet ( nameStr "testName" ) )

The really cool part is that we can place any configuration we like within our PartNamedString part property: even another TextFormatter. This is kinda cool because we can end up generating very complex text using such a simple part.

Conclusion

This blog was supposed to be about creating a view that can easily display collections (aggregates). It turns out we don’t need to define such a view within our framework and can, instead, use our layout engine in conjunction with composition to display collections and aggregates.

We now have a layout engine that can do just that: display lists of items. We’ve built up a new set of tests to go against a better css layout engine.

We can now start displaying a configurations visually!

Next Step

The next step is to display our current configuration of Interface Vision visually! This will be a big milestone for us.

The prior step in our goal of creating Interface Vision’s Gui based visual development environment was to dynamically add controls by using factories (instead of ‘hard coding’ our configuration).

Templates and Factories for a Gui Based Language

2014-01-28T00:00:00+00:00

Introduction

In all our prior examples, our configuration had windows pre-defined within the ‘canvas’. Instead of configuring the windows within the canvas, we need a way to add to our configuration dynamically.

To add to our configuration dynamically, we’re going to use factories which ‘build’ things from Templates.

The Results

Templates

In computing we consider a template to be:

a preset format for a document or file, used so that the format does not have to be recreated each time it is used.

Traditionally, software frameworks have to code out the Template functionality to add it to the framework.

In Interface Vision, Templates are an emergent aspect of the framework. How so?

Any composition of parts, even if that composition contains only one part, can be used as a Template.

In prior examples, our complete application had the windows that showed up on our canvas composed within the canvas:

UxViewDrawNat ( keyString "canvas" styling ".canvasDoc"
  properties HashTable (
    insert StringKeyString ( keyString "Css"
      withString "{ width: 4000px; height: 4000px; scale-width:100%, scale-height:100% }"
    )
  )
  uxActions ArrayList ( callBehavior true
    insert GesturePinchRecognizer ()
  )
  uxControls ArrayList ( callBehavior true
    insert UxViewDrawNat ( keyString "window01" styling ".windowFrame"
      properties HashTable (
        insert StringKeyString ( keyString "Css"
          withString "{ top: 50px; left: 50px; width: 200px; height: 200px; scale-width:100%, scale-height:100% }"
        )
      )
      uxActions ArrayList ( callBehavior true
        insert GesturePanRecognizerNat ( touchesMinNum 1 )
      )
      uxControls ArrayList ( callBehavior true
        insert UxRectRoundNat ( keyString "winBtnMove" styling ".winBtnMove"
          uxControls UxImageNat ( keyString "winBtnMoveImage"
            properties HashTable ( insert StringKeyLong ( keyLong  "draggable" ) )
            image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
          )
        )
        insert04 UxRectRoundNat ( keyString "winBtnResize" styling ".winBtnResize"
          uxControls UxImageNat ( keyString "winBtnResizeImage" 
            properties HashTable ( insert StringKeyLong ( keyLong "resizable" ) )
            image ImageNat ( fileName Vision.Core.String ( withString "resize_0.png" ) )
          )
        )
      )
    )
    insert UxViewDrawNat ( keyString "window02" styling ".windowFrame"
      properties HashTable (
        insert StringKeyString ( keyString "Css"
          withString "{ top: 250px; left: 350px; width: 200px; height: 300px; scale-width:100%, scale-height:100% }"
        )
      )
      uxActions ArrayList ( callBehavior true
        insert GesturePanRecognizerNat ( touchesMinNum 1 )
      )
      uxControls ArrayList ( callBehavior true
        insert UxRectRoundNat ( keyString "winBtnMove" styling ".winBtnMove"
          uxControls UxImageNat ( keyString "winBtnMoveImage"
            properties HashTable ( insert StringKeyLong ( keyLong  "draggable" ) )
            image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
          )
        )
        insert04 UxRectRoundNat ( keyString "winBtnResize" styling ".winBtnResize"
          uxControls UxImageNat ( keyString "winBtnResizeImage" 
            properties HashTable ( insert StringKeyLong ( keyLong "resizable" ) )
            image ImageNat ( fileName Vision.Core.String ( withString "resize_0.png" ) )
          )
        )
      )
    )
  )
)

As you can see, this is problematic because the configurations for window01 and window02 are the exact same (other than the top, left, width and height css values). What we want to do is make window configurations reusable.

We make our configuration reusable by placing the configuration within a Factory. We don’t need to explicitly define the configuration as a template.

Factories

A Factory is used to create new instances of parts during run time.

The FactoryInstance Part

The FactoryInstance Part, when given a Template, will create an exact copy of the template. For example:

FactoryInstance (
  part ConsoleWrite (
    text String (
      withString "Hello"
    )
  )
)

This configuration does not cause “Hello” to be written to the console. Instead, the configuration returns a new ConsoleWrite part pre-configured with a String Part having “Hello” as the text to write. So, in this case, ConsoleWrite is being used as a template.

Tap Gesture Creates a Window

For this example, every time a user taps somewhere on the ‘canvas’, we will create a new window. This will replace our existing behavior (which is drawing two windows in known locations).

Tap Gesture Event

The configuration for adding the Tap Gesture to the event system is as follows:

EventManager (
  properties HashTable (
    // other configured events like pan and pinch
    insert EventMonitor ( eventToMonitor GestureTap ( eventStep "finished" tapsRequiredNum 1 touchesRequiredNum 1 )
      action PropScopeGet ( nameStr "behaviorTap" )
    )
  )
)

In this configuration, if a user taps then the ‘behaviorTap’ configuration will run.

Tap Gesture Behavior

When a user taps on the ‘canvas’, we want to create a window at the position the user tapped. This will require us to:

1) Create a new instance of the window
2) Set the new window’s top position to the y value of the tap position within the view
3) Set the new window’s left position to the x value of the tap position within the view
4) Add the newly created window to the view.
5) Notify the view that it’s contents have changed so it can redraw.

Using a Factory to Create a Window

Let’s take the window01 (or window02) configuration and use the configuration as a Template by placing it in a FactoryInstance Part.

insert PropScopeSet ( nameStr "newWindow" 
  source FactoryInstance (
    part UxViewDrawNat ( styling ".windowFrame"
      properties HashTable (
        insert StringKeyString ( keyString "Css"
          withString "{ top: 0px; left: 0px; width: 200px; height: 200px; scale-width:100%, scale-height:100% }"
        )
      )
      uxActions ArrayList ( callBehavior true
        insert GesturePanRecognizerNat ( touchesMinNum 1 )
      )
      uxControls ArrayList ( callBehavior true
        insert UxRectRoundNat ( keyString "winBtnMove" styling ".winBtnMove"
          uxControls UxImageNat ( keyString "winBtnMoveImage"
            properties HashTable ( insert StringKeyLong ( keyLong  "draggable" ) )
            image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
          )
        )
        insert UxRectRoundNat ( keyString "winBtnResize" styling ".winBtnResize"
          uxControls UxImageNat ( keyString "winBtnResizeImage" 
            properties HashTable ( insert StringKeyLong ( keyLong "resizable" ) )
            image ImageNat ( fileName Vision.Core.String ( withString "resize_0.png" ) )
          )
        )
      )
    )
  )
)

The only changes to the initial Window configuration is that we set the top and left to 0px (because we will be overriding these anyway).

We use the result of the Factory and place it in a Scope property named ‘newWindow’. You will see, in the next step, that we place the result of the factory in this scope property so we can update the top/left values before placing the window into the view.

Updating Top and Left

We’ve created a copy of our window configuration and now we need to set the top and left values to the x,y position of the tap gesture.

insert PropSet ( nameStr "withFloat"
  part PropDynamicGet ( nameStr "left"
    part PartHold ( part PropScopeGet ( nameStr "newWindow" ) )
  )
  source PropGet ( nameStr "x" part PropScopeGet ( nameStr "position" ) )
)
insert PropSet ( nameStr "withFloat"
  part PropDynamicGet ( nameStr "top"
    part PartHold ( part PropScopeGet ( nameStr "newWindow" ) )
  )
  source PropGet ( nameStr "y" part PropScopeGet ( nameStr "position" ) )
)

The most interesting part of this configuration is the usage of PartHold:

PartHold ( part PropScopeGet ( nameStr "newWindow" ) )

Part’s in our framework automatically run when used. The scope-property ‘newWindow’ contains our newly created window which is a UxViewDrawNat part. The behavior of this part is to add itself to the parent view. We don’t want to actually run the behavior of the part. We just want to get a reference to it so we can update it’s top and left position.

This is where the PartHold Part comes in. The PartHold part puts a Part’s behavior “on hold” allowing you to access the part without running it.

Add the Newly Created View

We’ve created the window and updated the windows top,left position. Now we need to place the part into the array of controls of the parent view.

insert PropSet ( nameStr "insert"
  part PropGet ( nameStr "uxControls" part PropScopeGet ( nameStr "uxViewFocus" ) )
  source PartHold ( part PropScopeGet ( nameStr "newWindow" ) )
)

Complete Solution

The complete configuration for the tap event is provided:

Scope (
  properties HashTable (
    // other parts within the global scope
    insert PartNamedString ( keyString "behaviorTap"
      part ArrayList ( callBehavior true
        insert When (
          condition IsEqString (
            leftString "canvas" 
            right WithKeyString ( part PropScopeGet ( nameStr "uxViewFocus" ) )
          )
          action Scope (
            properties HashTable (
              insert PartNamedString ( keyString "newWindow" )
            )
            part ArrayList ( callBehavior true
              // 1. Create window
              insert PropScopeSet ( nameStr "newWindow" 
                source FactoryInstance (
                  part UxViewDrawNat ( styling ".windowFrame"
                    properties HashTable (
                      insert StringKeyString ( keyString "Css"
                        withString "{ top: 0px; left: 0px; width: 200px; height: 200px; scale-width:100%, scale-height:100% }"
                      )
  							  	)
                    uxActions ArrayList ( callBehavior true
                      insert GesturePanRecognizerNat ( touchesMinNum 1 )
                    )
                    uxControls ArrayList ( callBehavior true
                      insert UxRectRoundNat ( keyString "winBtnMove" styling ".winBtnMove"
                        uxControls UxImageNat ( keyString "winBtnMoveImage"
                          properties HashTable ( insert StringKeyLong ( keyLong  "draggable" ) )
                          image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
                        )
                      )
                      insert UxRectRoundNat ( keyString "winBtnResize" styling ".winBtnResize"
                        uxControls UxImageNat ( keyString "winBtnResizeImage" 
                          properties HashTable ( insert StringKeyLong ( keyLong "resizable" ) )
                          image ImageNat ( fileName Vision.Core.String ( withString "resize_0.png" ) )
                        )
                      )
                    )
                  )
                )
              )

              // 2. Update Left
              insert PropSet ( nameStr "withFloat"
                part PropDynamicGet ( nameStr "left"
                  part PartHold ( part PropScopeGet ( nameStr "newWindow" ) )
                )
                source PropGet ( nameStr "x" part PropScopeGet ( nameStr "position" ) )
              )

              // 3. Update Top
              insert PropSet ( nameStr "withFloat"
                part PropDynamicGet ( nameStr "top"
                  part PartHold ( part PropScopeGet ( nameStr "newWindow" ) )
                )
                source PropGet ( nameStr "y" part PropScopeGet ( nameStr "position" ) )
              )

              // 4. Add to control
              insert PropSet ( nameStr "insert"
                part PropGet ( nameStr "uxControls" part PropScopeGet ( nameStr "uxViewFocus" ) )
                source PartHold ( part PropScopeGet ( nameStr "newWindow" ) )
              )

              // 5. Get the view to redraw
              insert PropGet ( nameStr "redraw" part PropScopeGet ( nameStr "uxViewFocus" ) required false )
            )
          )
        )
      )
    )
  )
)

Conclusion

Configurations within our framework can be used as Templates allowing us to duplicate any configuration we come up with. In our example, we used a Factory to create new windows that were then added to the ‘canvas’.

If you find our work interesting, please follow us @interfaceVision and/or @erichosick.

Next Step

The next step in our goal of creating Interface Vision’s Gui based visual development environment is to create a view that can easily display collections (aggregates).

The prior step in our goal of creating Interface Vision’s Gui based visual development environment was to allow us to zoom in and out of a view using the pinch gesture.

Zooming And Scaling

2014-01-23T00:00:00+00:00

Introduction

Visually representing an entire program could start looking really cluttered. A general rule of design is to keep the number of elements in a group to around 5 +/- 2 1.

A program may require hundreds of elements. Our plan is to allow our users to zoom-in and zoom-out on different parts of their program: seeing more detail as they zoom in and less as they zoom out.

Imagine Google maps, but instead of seeing more detail about roads as you zoom in, you see more details about your program.

So, we needed to add zoom to our demo.

The Results

IOS vs OSX Drawing

Coordinate Systems

IOS and OSX use different coordinate systems. For OSX, (0,0) defaults in the lower left hand corner. For iOS, Android and Windows, (0,0) is in the upper left hand corner. We can not “flip” iOS but we can “flip” OSX 2.

We are bringing up this difference between the coordinate system because, throughout the vision framework, we need to take into account OSX’s inverted coordinate system (we want to encapsulate this type of minutia within our development framework so our users can focus on making software).

Source-1.1 contains the code necessary to flip the OSX coordinate system.

using System;
using System.Xml.Serialization;

namespace Vision.Ux.Gui {

  [Register("ViewDrawable")] public class ViewDrawable : MonoMac.AppKit.NSView {

    /// Other Code 

    /// <summary>
    /// True causes the coordinate system to flip with regards to native coordinate system.
    /// False keeps the operating system's native coordinate system to be used.
    /// </summary>
    public override bool IsFlipped {
      get { return true; }
    }

  }
} ###### Source-1.1: We need to flip the drawing coordinates for OSX. {#id-s1-1}

Without overriding IsFlipped and returning true, the output is “flipped” as shown in Figure-1.1.

Figure-1.1: For OSX, (0,0) is in the lower left hand corner.

Events

Interface Vision has it’s own event system which we need to send all operating system native events to. The coordinate provided in NSEvent of OSX is based on (0,0) being in the lower left hand corner. Overriding IsFlipped and setting it to true only flips the drawing system. It does not ‘flip’ the native iOS event system.

Source-1.2 contains the code required to support pinch in OSX.

using System;
using System.Xml.Serialization;

namespace Vision.Ux.Gui {

  [Register("ViewDrawable")] public class ViewDrawable : MonoMac.AppKit.NSView {

    /// Other Code 

    public override void MagnifyWithEvent (NSEvent theEvent) {
      // base.MagnifyWithEvent (theEvent); // We will consume the event here.
      NSView parentViewNative = view.parentView.adaptedPart as NSView;
      if ( null != parentViewNative ) {
        // IsFlipped = true (see below) but pos of event is not flipped so we need to flip it
        Pos2fNat posInViewFound = new Pos2fNat {
          native = this.ConvertPointFromView (theEvent.LocationInWindow, null)
          }; 
        Pos2fNat posInWindowFound = new Pos2fNat {
          native = parentViewNative.ConvertPointFromView (theEvent.LocationInWindow, null)
          };
        eventManager.insert = new GesturePinch {
          eventStep = Event.EventStepProcessing,
          posInView = posInViewFound,
          posInWindow = posInWindowFound,
          view = this.view,
          scale = (1 + theEvent.Magnification),
          velocity = theEvent.Magnification };
      }
    }

  }
} ###### Source-1.2: We need to flip the drawing coordinates for OSX. {#id-s1-2}

The value of theEvent.LocationInWindow zooming in the upper left part of the screen returns something like:

( X=37.41797, Y=945.9766 )

We need to use the following code to “flip” the Location sent by the event:

ConvertPointFromView (theEvent.LocationInWindow, null)

which gives us:

( X=37.41797, Y=56.02344 )

The ConvertPointFromView also converts the absolute position of the event location to the logical position within the view.

The Pinch Gesture in iOS contains both a scale and velocity value.

The UIPinchGestureRecognizer.Velocity value in iOS is similar to the NSEvent.Magnification value. However, iOS seems to be about 100 times more sensitive than OXS in it’s velocity value.

An equivalent scale/magnification between iOS and OSX is:

(UIPinchGestureRecognizer.Velocity/100 + 1) ≈ NSEvent.Magnification

Just for your enjoyment, Source-1.3 shows the code necessary to turn an iOS gesture event into an Interface Vision event with the velocity adjusted:

using System;
using System.Xml.Serialization;
using MonoTouch.UIKit;
using MonoTouch.Foundation;
using MonoTouch.ObjCRuntime;
using MonoTouch.CoreGraphics;

namespace Vision.Ux {

  [Serializable()] public class GesturePinchRecognizer : GesturePinch {

    protected void gestureAction (UIPinchGestureRecognizer theEvent ) {
      if ( null == theEvent ) {
        UIView parentViewNative = view.parentView.adaptedPart as UIView;
        if (null != parentViewNative) {
          Pos2fNat posInViewFound = new Pos2fNat {
            native = theEvent.LocationInView(theEvent.View)
          };
          Pos2fNat posInWindowFound = new Pos2fNat {
            native = theEvent.LocationInView (parentViewNative)
          };
          eventManager.insert = new GesturePinch {
            eventStep = eventStepFound,
            posInView = posInViewFound,
            posInWindow = posInWindowFound,
            view = this.view,
            scale = theEvent.Scale,
            velocity = theEvent.Velocity/100 + 1,
            };
        }
      }
    }

    protected bool initialized = false;
    [XmlIgnore] public override IPart withPart {
      get {
        if (!initialized) {
          initialized = true;

          UIView view = parentView.adaptedPart as UIView;
          if (null != view) {
            UIPinchGestureRecognizer gesture = new UIPinchGestureRecognizer (gestureAction);
            view.AddGestureRecognizer (gesture);
          }
        }
        return base.withPart;
      }
    }
  }
} ###### Source-1.3: Converting iOS events into Vision events.{#id-s1-3}

In this case, we adjust the velocity provided by iOS so it is close to the magnification value of OSX.

We are also still using theEvent.LocationInView but not for flipping the coordinate system. In this case, we only need it to convert the absolute position of the event location to the logical position within the view.

Scaling and Zooming Controls

There are a few approaches to scale controls:

NSView.ScaleUnitSquareToSize

This is only available in OS X.

Use:

NSView.ScaleUnitSquareToSize (scaleWidth, scaleHeight).

Although this led to a quick solution initially, there were a few issues. Primarily, and this is also the case for Transformations, everything within the view is scaled. If you want to, for example create resize handles, those controls would also scale.

Resources and information we found:

GCZoomView - “GCZoomView is a simple NSView subclass that adds a set of standard zoom commands, such as Zoom In, Zoom Out, Zoom To Fit, Zoom to any arbitrary scale, etc.”
Discussion - “Yes. Rather than using bounds scaling and leaving your drawables oblivious to zoom, it is commonly helpful to instead build your architecture to support drawing zoomed into a on unscaled bounds coordinate system. Often you’ll want to draw things in unscaled units (resize handles, selection loops, and the like).”
[Discussion 2] (https://groups.google.com/forum/#!msg/cocoa-dev/oprMTlUg4-A/FbJjnpCY4LoJ) - Some example code on zooming and keeping the zoom positioned relative to the mouse/finger coordinates.

Use Transformations

Available for both iOS and OSX.

NSView p_view = new NSView ();
p_view.WantsLayer = true; // FOR OSX
p_view.Layer.Transform = CATransform3D.MakeScale(scaleWidthFound, scaleHeightFound, 1.0f);

This can lead to fuzzy looking images still requiring some custom logic. However, it does work for both iOS and OSX. This also has the issue of scaling controls like resize handles.

Roll Out A Custom Solution

We wanted to simply use one of the zooming solutions provided by either iOS or OSX. These work great if you are trying to zoom a single entity (say an image). But, when you need to support zooming of a hierarchy of controls, this just doesn’t seem to cut it.

So, we’ve rolled out our own solution. This isn’t as crazy as it sounds. We had an existing CSS Layout Engine that had hundreds of tests. We added more tests building out scaling as part of the layout engine.

The Configuration - Scaling

We needed to change our configuration to support zoom through the pinch gesture by scaling our controls. Scaling the controls had an affect on our existing move and resize code. When resized or moved, controls scaled by a factor of two would visually move twice as fast as the mouse pointer/finger.

Even more interesting is that we support scaling within scaling. So, a parent view may be zoomed at 1.5 times while the child view is zoomed at 1.25 times. This means that the controls in the child view need to resize based on the scale factors of all parent controls.

In the resizing windows post, we had refactored our code so the configuration to move and resize controls was re-usable. We need to update this configuration so it also takes into account scaling.

Let’s first update our shared delta configuration to adjust for the scaling.

the left of the window:

PartNamedString ( nameStr "posDeltaX"
  part Divide (
    left Add (
      left PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
      right Subtract (
        left PropGet ( nameStr "x" part PropScopeGet ( nameStr "position") )
        right PropGet ( nameStr "x" part PropScopeGet ( nameStr "positionPrior") )
      )
    )
    right PropScopeGet ( nameStr "curScaleWidth" )
  )
)

the top of the window.

PartNamedString ( nameStr "posDeltaY"
  part Divide (
    left Add (
      left PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
      right Subtract (
        left PropGet ( nameStr "y" part PropScopeGet ( nameStr "position") )
        right PropGet ( nameStr "y" part PropScopeGet ( nameStr "positionPrior") )
      )
    )
    right PropScopeGet ( nameStr "curScaleHeight" )
  )
)

Basically, we divide our delta by the scale. We get the current scaled width and height from the scope properties named curScaleWidth and curScaleHeight.

Now all we need to do is figure out how to use the correct scales based on a move or resize action.

So, how do we define the curScaleWidth and curScaleHeight properties?

Where Interface Vision Really Shines

In our resizing windows, we were able to share the configuration to resize and move windows by nesting Scope.

The behavior to calculate the deltaX and deltaY needs to be altered based on action being taken: move/resize or zoom.

We add to this nested scope the curScaleWidth and curScaleHeight properties.

For moving and resizing scaleHeightCalc and scaleWidthCalc are added:

insert Scope (
  properties HashTable (
    insert StringKeyString ( keyString "scopeHeight" withString = "top" )
    insert StringKeyString ( keyString "scopeWidth" withString = "left" )
			insert PartNamedString ( keyString "curScaleHeight"
      part PropGet ( nameStr "scaleHeightCalc"
        part = new PropGet ( nameStr = "parentUxControl" part PropScopeGet ( nameStr "uxViewFocus" ) )
      )
    )
    insert PartNamedString ( keyString "curScaleHeight"
      part PropGet ( nameStr "scaleWidthCalc"
        part = new PropGet ( nameStr = "parentUxControl" part PropScopeGet ( nameStr "uxViewFocus" ) )
      )
    )
  )
  part PropScopeGet ( nameStr "viewResMov" )
)

For zooming scaleHeightCalc and scaleWidthCalc are different:

insert Scope (
  properties HashTable (
    insert StringKeyString ( keyString "scopeHeight" withString = "top" )
    insert StringKeyString ( keyString "scopeWidth" withString = "left" )
    insert PartNamedString ( keyString "curScaleHeight"
      part PropGet { nameStr = "scaleHeightCalc" part PropScopeGet ( nameStr "uxViewFocus" ) )
    )
			insert PartNamedString ( keyString "curScaleWidth"
      part PropGet { nameStr = "scaleWidthCalc" part PropScopeGet ( nameStr "uxViewFocus" ) )
    )
  )
  part PropScopeGet ( nameStr "viewResMov" )
)

This may sound a bit too forward, but it is the ability for Interface Vision to do what we just did that makes it just so amazing as a technology and framework.

The behavior for moving and scaling are different but there are no conditions to choose which behavior to use specific to scaling. We are able to alter the behavior of posDeltaX and posDeltaY by simply configuring different behavior in the curScaleHeight and curScaleWidth scope properties. From the perspective of deltaX and deltaY, the property is just a property with some value. The actual behavior used to calculate the value returned by the property is ‘unknowingly’ used by the deltaX and deltaY configuration.

Also cool to note, configuration for supporting scaling required no additional conditions: just adjustments to existing configurations. It is advantageous to lower the number of conditions in a program for different reasons (less logic to test, easier to read, etc.). In our case, it is greatly advantageous because it greatly simplifies the visual representation of programs.

The Configuration - Zooming

Finally, we are ready to zoom-in and out using the pinch gesture.

The configuration of the events within the event manager are very similar to the configuration of panning and resizing.

EventManager (
  // ... 
  insert EventMonitor (
    eventToMonito GesturePinch ( eventStep "Begin" )
    action PropScopeGet ( nameStr "behaviorPinch" )
  )
  insert EventMonitor (
    eventToMonito GesturePinch ( eventStep "Processing" )
    action PropScopeGet ( nameStr "behaviorPinch" )
  )
  insert EventMonitor (
    eventToMonito GesturePinch ( eventStep "Finished" )
    action PropScopeGet ( nameStr "behaviorPinch" )
  )
)

Our action, in all three cases, causes the behavior named ‘behaviorPinch’ to run. We don’t need to really worry about the beginning, processing and finished steps of the event.

The configuration (named behaviorPinch) to handle the actual scaling is also similar to the pan behavior within our global scope.

Scope (
  // ... Other configurations
  insert PartNamedString ( keyString "behaviorPinch"
    part ArrayList ( callBehavior true
      insert PropScopeSet ( nameStr "uxViewFocus"
        source PropGet ( nameStr "view"
          part PropScopeGet ( nameStr "eventCurrent" )
        )
      )
      insert PropSet ( nameStr "withFloat"
        part PropDynamicGet ( nameStr "scale-height"
          part PropScopeGet ( nameStr "uxViewFocus" )
        )
        source = new Multiply (
          left PropDynamicGet ( nameStr "scale-height"
            part PropScopeGet ( nameStr "uxViewFocus" )
          ) 
          right PropGet ( nameStr "velocity"
            part PropScopeGet ( nameStr "eventCurrent" )
          )
        )
      )
      insert PropSet ( nameStr "withFloat"
        part PropDynamicGet ( nameStr "scale-width"
          part PropScopeGet ( nameStr "uxViewFocus" )
        )
        source = new Multiply (
          left PropDynamicGet ( nameStr "scale-width"
            part PropScopeGet ( nameStr "uxViewFocus" )
          ) 
          right PropGet ( nameStr "velocity"
            part PropScopeGet ( nameStr "eventCurrent" )
          )
        )
      )
    )
  )
)

In this case, we are adjusting the scale-width and scale-height dynamic-properties of the view that has focus:

PropDynamicGet ( nameStr "scale-width" part PropScopeGet ( nameStr "uxViewFocus" ) )

These values are used within the CSS Layout engine to scale the final values for width, height, left, top of controls (it also scales margin, border and padding values). There is actually no CSS property for scaling in the official CSS3 standards making the layout engine non-compatible with CSS3.

Conclusion

Although we wanted to use scaling solutions provided by iOS and OSX, we just couldn’t make it work with the features we needed for our customers. That isn’t to say we won’t be enabling our users to use iOS and OSX’s Transformation features within their configurations. That will be provided.

The solution worked really well by updating the CssLayoutEngine to support scaling.

If you find our work interesting, please follow us @interfaceVision and/or @erichosick.

Next Step

The next step in our goal of creating Interface Vision’s Gui based visual development environment is to dynamically add controls by using factories (instead of ‘hard coding’ our configuration).

The prior step was to do further refactoring and allow resizing of windows.

Footnotes

{#id-1} 1. You may want to checkout this interesting article on The Magical Number Seven Plus Or Minus Two.

{#id-2} 2. This isn’t exactly true. It is possible to use transformation matrices to “flip” the layer we are drawing on using Apple’s Core Animation framework.

Resizing Windows and Configuration Re-Use

2014-01-16T00:00:00+00:00

Introduction

I was planning on blogging about zooming in and out but it’s been a challenge (which I will talk about in detail when we do get it working).

So, we’ve taken a quick detour and decided to add resizing of windows. This was surprisingly simple in Interface Vision. We also did some refactoring to take advantage of the ability for properties to contain behavior.

The Results

Calculating How Much We Moved Our Mouse/Finger

In our post on draggable controls, we needed to calculate the difference between where the mouse/finger is and where it was. We could then add this delta to the windows left top corner giving us the new window position.

Our initial configuration, using SipCoffee to adjust:

the left of the window:

Add (
  left PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
  right Subtract (
    left PropGet ( nameStr "x" part PropScopeGet ( nameStr "position") )
    right PropGet ( nameStr "x" part PropScopeGet ( nameStr "positionPrior") )
  )
)

the top of the window.

Add (
  left PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
  right Subtract (
    left PropGet ( nameStr "y" part PropScopeGet ( nameStr "position") )
    right PropGet ( nameStr "y" part PropScopeGet ( nameStr "positionPrior") )
  )
)

Resizing a window will also require knowing the distance a Mouse/Finger moved. So, let’s turn the delta behavior into something that is re-usable.

{#position-delta-config} First, let’s add the delta behavior to the program’s scope calling them ‘posDeltaX’ and ‘posDeltaY’ so they can be re-used in other parts of the configuration:

Scope (
  properties HashTable (
    ... // other properites here
    insert PartNamedString ( keyString "posDeltaX"
      part Subtract (
        left PropGet ( nameStr "x" part PropScopeGet ( nameStr "position") )
        right PropGet ( nameStr "x" part PropScopeGet ( nameStr "positionPrior") )
      )
    )
    insert PartNamedString ( keyString "posDeltaY"
      part Subtract (
        left PropGet ( nameStr "y" part PropScopeGet ( nameStr "position") )
        right PropGet ( nameStr "y" part PropScopeGet ( nameStr "positionPrior") )
      )
    )
  )
)

and now let’s re-factor our Add to use the “named” behavior:

for left:

Add (
  left PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
  right PropScopeGet ( nameStr "posDeltaX" )
)

for top:

Add (
  left PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
  right PropScopeGet ( nameStr "posDeltaY" )
)

This is looking a lot better. When Add.right is accessed, PropScopeGet is run. ProprScopeGet causes the behavior in posDeltaX or posDeltaY to run causing the subtraction.

How very interesting. The subtraction behavior has access to posDeltaX and posDeltaY even though it was defined outside of the Scope’s part property. How does that work?

The Scope Part Is Nest-able

One of the cool things about Scope Parts is that they are nest-able: scopes can contain scope.

###### Figure-1.1: Scopes can nest allowing behavior to access properties of any scope ‘above’ them. {#id-f1-1}

This is really powerful because behavior, even configured outside of the scope, run within a scope has access to that scope’s properties and any scope ‘above’ the behavior.

Moving And Resizing Windows

To move a window, we take our deltas (posDeltaX and posDeltaX) and we add them to the top, left corner of the window. To resize a window, we take that same delta and add it to the width and height of the window.

We can re-use the exact same logic as we did for moving a window but replace “top” (of the window) with “height” (of the window) and “left” with “width”.

First, let’s create a configuration, placed within the main scope, that can both resize and move a window:

Scope (
  properties HashTable (
    ... // other properites here
    insert PartNamedString ( keyString "viewResMov"
      part ArrayList ( callBehavior true
        insert PropSet ( nameStr "withFloat"
          part PropDynamicGet ( name PropScopeGet ( nameStr "scopeHeight" )
            part PropScopeGet ( nameStr "uxViewFocus" )
          )
          source Add (
            left PropDynamicGet ( name PropScopeGet ( nameStr "scopeHeight" )
              part PropScopeGet ( nameStr "uxViewFocus" )
            )
            right PropScopeGet ( nameStr "posDeltaY" )
          )
        )
        insert PropSet ( nameStr "withFloat"
          part PropDynamicGet ( name PropScopeGet ( nameStr "scopeWidth" )
            part PropScopeGet ( nameStr "uxViewFocus" )
          )
          source Add (
            left PropDynamicGet ( name PropScopeGet ( nameStr "scopeWidth" )
              part PropScopeGet ( nameStr "uxViewFocus" )
            )
            right PropScopeGet ( nameStr "posDeltaX" )
          )
        )
      )
    )
  )
)

The interesting part is that original configurations for PropDynamicGet had “hard coded” the name of the property to get: in this case “hard coded” to “top”.

PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )

The new configuration gets the name of the property using PropScopeGet:

PropDynamicGet ( name PropScopeGet ( nameStr "scopeHeight" )
  part PropScopeGet ( nameStr "uxViewFocus" )
)

{#shared-resize-move}

All we have to do then is run our configuration within a Scope that has an extended-property named “scopeHeight”. Our original configuration for moving windows was here. Let’s see what our changes have done:

insert PartNamedString ( keyString "behaviorPanProcEnd"
  part ArrayList ( callBehavior true
    insert PropScopeSet ( nameStr "positionPrior"
      source PropGet ( nameStr "posInWindow" part PropScopeGet ( nameStr "eventCurrent" ) )
    )
    insert When (
      condition IsNotNil ( part PropDynamicGet ( nameStr "draggable" required false part PropScopeGet ( nameStr "controlFocus" )) )
      action ArrayList ( callBehavior true
        insert Scope (
          properties HashTable (
            insert StringKeyString ( keyString "scopeHeight" withString = "top" )
            insert StringKeyString ( keyString "scopeWidth" withString = "left" )
          )
          part PropScopeGet ( nameStr "viewResMov" )
        )
      )
    )
    insert When (
      condition IsNotNil ( part PropDynamicGet ( nameStr "draggable" required false part PropScopeGet ( nameStr "controlFocus" )) )
      action ArrayList ( callBehavior true
        insert Scope (
          properties HashTable (
            insert StringKeyString ( keyString "scopeHeight" withString = "height" )
            insert StringKeyString ( keyString "scopeWidth" withString = "width" )
          )
          part PropScopeGet ( nameStr "viewResMov" )
        )
      )
   )
)

We can now re-use the “viewResMov” behavior for both moving and resizing windows.

Conclusion

We’ve been able to further refactor or configuration to improve on re-use by taking advantage of the nesting feature of Scope. We’ll probably write a post on how nesting Scope is so much more awesome than relying on the function calling chain: passing information through parameters all the way down.

If you find our work interesting, please follow us @interfaceVision and/or @erichosick.

Next Step

The next step in our goal of creating Interface Vision’s Gui based visual development environment is to allow us to zoom in and out of a view using the pinch gesture.

The prior step allows us to ‘re-use’ parts of a configuration.

Configuration re-use

2014-01-14T00:00:00+00:00

Introduction

A goal of programming is to create code that is re-usable.

That is, we are able to generalize a behavior required in a software system, write code to implement that behavior, and then re-use that code throughout the software system.

Interface Vision is able to configure behavior that can be re-used throughout the program.

The Approach

In our post on draggable controls, we had some configurations that were redundant. That is, the exact same configuration was found in more than one place within the configuration.

We want to place this duplicated configuration in some area within our program and make it accessible to other areas of our program. This should allow us to re-use that configuration as needed.

It turns out we don’t need to do anything to support re-use within Interface Vision. Re-use is an emergent feature (emergent behavior) of our technology.

Let’s see how it works.

Behavior Re-use in Interface Vision

If you recall, we were able to declare variables in Interface Vision as follows:

Scope (
  properties HashTable (
    insert PartNamedString ( keyString "eventCurrent" )
    // other variables within the scope
  )
)

In this case, we have declared a scope variable named eventCurrent.

What we didn’t mention is that a variable, and really any property for that matter, can contain more than just information. In fact, a variable (or property) can also contain behavior.

{#configuring-properties} ## Configuring Properties So They Can Contain Behavior

Let’s take the behavior we want to make re-usable and place that behavior in Scope variables:

Scope (
  // .. other scope variables 
  insert PartNamedString ( keyString "behaviorPanBegin"
    part ArrayList ( callBehavior true
      insert PropScopeSet ( nameStr "eventBegin" source PropScopeGet ( nameStr "eventCurrent" ) )
      insert PropScopeSet ( nameStr "eventPrior" source PropScopeGet ( nameStr "eventCurrent" ) )
      insert PropScopeSet ( nameStr "viewFocus"
        source PropGet ( nameStr "view"
          part PropScopeGet ( nameStr "eventCurrent" )
        )
      )
      insert PropScopeSet ( nameStr "positionPrior"
        source PropGet ( nameStr "posInWindow"
          part PropScopeGet ( nameStr "eventCurrent" )
        )
      )
      insert PropScopeSet ( nameStr "controlFocus" sourceRequired false
        source UxControlAtPoint ( returnView false
          position PropGet ( nameStr "posInView"
            part PropScopeGet ( nameStr "eventCurrent")
          )
          shapes PropScopeGet ( nameStr "viewFocus" )
        )
      )
    )
  )
  insert PartNamedString ( keyString "behaviorPanProcEnd"
    part ArrayList ( callBehavior true
      insert PropScopeSet ( nameStr "positionPrior"
        source PropGet ( nameStr "posInWindow" part PropScopeGet ( nameStr "eventCurrent" ) )
      )
      insert When (
        condition IsNotNil ( part PropDynamicGet ( nameStr "draggable" required false part PropScopeGet ( nameStr "controlFocus" )) )
        action ArrayList ( callBehavior true
          insert PropSet ( nameStr "withFloat"
            part PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
            source Add (
              left PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
              right Subtract (
                left PropGet ( nameStr "y" part PropScopeGet ( nameStr "position") )
                right PropGet ( nameStr "y" part PropScopeGet ( nameStr "positionPrior") )
              )
            )
          )
          insert PropSet ( nameStr "withFloat"
            part PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
            source Add (
              left PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
              right Subtract (
                left PropGet ( nameStr "x" part PropScopeGet ( nameStr "position") )
                right PropGet ( nameStr "x" part PropScopeGet ( nameStr "positionPrior") )
              )
            )
          )
          insert PropScopeSet ( nameStr "eventPrior" source PropScopeGet ( nameStr "eventCurrent" ) ) 
          insert PropScopeSet ( nameStr "positionPrior" source PropScopeGet ( nameStr "position" ) ) 
        )
      )
    )
  )
  // .. other scope variables       
)

We’ve defined two scope variables named ‘behaviorPanBegin’ and ‘behaviorPanProcEnd’. The “Part” contained within the part property of PartNamedString are the same configurations we had defined in our prior post.

Using Properties With Behavior

Original, the above behavior was configured within our EventManager. Let’s see how we access that behavior now that it is defined outside of the EventManager:

EventManager ( keyString "PropEventManager"
  properties HashTable {
    insert EventMonitor (
      eventToMonitor GesturePanEventNat ( eventStep "Begin" touchesMinVal 1 )
      action PropScopeGet ( nameStr "behaviorPanBegin" )
    )
    insert EventMonitor (
      eventToMonitor GesturePanEventNat ( eventStep "Processing" touchesMinVal 1 )
      action PropScopeGet ( nameStr "behaviorPanProcEnd" )
    )
    insert EventMonitor (
      eventToMonitor GesturePanEventNat ( eventStep "End" touchesMinVal 1 )
      action PropScopeGet ( nameStr "behaviorPanProcEnd" )
    )
)

That’s it. All we have to do, for the action of the EventMonitor Part we are defining, is access the scope variable by calling PropScopeGet. Using PropScopeGet causes the configuration located within the part property to run.

Conclusion

Configuring behavior that is re-usable is really easy in Interface Vision. If you find our work interesting, please follow us @interfaceVision and/or @erichosick.

Next Step

The next step is to do further refactoring and allow a window to be resized.

The prior step was to create a configuration to allow us to drag controls around on the screen..

Configurable Dragging of Gui Controls

2014-01-13T00:00:00+00:00

Introduction

This took a little longer to get working than we thought it would. There really are quite a few differences between iOS and OSX. Getting them to work using the same configuration was a bit of a challenge.

In this post, we are going to show how we used our [configurable event system] (/design/example-events-basic) to configure the dragging of controls.

The Results

The Approach

We want a user to be able to drag controls around on a screen using a button attached to the window.

We will use the Pan Gesture with a single finger touch and apply the following logic:

At the beginning of the Pan gesture, we set a prior event to the current event (automatically set by the event system). If there is a control at the position of the current event, we set a reference at this step.
During the processing of the Pan gesture, we check if the current control is marked “draggable”. If the control is draggable, we update the view’s frame position based on the distance a mouse/finger moved.
We then update the prior position to the current position (for the next pan gesture).
During the ending of the Pan gesture, we also update the view’s frame position for that last little movement.

{#complete-application} ### The Complete Configuration

Configuration-1.1 contains the complete configuration in [SipCoffee] (/design/design-composition-based-language) for an application that runs on iOS and OSX devices that allows controls to be dragged around in a scrollable canvas. The complete configuration is broken down and explained in detail below.

Please note that this is a complete application, excluding the CSS, that is able to define the entire behavior of a cross platform application with a GUI user experience configured in around 110 lines 1.

Scope (
  properties HashTable ( // Contains the 'variables' for this Scope.
    insert PartNamedString ( keyString "eventCurrent" ) // current event
    insert PartNamedString ( keyString "eventPrior" ) // prior event
    insert PartNamedString ( keyString "viewFocus" ) // view with focus
    insert PartNamedString ( keyString "controlFocus" ) // control with focus
    insert PartNamedString ( keyString "position" ) // current event position
    insert PartNamedString ( keyString "positionPrior" ) prior event position
    insert CssManager ( ... )
    insert EventManager ( keyString "PropEventManager"
      properties HashTable (
        insert EventMonitor (
          eventToMonitor GesturePan ( eventStep "Begin" touchesMin 1 )
          action ArrayList ( callBehavior true
            insert PropScopeSet ( nameStr "eventBegin" source PropScopeGet ( nameStr "eventCurrent" ) )
            insert PropScopeSet ( nameStr "eventPrior" source PropScopeGet ( nameStr "eventCurrent" ) )
            insert PropScopeSet ( nameStr "viewFocus"
              source PropGet ( nameStr "view"
                part PropScopeGet ( nameStr "eventCurrent" )
              )
            )
            insert PropScopeSet ( nameStr "positionPrior"
              source PropGet ( nameStr "posInWindow"
                part PropScopeGet ( nameStr "eventCurrent" )
              )
            )
            insert PropScopeSet ( nameStr "controlFocus" sourceRequired false
              source UxControlAtPoint ( returnView false
                position PropGet ( nameStr "posInView"
                  part PropScopeGet ( nameStr "eventCurrent")
                )
                shapes PropScopeGet ( nameStr "viewFocus" )
              )
            )
          )
        )
        insert EventMonitor (
          eventToMonitor GesturePan ( eventStep "Processing" touchesMin 1 )
          action ArrayList ( callBehavior true
            insert PropScopeSet ( nameStr "positionPrior"
              source PropGet ( nameStr "posInWindow" part PropScopeGet ( nameStr "eventCurrent" ) )
            )
            insert When (
              condition IsNotNil ( part PropDynamicGet ( nameStr "draggable" required false part PropScopeGet ( nameStr "controlFocus" )) )
              action ArrayList ( callBehavior true
                insert PropSet ( nameStr "withFloat"
                  part PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
                  source Add (
                    left PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
                    right Subtract (
                      left PropGet ( nameStr "y" part PropScopeGet ( nameStr "position") )
                      right PropGet ( nameStr "y" part PropScopeGet ( nameStr "positionPrior") )
                    )
                  )
                )
                insert PropSet ( nameStr "withFloat"
                  part PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
                  source Add (
                    left PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
                    right Subtract (
                      left PropGet ( nameStr "x" part PropScopeGet ( nameStr "position") )
                      right PropGet ( nameStr "x" part PropScopeGet ( nameStr "positionPrior") )
                    )
                  )
                )
                insert PropScopeSet ( nameStr "eventPrior" source PropScopeGet ( nameStr "eventCurrent" ) ) 
                insert PropScopeSet ( nameStr "positionPrior" source PropScopeGet ( nameStr "position" ) ) 
              )
            )
          )
        )
        insert EventMonitor (
          eventToMonitor GesturePan ( eventStep "End" touchesMin 1 )
          action ArrayList ( callBehavior true
            insert PropScopeSet ( nameStr "positionPrior"
              source PropGet ( nameStr "posInWindow" part PropScopeGet ( nameStr "eventCurrent" ) )
            )
            insert When (
              condition IsNotNil ( part PropDynamicGet ( nameStr "draggable" required false part PropScopeGet ( nameStr "controlFocus" )) )
              action ArrayList ( callBehavior true
                insert PropSet ( nameStr "withFloat"
                  part PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
                  source Add (
                    left PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
                    right Subtract (
                      left PropGet ( nameStr "y" part PropScopeGet ( nameStr "position") )
                      right PropGet ( nameStr "y" part PropScopeGet ( nameStr "positionPrior") )
                    )
                  )
                )
                insert PropSet ( nameStr "withFloat"
                  part PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
                  source Add (
                    left PropDynamicGet ( nameStr "left" part PropScopeGet ( nameStr "viewFocus") )
                    right Subtract (
                      left PropGet ( nameStr "x" part PropScopeGet ( nameStr "position") )
                      right PropGet ( nameStr "x" part PropScopeGet ( nameStr "positionPrior") )
                    )
                  )
                )
                insert PropScopeSet ( nameStr "eventPrior" source PropScopeGet ( nameStr "eventCurrent" ) ) 
                insert PropScopeSet ( nameStr "positionPrior" source PropScopeGet ( nameStr "position" ) ) 
              )
            )
          )              
        )
      )
    )
  )
  part AppNat (
    action UxWindowNat (
      titleStr "Interface Vision"
      frame RectanglefFixed ( x 10 y 10 width 768 height 1024 )
      uxControls UxViewPrimaryNat ( styling ".windowNative"
        statusBarHiddenBool true
        uxControls UxViewScrollable ( styling ".canvas"
          scrollVerticalAllowedBool true
          scrollHorizontalAllowedBool true
          uxControls UxViewDrawNat ( styling ".canvasDoc"
            properties HashTable (
              insert StringKeyString ( keyString "Css"
                withString "{ width: 4000px; height: 4000px }"
              )
            )
            uxControls ArrayList ( callBehavior true
              insert UxViewDrawNat ( styling ".windowFrame"
                properties HashTable (
                  insert StringKeyString ( keyString "Css"
                    withString "{ top: 50px; left: 50px; width: 200px; height: 200px }"
                  )
                )
                uxActions GesturePanRecognizerNat ( touchesMinVal 1 )
                uxControls UxRectRoundNat ( styling ".windowButton"
                    uxControls UxImageNat (
                      properties HashTable ( insert StringKeyString ( keyString "draggable" ) )
                      image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
                    )
                )
              )
              insert UxViewDrawNat ( styling ".windowFrame"
                properties HashTable (
                  insert StringKeyString ( keyString "Css"
                    withString "{ top: 50px; left: 270px; width: 200px; height: 200px }"
                  )
                )
                uxActions GesturePanRecognizerNat ( touchesMinVal 1 )
                uxControls UxRectRoundNat ( styling ".windowButton"
                    uxControls UxImageNat (
                      properties HashTable ( insert StringKeyString ( keyString "draggable" ) )
                      image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
                    )
                )
              )
            )
          )
        )
      )
    )
  )
)

Configuration-1.1: A configured iOS and OSX application allowing controls to be dragged.{#id-s1-1}

There is some redundant configuration code that should be reused: specifically the Processing and End panning events. It is easy to re-use configurations and we’ll write a post on this.

{#declaring-variables} ### Declaring and Using Variables

Traditional Approach

We need to keep some easily accessible information about the status of our dragging of windows. Traditionally, we would declare variables within some scope: a function, a method or passed as parameters. So, we may have something like:

public class MoveWindow {
  Event eventCurrent = null;
  Event eventPrior = null;
  UxControl controlFocus = null;
  Pos2f position = null;
  Pos2f positionPrior = null;
  
  public void MoveWindow {
    // add code here.
  }
}

or, maybe we just pass all the information into a function using parameters:

public void MoveWindow ( Event eventCurrent, Event eventPrior, UxControl controlFocus, Pos2f position, Pos2f positionPrior ) {
  // add code here.
}

Traditionally, we access variables by reading from them and setting them as follows:

MoveWindow mw = new MoveWindow;
mw.eventCurrent = // some logic
mw.eventPrior = null;
mw.position = eventCurrent.position;

How We Declare and Use Variables

Interface Vision is designed to be fully compose-able using Parts. As such, we define scope (see [How We do Scope] (/design/example-window-basic/#id-scope) ) and variables using Parts.

Scope Properties

Within our Scope we define variables using different Parts. In this case, we are using the PartNamedString part allowing us to define a part using a string as the variable name. There are also parts like LongKeyLong which allow us to define a long variable with a number as a variable name.

Scope (
  properties HashTable ( // Contains the 'variables' for this Scope.
    insert PartNamedString ( keyString "eventCurrent" ) // current event
    insert PartNamedString ( keyString "eventPrior" ) // prior event
    insert PartNamedString ( keyString "viewFocus" ) // view with focus
    insert PartNamedString ( keyString "controlFocus" ) // control with focus
    insert PartNamedString ( keyString "position" ) // current event position
    insert PartNamedString ( keyString "positionPrior" ) prior event position
  )
  action TheAction (
    // behavior within the scope
  )
)

The purpose of the variables is to allow us to drag a control around using Pan gestures.

eventCurrent - The current event. This is set automatically when setting the property EventManager.insert to a new event.
eventPrior - This contains the prior event.
viewFocus - This is the view that had focus when the pan event began.
controlFocus - This is the control that had focus, if any, when the pan event began.
position - This is the (x,y) position on the view of the current event. This is a temporary variable used to keep the logic easier. This information is also contained within eventCurrent.
positionPrior - This is the (x,y) position on the view of the prior event. This is a temporary variable used to keep the logic easier. This information is also contained within eventPrior.

Accessing variables within Interface Vision is also done using Parts 2. For reading to and writing from Scope “variables” we have the following:

PropScopeGet ( nameStr "eventCurrent" required false )

This reads a property defined within the current scope named “eventPrior”. required being set to false will stop any warning from being generated if the variable does not exist.

PropScopeSet ( nameStr "eventPrior" part PropScopeGet ( nameStr "eventCurrent" ) )

This sets a property defined within the current scope named “eventPrior” to the item located in part. In this case, the item located in part is PropScopeGet which, when used, will return a reference to the current event.

This is equivalent to the equal operator: destination = source.

Dynamic Properties

A dynamic property is a property that can be defined on any Part instance: even at run time.

UxImageNat (
  properties HashTable (
    insert StringKeyString ( keyString "draggable" )
  )
)

In this case, we have added to a UxImageNat Part a dynamic property named “draggable”.

To access this dynamic property, we use the PropDynamicGet part:

PropDynamicGet (
  nameStr "draggable"  // the name of the dynamic property
  part SomePart ( ) // the part that contains the dynamic property we want to get
)

To set a dynamic property, we use the PropDynamicSet part (not used in our configuration).

Instance Properties

To access a property of an instance of a class, we use PropGet.

PropGet ( nameStr "view"
  part PropScopeGet ( nameStr "eventCurrent" )
)

In this case, we are getting the property named view of the Part located within the current event. The eventCurrent is actually a Part of type EventGesture which contains a view property.

Traditionally, we would access a property as follows:

EventGesture someEvent;
object eventView = someEvent.view; // view is a property of someEvent.

To write to a property of an instance of a class, we use PropSet.

PropSet ( nameStr "withFloat"
  part PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
  source PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
)

nameStr is the name of the property, part contains the instance that we want to write too. Source contains the value we want to place into the property, in this case, named ‘withFloat’.

Logic and Flow

A goal of Interface Vision is to make our framework really easy to use. If you look at Configuration-1.1 you’ll note that there really is very little logic and flow defined within the configuration. All the minutia for creating native windows, native view, native images, and allocating memory are “hidden” within our framework. This allows the programmer to focus on the domain specific behavior of the program itself. Programmers don’t have to twiddle with the idiosyncrasies languages and frameworks introduce into the development process.

That being said, there are cases where logic and flow needs to be supported at the domain level. For these cases, Interface Vision has Parts to deal with logic and flow.

Controls marked as “draggable” can be dragged. To check if a control is draggable requires some logic and flow within our configuration.

In Configuration-1.1 we use When to alter flow and IsNotNil as our Logic.

When (
  condition IsNotNil ( part PropDynamicGet ( nameStr "draggable" part PropScopeGet ( nameStr "controlFocus" ) required false ) )
  action (
    // do the dragging thing
  )        
)

The above could be read as “When condition is not nil property ‘draggable’ part scope ‘controlFocus’”.

The action is run only if the condition is true: in this case, only if there is a control with focus and it has a dynamic property “draggable”.

Configuring Domain Specific Behavior

In Interface Vision, the position of a control is determined using two dynamic properties named ‘top’ and ‘left’ (the same as CSS). To move a control, we need to update these two values.

To do this, we will need to get the current position of our mouse/touch within the current event and subtract it from the prior position of the mouse/touch of the prior event. This gives us the distance the mouse/touch moved between the events. We then add that value to the existing top/left properties of the control.

Let’s look at the configuration to adjust the top position of the view that has focus:

PropSet ( nameStr "withFloat"
  part PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
  source Add (
    left PropDynamicGet ( nameStr "top" part PropScopeGet ( nameStr "viewFocus") )
    right Subtract (
      left PropGet ( nameStr "y" part PropScopeGet ( nameStr "position") )
      right PropGet ( nameStr "y" part PropScopeGet ( nameStr "positionPrior") )
    )
  )
)

The Add Part has a left and right property which are the left and right side of the addition operator similar to:

left + right

The value of left is the dynamic property named ‘top’ of the view that has focus. The value of right is the result of the subtraction of the y property of the current position and the y property of the prior position.

The result of this addition is placed into the top property of the view that has focus.

Let’s look at how this might be implemented traditionally by coding out a function:

function void MoveWindow ( Control viewFocus, Pos position, Pos positionPrior ) {
    viewFocus("top").withFloat = viewFocus("top").withFloat + ( position.y - positionPrior.y );
}

Running Behavior in Series

The last item of interest is causing behavior to happen in series. To do this, we can use an ArrayList setting callBehavior to true.

ArrayList ( callBehavior true
  insert PropScopeSet ( nameStr "eventBegin" source PropScopeGet ( nameStr "eventCurrent" ) )
  insert PropScopeSet ( nameStr "eventPrior" source PropScopeGet ( nameStr "eventCurrent" ) )
  insert PropScopeSet ( nameStr "viewFocus" ... )
)

Conclusion

Configuring conditions, logic and behavior within Interface Vision is both easy and consistent. The nasty bits that we usually need to worry about within frameworks are taken care of by the Vision Framework (you compose with Vision, you don’t code against it).

Configurations are consistent throughout. The syntax to describe the creation of parts, declare variables, define behavior, define logic and define flow is the exact same!

If you find our work interesting, please follow us @interfaceVision and/or @erichosick.

Next Step

The next step allows us to ‘re-use’ parts of a configuration.

The prior step was to create a configurable event system.

Footnotes

{#id-1} 1. The goal of Interface Vision is to be a Gui based visual development environment so, in the bigger picture, the number of lines of configuration required is not that important. It is probably more important to keep the number of parts manageable.

{#id-2} 2. We intend on hiding the process of reading from and writing to properties. As such, within the visual development environment, the user will not be aware of parts like PropGet, PropSet, PropScopeGet, PropScopeSet, etc.

Configurable Event System

2014-01-04T00:00:00+00:00

Introduction

Most, if not all, frameworks with some kind of User Experience (UX) have some sort of event system to handle events generated from mice, keyboards and other devices. Our goal is to create an event system that can be fully configured.

Traditional Approaches

Source-1.1 shows one way developers handle events in Ux frameworks. In this case, we’ve inherited from a class NSWindow provided by MonoMac and override the method MouseDown.

public partial class MainWindow : NSWindow {
  
  // other code
  
  public override void MouseDown (NSEvent theEvent) {
    base.MouseDown (theEvent);
    // custom code to handle MouseDown event
  }
  
  // other code
  		
}

Source-1.1: Traditional approach to handling events using C# MonoMac.

Source-1.2 shows another way developers handle events in Ux frameworks. In this case, we use delegates and “compose” the handling of the event within a UIButton, provided by MonoTouch, and override the method MouseDown.

// other code

UIButton button = UIButton.FromType(UIButtonType.RoundedRect);
button.TouchDown += delegate(object sender, EventArgs e) {
  // custom code to handle Button pressed event
};

// other code

Source-1.2: Traditional approach to handling events using C# MonoTouch.

Source-1.3 shows another way developers handle events in Ux frameworks. In this case, we register a recognizer with a Ux Control, in this case a UIWindow provided by MonoTouch, that supports Panning with one or two fingers.

public partial class MainWindow : NSWindow {
  
  // other code

  protected void gestureAction (UIPanGestureRecognizer theAction ) {
    // custom code to handle gesture
  }

  MainWindow() {
    UIPanGestureRecognizer gesture = new UIPanGestureRecognizer (gestureAction);
    gesture.MinimumNumberOfTouches = 1;
    gesture.MaximumNumberOfTouches = 2;
    this.AddGestureRecognizer (gesture);
  }
  
  // other code
  		
}

Source-1.3: Traditional approach to handling events using C# MonoTouch.

The recognizer is “attached” to a protected method gestureAction which contains the custom code to handle the gesture.

Event Handling in Interface Vision

We want to provide a consistent way to compose the definition of and handling of events. Not only does it need to be consistent, but it needs to be operating system agnostic.

We will need to “wrap” the traditional approach to handling events and forward those events to our event handling system described in detail below.

Our Design

Events

We want to be able to handle events at different levels:

Cloud “level” (Across multiple devices - planned)
Global to OS (Maybe)
Active Application
Active Window
Active View

An event can occur in one of the following steps:

EventStepEmpty - The “empty” step. No step has been defined for the event.
EventStepBegin - The start/beginning of an event (Pan, Press, keyPressDown, etc.)
EventStepProcessing - The event is still running (Drag/Drop, IsPanning, etc.)
EventStepFinished - The event finished (keyPressUp, finger released from screen, etc.)
EventStepCancelled - The event was cancelled during the processing phase.

An even has a source. Sources can be native to the operating system such as (few examples):

EventSourceWinNatResize - Native window was resized.
EventSourceWinNatMove - Native window was moved.
EventSourceWinNatScreenFullExit - Native window exited full screen
EventSourceWinNatScreenFullEnter - Native window entered full screen

Sources can be gestures such as (few examples):

EventSourceGesturePan - The source of the even was a pan gesture.
EventSourceGesturePress - The source of the even was a press gesture.
EventSourceGestureRotation - The source of the even was a rotation gesture.
EventSourceGestureSwipe - The source of the even was a swipe gesture.
EventSourceGestureTap - The source of the even was a tap gesture.

Sources can be from native physical devices such as (few examples):

EventSourceKeyboard - The source was a keyboard
EventSourceMouse - The source was a mouse

A specific Event my require more information. For example, a GesturePan event may require the number of touches required for the event to “fire”. A GesturePress event may require the number of touches and the touch duration for the event to “fire”.

Unique Events with the Event Part

We will need a way to register events, monitor for events and “fire” those events (run the behavior configured for a given event). Let’s first see how we define a unique event to monitor.

Currently, we identify an event by creating a unique hash code for the event.

public class Event : Part, IEvent {

  public override object keyHashCode {
    get { return this.keyString; }
  }

  public override string keyString {
    get { return eventSource + eventStep; }
  }

  public string eventSource = "SourceEmpty";
  public string eventStep = "StepEmpty";

  }
}

In Interface Vision, the Part class has a keyHashCode and keyString properties. We override these properties and return “eventSource + eventStep” as the hashcode. An event instance can now be placed in a HashTable part for quick lookup.

A GesturePan event has more information provided, the touchesMin, which is used to generate a unique hash code.

public class GesturePan : Event {

  public override string keyString {
    get { return base.keyString + "Touch"+touchesMin.ToString(); }
  }

  public override string eventSource {
    get { return "GesturePan"; }
  }
	
  public int touchesMin = 0;

}

The unique hash code for a GesturePan with 2 for touchesMin with two fingers would be “GesturePanStepEmptyTouch2” 1.

Attaching an Action to an Event with EventMonitor

When an event “fires” we need to attach a behavior to that event which is what the EventMonitor part does.

public class EventMonitor : PartParent, IEventMonitor {

  public override object keyHashCode {
    get { return keyString; }
  }

  public override string keyString {
    get { return eventToMonitor.keyString; }
  }
	
  public IPart eventToMonitor { get; set; }
  public IPart action { get; set; }

  public override IPart withPart {
    get { return action.withPart; }
  }

}

The hash code for the EventMonitor part will always be the same as the event it monitors (see the keyString property). The property withPart of our EventMonitor simply calls withPart of the Part located within the action property (see Our Technology to understand the trickery behind the withPart property).

The Configuration using the EventManager part

Let’s define a few events to monitor. Let’s build on top of the configuration we had in our [prior step] (/design/example-window-basic) - a program to display a native window.

We add to our Scope an EventManager as follows:

Scope (
  properties HashTable ( // Contains the 'variables' for this Scope.
    insert CssManager ( ... )
    insert EventManager ( keyString "PropEventManager"
      properties HashTable (
        insert EventMonitor (
          eventToMonitor GesturePan ( eventStep "Begin" touchesMin 1 )
          action ConsoleWriteLine ( text "GesturePan - EventStep Begin - One Finger")
        )
        insert EventMonitor (
          eventToMonitor GesturePan ( eventStep "Processing" touchesMin 1 )
          action ConsoleWriteLine ( text "GesturePan - EventStep Processing - One Finger")
        )
        insert EventMonitor (
          eventToMonitor GesturePan ( eventStep "End" touchesMin 1 )
          action ConsoleWriteLine ( text "GesturePan - EventStep End - One Finger")
        )
      )
    )
  )
  part AppNat (
    ...
  )
)

We’ve now configured our application to watch for panning using a single finger for the Begin, Processing and End event steps. In this case, we will write to the console text based on which event is fired.

Note that we can have more than one action taken by plugging in an ArrayList part for the action.

Hooking Up The “Old” With The New

Hooking up the event systems with the IOS and OSX frameworks is an interesting challenge.

Standardizing on Gestures and Events

A gesture on a touch device or screen is a bit different from a Gestures created using something like a [TrackPad] (http://www.apple.com/magictrackpad/) or Mouse.

Let’s consider Panning. On a gesture device, the first time the user touches the screen and moves their fingers, we know that the beginning of a Gesture has occurred and that we are processing the Gesture. When the user releases their finger, we are at the end of the pan gesture.

However, with a TrackPad or mouse, we should only consider the Gesture to be panning when the user has pressed down on the Trackpad or one of the mouse buttons. We can track the position of a mouse as the user moves it but we can’t track where a user is going to put their finger on the screen of a touch screen device until they have done so.

A similar issue comes up with a trackpad where the user can move the cursor on the screen without actually pressing down on the trackpad. This lets the user position the cursor on the screen without “pressing”: similar to the mouse.

So, we will need to standardize how we represent gestures between different devices like touchable devices, mice and trackpads 2.

Hooking Up IOS

Let’s hook up the Interface Vision Event System with the iOS event system. Source-1.3 shows how iOS’s event system works. Let’s generalize it by creating a part to support Panning.

public class GesturePanRecognizer : GesturePan {

  protected void gestureAction (UIPanGestureRecognizer theAction ) {
    eventManager.insert = new GesturePanEvent { eventStep = eventStep, theAction = theAction, touchesMinVal = this.touchesMinVal };
  }

  [XmlIgnore] public override IPart withPart {
    get {
      UIPanGestureRecognizer gesture = new UIPanGestureRecognizer (gestureAction);
      gesture.MinimumNumberOfTouches = (uint)this.touchesMinVal;
      IPart window = parentLogical;
      window.AddGestureRecognizer (gesture);
      return base.withPart;
    }
  }
}

The GesturePanRecognizer inherits from GesturePan which is an Event (if you recall). In this way, we can create a UIPanGestureRecognizer based on properties unique to the GesturePan such as touchesMinVal.

The property withPart of our GesturePanRecognizer creates an instance of the UIPanGestureRecognizer and adds it to the window (see Our Technology to understand the trickery behind the withPart property).

What is interesting to note is that the window is found by calling parentLogical which means we need to configure our Recognizer “under” our MainWindow. Let’s see what this looks like in SipCoffee.

Scope (
  ...
  part AppNat (
    action UxWindowNat (
      uxActions ArrayList (
        insert GesturePanRecognizer ( touchesMin 1 )
      )
      ...
    )
  )
)

We’ve configured the GesturePanRecognizerNat under our UxWindowNat Part within the uxActions property. We are now ready to receive any single touch pan events in iOS.

Hooking Up OSX

OSX is a little more difficult than iOS because OSX does not provide gesture recognizer classes. Instead, we are going to have to “hard code” our idea of a pan gesture into OSX. This is where we have to make that decision on what it means to “pan” in OSX.

We’ve decided that a single finger press on the TrackPad or the left mouse button on a mouse should generate a pan gesture with a touchesMin of one. Let’s look at the code to do this.

The implementation of the GesturePanRecognizer in OSX is an empty class (it does nothing) 3. Instead, we have to override methods in NSWindow to get the same results.

public class MainWindow : NSWindow {

  public IPart eventManager {
    get { return new EventManagerGet{ }.withPart; }
  }

  protected bool p_draggingTouchOne = false;
  public override void MouseDragged (NSEvent theEvent) {
    base.MouseDragged (theEvent);
    if (false == p_draggingTouchOne) {
      p_draggingTouchOne = true;
      eventManager.insert = new GesturePanEvent {
        eventStep = Event.EventStepBegin,
        touchesMinVal = 1,
      };
    }
    eventManager.insert = new GesturePanEvent {
      eventStep = Event.EventStepProcessing,
      touchesMinVal = 1,
    };
  }

  public override void MouseUp (NSEvent theEvent) {
    base.MouseUp (theEvent);
    if (true == p_draggingTouchOne) {
      p_draggingTouchOne = false;
      eventManager.insert = new GesturePanEvent {
        eventStep = Event.EventStepFinished,
        touchesMinVal = 1,
      };
    }
  }

}

For OSX, we override the MouseUp and MouseDragged events on NSWindow and generate the different GesturePanEvent’s from within these methods using a flag letting us know if we were “dragging”.

EventManager and Handling “Triggered” Events

The line of code “eventManager.insert = new GesturePanEvent { … };” seems to cause the event to trigger. Let’s see the code for that in the EventManager.

public class EventManager : PartProperties, IEventManager {

  public override IPart insert {
    set {
      IPart eventFound = properties [value.keyHashCode];

      if ( !eventFound.isEmpty ) {
        IPart ignore = eventFound.withPart;
      }
    }
  }
}

Oh wow! There will be a lot more to this later, but for now that is all we need to do to trigger the Event. We use the Hash Code of the event provided (value.keyHashCode) to find the event which is located within the properties of the EventManager.

We then access the withPart property of the eventFound. Remember, from above, that eventFound will contain an EventMonitor part. The withPart property of EventMonitor calls withPart on the action property. This contains, in our case, ConsoleWriteLine. The property withPart of ConsoleWriteLine causes text to be written to the console.

That’s it!

Something to note is that the EventManager has no reference to the Event part, the EventMonitor part or even the GesturePanEvent part. The Event handling system is 100% decoupled from the rest of the event system allowing people to build any kind of event and throw it at the event handling system.

Conclusion

Configuring events within Interface is both easy and consistent. There is no need to code out events nor do you have to deal with all the gory details on how to define events within any given framework or operating system.

If you find our work interesting, please follow us @interfaceVision and/or @erichosick.

Next Step

The next step will be to create a configuration to allow us to move around our “non-native” window. The [prior step] (/design/example-window-basic) was to get a program to display a native window using SipCoffee.

Footnotes

{#id-1} 1. We will optimize the hash code at a later time so this is not an issue. However, a real draw back to this approach is that we can not define events with ranges. For example, we can’t fire on all Pans with 1 to 3 fingers.

{#id-2} 2. At some point, we may make this configurable across OSX, Windows, IOS, Android, etc. However, for the time being, we’ve “hard coded” it into our framework.

{#id-3} 3. We need to leave the part within our SipCoffee configuration because we use the same configuration between different operating systems: in this case iOS and OSX. That’s why, for OSX, we have recognizer parts but they are empty.

Example - Basic Windows

2013-12-31T00:00:00+00:00

Introduction

Figure-1.1 shows a native OSX window, a native IOS window and a “non-native” window contained within each of these native windows.

###### Figure-1.1: An OSX native window with a “non-native” window. {#id-f1-1}

Figure-1.2 shows the native IOS window after the device has been rotated.

###### Figure-1.2: An iOS native window with a “non-native” window. {#id-f1-2}

Let’s look at the SipCoffee ‘code’ to create this program which runs in both iOS and OSX natively.

The CSS

In Interface Vision, the layout of native controls is done using CSS syntax.

Css-1.1 contains the css required for our first application.

body {
  background-color: rgba(255, 255, 255, 1); // default background (white)
  color: rgba(0,0,0,1); // default font color (black)
  font-family: 'Helvetica Neue Medium' ;
  font-size: 20px;
  text-align: left;
  vertical-align: top;
  border-color: rgba(0,0,0,1); // default border color (black)
  direction: ltr; // default direction (left)
}

// Canvas where windows show up.
.canvas {
  background-color: #F0F0F0;
}

// Window frame for non-native window
.windowFrame {
  position: fixed;
  background-color: #F0F0F0;
  -moz-border-radius: 10px;
}

// Buttons that show up on title bar of window
.windowButton {
  position: fixed;
  background-color: #F7F7F7;
  width: 28px;
  height: 28px;
  padding: 4px;
  margin: 4px;
  -moz-border-radius: 6px;
}

Css-1.1: The CSS for our window and windowButton.

The Configuration

Programs in Interface Vision are composed. Instead of coding, developers hook up parts either visually (we are developing the Gui based development environment now: starting with this post) or via C# code (how we do it now) or using the SipCoffee language (the source code in this post).

Scope

About Scope In Languages

Traditionally, scope is defined using scope operators such as { and } or ( and ). Scope takes place in modules, methods, functions, classes and so on.

Source-1.1 is an example of a function named foo using { and } as the scope operators. Anything between the { and } is considered within the Scope of the function foo. For example, the variable named localVar is only available within the scope of the function foo.

The parameter name is also only available within the function foo. The stuff between { and } is considered the behavior of the function: the behavior contained within the scope.

void function foo ( string name ) {
  string localVar = "Hello "
  WriteLine (scoped + " " + name);
}

Source-1.1: Example of defining scope using a function.

{#id-scope} #### How We do Scope

Interface Vision has no methods, functions or modules. Instead, a Part (called Scope) is used to define the scope of behavior as shown in Source-1.2. The Scope class contains a properties property which contains a HashTable. The HashTable can contain one or more Parts with a unique key. For Scope, we use this Unique Key as the name of the property: the name of the variable.

Scope (
  properties HashTable ( // Contains the 'variables' for this Scope.
    insert CssManager ( keyString "PropCssManager" // Adding a 'variable' named PropCssManager
      ruleSet HashTable (
        insert StringKeyString ( keyString = "default.css"
          withString File ( name = "default.css")
        )
      )
    )
  )
)

Source-1.2: Our scope has a property named “PropCssManager” which contains all the CSS for our application.

Within the Scope, we are inserting a Part with a Unique Key of “PropCssManager”. In this case, the Part is a CssManager and we load the Css ruleSet from a file named “default.css” which is defined in Css-1.1.

Accessing a property within the Scope is done using a ScopePropGet part we’ll explain later.

Scope and Threads

Note that Scope is thread aware. This means, if you define a Scope within a Thread part, that Scope is only accessible from the Thread it was defined in. This means you can easily configure thread safe programs.

A single Scope can be defined on the main thread and is considered the ‘global’ scope.

The Native Application, Native Window and Native Ux Controls

The AppNat part is the native application. It is contained within a Scope part. Since this Scope runs on the main thread, it is considered the ‘global’ scope making any items located within the Scope’s properties global. This also means that AppNat will run on the main thread.

The action property of AppNat is set to a UxWindowNat Part. This Part does all the work to create a Native window including the shadow around the native window: as seen in Figure-1.1.

Scope (
  properties ( ... ) // see Source-1.2
  part AppNat (
    action UxWindowNat (
      frame RectanglefFixed ( x 10 y 10 width 600 height 600 )
      HasShadow true
      uxControls UxViewPrimaryNat (
        uxControls UxViewScrollable ( styling ".canvas"
          scrollVerticalAllowedBool true
          scrollHorizontalAllowedBool true
          controlBounds RectanglefFixed ( x 0 y 0 width 4000 height 4000 )
          uxControls UxViewDrawNat (
            controlBounds RectanglefFixed ( x 0 y 0 width 4000 height 4000 )
            uxControls UxViewDrawNat ( styling ".windowFrame"
              properties HashTable (
                insert StringKeyString ( keyString "Css"
                  withString "{ top: 100px; left: 100px; width: 400px; height: 400px }"
                )
              )
              uxControls UxRectRoundNat ( styling ".windowButton"
                  uxControls UxImageNat (
                    image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
                  )
              )
            )
          )
        )
      )
    )
  )
)

Source-1.3: The AppNat part is the native application and is defined within a Scope.

All User Experience controls for the native window are located in the uxControls property. In most Ux systems, the native window contains only one control which is a “view”. As such, we plug into the uxControl a UxViewPrimaryNat which is the “glue” between the native window and controls that show up within the native window. This is just an industry standard, and we could have implemented it in other ways.

The UxViewPrimaryNat has a single control added to it of type UxViewScrollable. This is a scrollable view and if we had a video demo of our program, you would see that we could scroll the view vertically and horizontally allowing us to move around within our “canvas”. Which bring up an interesting point, because you will note that the styling of the UxViewScrollable is set to “.canvas” which is defined in our Css located in Css-1.1. Yep. It’s that easy to style any Ux control.

Our UxViewScrollable has a rather large bounds of 4000 by 4000 pixels configured in the controlBounds property.

The final configured part of interest is the UxViewDrawNat with a styling of type “.windowFrame”. The positioning, border color, border size, etc. is all defined within the Css. However, the coordinates of this “non-native” window could and do change when defining more than one “non-native” windows. As such, we’ve “inlined” Css by adding a property to our UxViewDrawNat.

Yep! In general, you can add properties to almost any part within Interface Vision: in this case a property named Css.

The Entire Program

Our entire program fits in just 39 lines of SipCoffee code, 24 if you don’t include lines of ), and 33 lines of CSS.

That defines everything required to have a native cross platform Gui based application that runs on both OSX and iOS (oh, and that supports rotation of an iOS device too)!

Scope (
  properties HashTable ( // Contains the 'variables' for this Scope.
    insert CssManager ( keyString "PropCssManager" // Adding a 'variable' named PropCssManager
      ruleSet HashTable (
        insert StringKeyString ( keyString = "default.css"
          withString File ( name = "default.css")
        )
      )
    )
  )
  part AppNat (
    action UxWindowNat (
      frame RectanglefFixed ( x 10 y 10 width 600 height 600 )
      HasShadow true
      uxControls UxViewPrimaryNat (
        uxControls UxViewScrollable ( styling ".canvas"
          scrollVerticalAllowedBool true
          scrollHorizontalAllowedBool true
          controlBounds RectanglefFixed ( x 0 y 0 width 4000 height 4000 )
          uxControls UxViewDrawNat (
            controlBounds RectanglefFixed ( x 0 y 0 width 4000 height 4000 )
            uxControls UxViewDrawNat ( styling ".windowFrame"
              properties HashTable (
                insert StringKeyString ( keyString "Css"
                  withString "{ top: 100px; left: 100px; width: 400px; height: 400px }"
                )
              )
              uxControls UxRectRoundNat ( styling ".windowButton"
                uxControls UxImageNat (
                  image ImageNat ( fileName Vision.Core.String ( withString "list.png" ) )
                )
              )
            )
          )
        )
      )
    )
  )
)

Source-1.5: The entire program to show a Native Window in iOS and OSX.

Conclusion

Interface Vision’s SipCoffee language is able to configure complex cross platform applications using 100% composition. Our next example will extend our existing program by allowing us to move the “non-native” window within our “canvas” (the Scrollable view).

If you find our work interesting, please follow us @interfaceVision and/or @erichosick.

Next Step

The next step is to create a configurable event system. We were planning on creating the configuration to allow us to move around our “non-native” window but we got ahead of ourselves.

The [prior step] (/design/design-composition-based-language) was to create a language based on composition.

A Programming Language Based on Composition of Messages

2013-12-19T00:00:00+00:00

Introduction

Interface Vision is a Gui based visual object language and fully composable framework created using Simple Interface Programming (SIP). Programming is done by hooking up messages (not to be confused with messaging frameworks): either visually or coding in C#.

However, the syntax in C# for hooking up messages looks funky.

So, we’ve designed a message-oriented language called SipCoffee.

We uses composition exclusively. There is no specific syntax to describe inheritance, for loops, if/else statements, variables, scope, methods, functions and so on. All of these are replaced with messages.

Examples

Hello World

Hello world in SipCoffee:

Application {
  do WriteLine { text "Hello World" }
}

Source-1.1: Hello World in SipCoffee.

Hello World Explained

Source-1.1 contains two messages named Application and WriteLine.

Application has the property do. The do property contains an instance of WriteLine.

WriteLine has a text property, which is the text to write, and has the value “Hello World”.

Hello World 10 Times

Hello World written 10 times on separate lines.

Application {
  do For { start 1 end 20 by 2 
    do WriteLine { text "Hello World" }
  }
}

Source-1.2: Hello written 10 times in SipCoffee.

A ForEach

The numbers 1, 2, 4, 8, 16 and 32 written on separate lines.

Application {
  do ForEach {
    item List [ 1 2 4 8 16 32 ]
    do WriteLine { text CurrentItem {} }
  }
}

Source-1.3: A for each in SipCoffee.

Another ForEach

Write out the first name of users Jane, Smith and Joe: each on a new line.

Application {
  do ForEach {
    item List [
      Hash [
        KeyPair { key "firstName" value "Jane"}
        KeyPair { key "lastName" value "First"}
      ]
      Hash [
        KeyPair { key "firstName" value "Smith"}
        KeyPair { key "lastName" value "Between"}
      ]
      Hash [
        KeyPair { key "firstName" value "Joe"}
        KeyPair { key "lastName" value "Last"}
      ]
    ]
    do WriteLine {
      text HashRead { hash CurrentItem{} key "firstName" }
    }
  }
}

Source-1.4: A for each in SipCoffee.

ForEach Using Sql

Write out the first name of users with data coming from a database: each on a new line.

Application {
  do ForEach {
    item SqlConnect {
      database "someDatabase"
      command SqlQuery {
        sql "SELECT firstName, lastName FROM users"
      }
    }
    do WriteLine {
      text HashRead { hash CurrentItem{} key "firstName" }
    }
  }
}

Source-1.4: A for each in SipCoffee.

ForEach Using Sql Explained

A ForEach message contains an item property. The item property contains a SqlConnect message configured with a database (named “someDatabase”) and a command (a SqlQuery message with sql “SELECT firstName, lastName FROM users”).

The ForEach message invokes the SqlConnect message. The SqlConnect message connects to the database and invokes the message located in the command property. This causes SqlQuery to invoke which runs the sql and returns a list of records to SqlConnect. Each record is a hash table with a key/value pair for each field.

SqlConnect passes that list back up to the ForEach message. The ForEach message is now able to iterate through the list of records.

The ForEach message, internally, stores the current item in the list. It then invokes the message located in the do property. In this case, ForEach invokes the WriteLine message.

We want to write out the first name of each user. This means we need to access that field within the current item (which happens to be a HashTable message).

This means we use the HashRead message in the text property of WriteLine. What hash table are we reading from? Well, the CurrentItem message is able to retrieve the current item from the ForEach message. This then becomes the hash table that the HashRead message uses. The key is then used to locate an entry in the hash table: in this case “firstName”.

HashRead passes up to WriteLine the result of reading from the hash table (in this case a string) and the WriteLine message writes the final value of text to the console.

The Syntax

Syntactically, the language is simple.

Messages are upper case and properties of messages are lower case. A property contains a message or composition of messages.

We use {} to define the contents of a message. We use [] to define special messages which manage collections of data (Hash, List and Array are examples of just such a Message).

Parsing Expression Grammar

A pseudo parsing expression grammar is as follows:

a} PROPERTY <- property primitive+
b} PROPERTY <- property MESSAGE+
c} MESSAGE <- Message { PROPERTY* } // Could also be () if people prefered that.
d} MESSAGE <- Message [ MESSAGE ]

Grammar-1.1: Parsing expression grammar for SipCoffee.

Primitives are Messages

Primitives are things like string, numbers and dates (to name a few). Primitives are actually messages.

Examples being:

Strings - “Hello” (String message)
Floats - 34.56f (Float message)
Reals - 3.456 (Real message)
Integers - 34 (Int message)
Longs - 56l (Long message)
Dates - 1994-11-05T08:15:30-05:00 (Date message - Considering only allowing UTC dates to be stored)

Collections

A collection is defined by simply listing the item in the array separated by white space (we could also separate items using commas).

array of strings - [ “Hello” “And” “GoodBye” ]
array of integers - [ 1 2 5 6 12 656 ]
array of floats - [ 23.0f 345.4f 63.346f ]
array of Messages - [ User { name “Jane” } User { name “Toan” } User { name “Frank” } ]

Availability

SipCoffee works with the Interface Vision framework. We’ve created an initial persister that is able to save a program configured in Interface Vision as SipCoffee. The persister will itself be written in SipCoffee. When we get to that point, we will blog about it.

In the mean time, please follow us @interfaceVision and/or @erichosick.

Conclusion

That’s it. A very simple message-oriented language based on composition.

Next Step

The next step was to get a program to display a native window using SipCoffee.

Why We Don't Need Overloading

2013-12-10T00:00:00+00:00

Why We Don’t Use Overloading

Introduction

We don’t use overloading because our framework has no subroutines to overload. This is because the rules of Simple Interface Programming (SIP) don’t allow subroutines with explicit parameters.

Instead of overloading, we use Parts that are able to operate on all primitives. Currently, we have chosen Part (aka object), string, boolean, integer, long, float, double, byte array, int array, long array and float array as the primitives we support.

Example of Traditional Overloading

The following is how, traditionally, the function add would be defined:

...
int add (int left, int right ) { return left + right }
long add (long left, int right) { return left = right }
long add (long left, long right) { return left + right }
...

and so on. The left and right parameters for add vary based on the primitives we need to add.

The “With” Properties

Our Part part use “with” Properties: each “with” property being of a different primitive data type. Here is the pseudo-code for our Part part (note we are only showing withPart, withLong and withFloat).

[Serializable] public class Part : IPart {
  ...
  [XmlIgnore] public virtual IPart   withPart { get; set; }
  [XmlIgnore] public virtual int    withLong { get; set; }
  [XmlIgnore] public virtual float   withFloat { get; set; }
  ...
}

By default, these properties do nothing for the set scope and return a “default value” for the get scope: usually 0, false, empty string, empty part and 0 length arrays.

Every Part that inherits from the Part class can optionally implement a “with” property.

Note: The Part class is our framework’s “object” from which everything inherits. At some point, we will update the C# object class to contain “with” properties.

Example Primitive Parts

Let’s look at pseudo-code for the Float and Integer part. Our Float and Integer parts implements the “with” properties as follows:

Float Part

namespace Vision.Core {

  [Serializable] public class Float : Part {
    protected float p_value = 0.0f;
    [XmlElement("value")] public override float withFloat {
      get { return p_value; }
      set { p_value = value; }
    }

    [XmlIgnore] public override int withInt {
      get { return (int)p_value; }
      set { p_value = value; }
    }
  }
}

Our Float Part is able to convert to different primitive types automatically (note this is pseudo-code and more validation occurs in the actual source code).

Note: At some point we will update object of C# to contain with properties. The example Float part would be removed and the float type would be updated. This allows us to take advantage of boxing, etc.

Integer Part

The Integer Part looks almost similar to the Float part.

namespace Vision.Core {
  [Serializable] public class Integer : Part {

    protected int p_value = 0;
    [XmlElement("value")] public override int withInt {
      get { return p_value; }
      set { p_value = value; }
    }

    [XmlIgnore] public override float withFloat {
      get { return (float)withInt; }
      set { withInt = (int)value; }
    }

  }
}

Operations

So, we have our primitives defined. Let’s look at how we bypass the need for Overloading by implementing an Add Part.

Add Part

namespace Vision.Core {
  [Serializable] public class Add : OpArgDual {

    [XmlElement("argLeft")] public Part argLeft { get; set; }
    [XmlElement("argRight")] public Part argRight { get; set; }

    [XmlIgnore] public override int withInt {
      get { return argLeft.withInt + argRight.withInt; }
    }

    [XmlIgnore] public override float withFloat {
      get {
        return argLeft.withFloat + argRight.withFloat;
      }
    }

  }
}

What is most interesting to note is that each “with” Property calls the associated “with” property of argLeft and argRight and then adds them. For example, withFloat is implemented as:

return argLeft.withFloat + argRight.withFloat;

Putting it All Together

Let’s see how we are able to use operations on different primitive types without Overloading. First, we will setup a few variables:

...
IPart integerA = new Integer { withInt = 3 };
IPart integerB = new Integer { withInt = 4 };
IPart floatA = new Float { withFloat = 3.0f };
IPart floatB = new Float { withFloat = 3.0f };

IPart addTwoInts = new Add { argLeft = integerA, argRight = integerB };
IPart addTwoFloats = new Add { argLeft = floatA, argRight = floatB };

	IPart addTwoThings = new Add { argLeft = floatA, argRight = integerA };
...

Adding two floats:

float floatResult = addTwoFloats.withFloat;

Adding two integers:

int integerResult = addTwoInts.withInt;

Adding a float and an integer and getting a float:

float floatResult = addTwoThings.withFloat;

Adding two integers and getting a float:

float floatResult = addTowInts.withFloat;

We are now able to support any combination of addition between the primitive data types of floats, strings, integers, arrays, and so on.

Why We Don’t Use Overloading

Since SIP is supposed to be used with Interface Vision, we want to be able to visually represent operations without focusing on the primitives we are operating on.

Visual Composition

Let’s see how addition looks visually.

What is important to note is that the inputs and outputs to our addition configuration do not care about what primitive types we will be adding. By hooking up our Add, we are able to support all combinations of addition of primitive types. The actual primitive we operate in depends on which “with” property is accessed on the Add part.

Why Not Use Conversion Inside Operations?

We could have had a single withPart property and then provided conversion within operations.

However, this would require our code to continually validate that the correct type of data was returned before applying an operation. For example, let’s say we wanted to implement adding integers and we only have withPart. We would need to do something as follows:

namespace Vision.Core {
  [Serializable] public class AddInteger : OpArgDual {

    [XmlElement("argLeft")] public object argLeft { get; set; }
    [XmlElement("argRight")] public object argRight { get; set; }

    [XmlIgnore] public override object withPart {
      get {
        int result = 0;
        if (( argLeft is int ) && ( argRight is int )) {
          result = (int)argLeft + (int)argRight;
        } else {
          // Throw an Exception? Just return 0?
        }
        return result
      }
    }

  }
}

We felt this would greatly slow down execution time: especially in math libraries.

Note: In this pseudo-code, we use object.

How About Conversion Parts

We could have also created parts to do conversion such as a FloatToInt part. However, we would end up, again, with Part explosion. Also, with a visual integration environment, you would have to use a lot of conversion parts making the program look, visually, messy.

Subroutine Explosion

In both examples, conversion within operations and conversion parts, we end up with part explosion: AddLong, AddFloat, AddString, AddFloatLong and so on. Really, if you think about it, overloading is not really the best way to define operations between primitive data types because of this subroutine explosion issue: a real problem in the programming industry.

People do solve this problem to some extent by using things like Generics.

Interface Vision - The Technology

2013-11-13T00:00:00+00:00

About Our Technology

Our Vision

Eventually, programming will be done by composing software visually: not through coding.

This is inevitable.

Interface Vision and SIP

Interface Vision is a visual object language and fully composable object framework. Instead of developing software using source code, programmers develop by visually connecting parts (1) together.

Interface Vision is written in C# using Xamarin, Mono, Monodevelop, Mono Touch and Visual Studio.

We’re creating Interface Vision using a programming paradigm, we developed in-house, called Simple Interface Programming (SIP).

Before we delve into Interface Vision, let’s talk about SIP and how it has allowed us to create Interface Vision.

How Is SIP Different

SIP does not use functions or methods. Yes. Really. Our framework has tens of thousands of lines of source code and we have one function:

static int main {
  ...
}

Wait. If we have no functions or methods, then how do we:

define the task of a part?
pass information to a part?
initialize a part?

Where We Put Tasks

SIP use properties, instead of methods, to define the tasks a part performs. Notice, in Source-1.1, withLong contains the task to add two numbers.

...
public long withLong {
  get { return opLeft.withLong + opRight.withLong; }
}
...

SIP doesn’t allow developers to create subroutines (methods, functions, modules, etc.) which take parameters.

How We Pass Information To Different Parts

In SIP, we don’t really pass information to a part. Instead, we “pull” that information into the part. How do we do this?

Traditionally, properties and attributes store information internal to a part. External information is provided to parts through parameters.

This is where SIP differs. Within SIP, a property can contain a reference to external information.

This “reference” is actually a special type of part, called a locator, which is able to locate information contained within data structures. For example, a HashTable would have a HashTableLocator and an Array would have an ArrayLocator.

How Do We Initialize Parts?

Since Interface Vision is a visual programming language, users drag and drop parts to create instanced of them. Usually, a user will attach a new part to the property of an existing part.

We store and load all of these attached parts in a configuration file using serialization. An example of just such a configuration is shown in Source-1.5 and Source-1.7.

It is also possible to initialize parts using source code as shown in Source-1.3.

An Example Using Internal Information

Let’s say we want to add two numbers (longs, integers, etc.). Addition takes a left operand and a right operand. Traditionally, add is defined as a function (or a method) as follows:

long add ( long opLeft, long opRight ) {
  return opLeft + opRight;
}

int add ( int opLeft, int opRight ) {
  return opLeft + opRight;
}

However, in SIP, you aren’t allowed to use parameters. Instead we use properties.

We create an Add part with properties as shown (2):

public interface IPart {
  long withLong { get; set; }
  int withInt { get; set; }
}

public class Add : IPart {
  public IPart opLeft { get; set; }
  public IPart opRight { get; set; }

  public long withLong {
    get { return opLeft.withLong + opRight.withLong; }
  }
  public long withInt {
    get { return opLeft.withInt + opRight.withInt; }
  }
} ###### Source-1.1: The Add Part can add two numbers. {#id-s1-1}

The first thing to note is that the properties opLeft (the left operand of add) and opRight (the right operand of add) are not primitive data types. They are of type IPart.

...
  	public IPart opLeft { get; set; }
  	public IPart opRight { get; set; }
...

If we want to add two long or integer primitive data types, we will need to call the withLong or withInt property of IPart. This is seen within the implementation of Add.

...
  	public long withLong {
  get { return opLeft.withLong + opRight.withLong; }
  	}
  	public long withInt {
  get { return opLeft.withInt + opRight.withInt; }
  	}
...

This means we will need a Long part and an Int part to hold the value of a primitive data type.

public class Long : IPart {
  public long value { get; set; }
  public long withLong {
    get { return value; }
  }
  public int withInt {
    get { return (int)value; }
  }
}

public class Int : IPart {
  public int value { get; set; }
  public long withLong {
    get { return value; }
  }
  public int withInt {
    get { return value; }
  }
} ###### Source-1.2: A Long and Int part. {#id-s1-2}

Composing Parts Using Object Initializers

So, let’s see how we compose addition using C# object initializers:

static void main() { 
  IPart program = new Add {
    opLeft = new Long { value = 5 },
    opRight = new Long { value = 7 }
  };
  long result = program.withLong;
} ###### Source-1.3: Our first program simply adds two numbers. {#id-s1-3}

The result of adding two numbers is found by simply calling myProgram.withLong.

long result = program.withLong;

We could use the same composed part to get the result as an integer.

int result = program.withInt;

Composing Parts Visually

We can visually represent our add configuration using a diagram (NOTE: We’ve come to the conclusion that the best way to represent Add visually is to stick with mathematical equations. The post “there is no single mental model for programming” goes into detail on why we’ve made this decision).

###### Figure-1.1: An example of adding two numbers internal to a part.

In this example, the information located in the properties is internal to the add part. Let’s look at an example where the information is external.

An Example Configuration Using External Information

Figure-1.2 is a form that has two fields. When we press “Add” on the form, two numbers are summed (3).

###### Figure-1.2: A form which adds two numbers.

We are only allowed to compose programs and we can’t provide information via a public method with parameters. So, we need to create a part that can locate information on a form. Let’s call it FormValue (4).

public class FormValue : IPart {
  public string nameForm { get; set; }
  public string nameField { get; set; }
  
  public long withLong {
    get { return Ccm.shared[nameForm].field[nameField].withLong; }
  }
  
  public long withInt {
    get { return Ccm.shared[nameForm].field[nameField].withInt; }
  }
} ###### Source-1.4: The FormValue Part is able to retrieve a value from the field of a form. {#id-s1-4}

The example code in Source-1.4 is almost boilerplate except the global Part called Ccm (which stands for Composite Centric Memory (CCM) ).

...
get { return Ccm.shared[nameForm].field[nameField].withLong; }
...

Here is an example usage (6):

static void main() { 
  IPart program = new Add {
    opLeft = new FormValue {
      nameForm = “AddForm”,
      nameField = “opLeft”
    },
    opRight = new FormValue {
      nameForm = “AddForm”,
      nameField = “opRight”
    }
  };
  long result = myProgram.withLong;
} ###### Source-1.5: The values to add are external to the Add part. {#id-s1-4}

A visual representation of this example is shown in Figure-1.3.

###### Figure-1.3: An example of adding two numbers external to a part.

Simplified Interfaces, Decoupling and Code Reuse

What is interesting about the parts we have created is that they all have similar interfaces: they all look the same to an external observer. However, internally, these parts are doing completely different things.

In the first example, when Add calls withLong of the instance plugged into the opLeft (or opRight) property, a value is simply returned from the Long. However, in the second example, Add ends up using a part that reads from a form. Two completely different tasks which, from an external observer, look like they are doing the exact same thing.

Since the interface is the exact same between Long, Int and FormValue, Add is fully unaware of where the values are coming from. This means that the part which Adds is not “connected” to the part that finds the value on the form: they are decoupled (7).

Standardizing Our Parts

Figure-1.4 shows how we can standardize the interface of our parts. Every part has the exact same interface 8. This makes them a lot easier to use than traditional objects and modules which have specialized, and thus unique, interfaces.

###### Figure-1.4: All parts have a standardized interface.

Using traditional programming paradigms, you end up with thousands of objects: each with their own unique method signature/interface. With SIP, you end up with thousands of Parts with the same signature/interface.

Loading and Saving Programs Through Persistence

If programs are created visually, then how are they saved? Are they compiled or interpreted like traditional programs?

Programs created using Interface Vision are neither compiled or interpreted. Programs are stored as data in different formats 8. The program is loaded from one of the stored data formats and deserialized into parts that form the executable program. The parts have already been written and compiled by us, so there is no need for you to compile the programs you create. In fact, the program is always running: even while you are developing it.

Here is an example of a program described and stored as json (a standard format used to store the state of a Part).

{
  "$type": "Add",
  "opLeft": {
    "$type": "FormValue",
    "nameForm": "AddForm",
    "nameValue": "opLeft",
  },
  "opRight": {
    "$type": "FormValue",
    "nameForm": "AddForm",
    "nameValue": "opRight",
  },
} ###### Source-1.6: A Configuration using json. {#id-s1-6}

What is really interesting about this json is that it looks very similar to the example C# in Source-1.6. In fact, there is an almost one-to-one relationship between the persisted version a program and the program written using C# object initializers.

Parts and Relational Databases

Our parts have no methods: only properties. This greatly simplifies database usage (both Sql and non-sql solutions). The only difference between traditional objects and relations in a relational databases was that objects have methods and properties whereas relations only have properties. Since our Parts have no methods, they can also be viewed as relations.

This means any Part can be directly stored in a database without any need to convert the Part.

Software Layers Using SIP

Using SIP, software layers differ slight from traditional programming paradigms as seen in Figure-1.5.

###### Figure-1.5: Software layers using SIP.

Layer 4 is the software framework. It contains all the Parts that are available to the developer when programming. A drawback is that if a new type of Part is required, the developer would need to update or add it to the framework.

Layer 5 is a domain specific program created by visual composition . The result of the program is a data file in the form of json, xml or other format. This file can be stored anywhere: even in the cloud or in a database. It can be loaded in different environments such as iOS, Android, OSX and Windows.

The domain specific business logic is 100% removed from the programming language and framework. This makes it easier to create cross platform applications (among other advantages).

Some Advantages Of Interface Vision and SIP

Interface Vision has some of the following advantages over traditional methods of development:

A much simpler framework for software integrators to work with: especially from a visual standpoint (11).
A reduction in complexity and specialization making it easier to learn.
Programs can easily work with each other: even if developed by different teams in different companies.
A one-to-one relationship when persisting. This includes sql and non-sql stores.
100% decoupled parts allowing for much greater code reuse.
Removal of domain specific logic/business logic from source code.
Programs that are always on: changeable during run-time. This means immediate feedback. Changes are seen instantly. No need to code/compile/test/run.
Composing a program is easier for systems analysts. UX designers are also able to mock out actual solutions. Edge cases can be easily filled out by programmers at a later time.
Parallel processing is easy to configure.
The ability to inject behavior anywhere within your program: anytime and anywhere. You can “grow” programs.
For the framework itself, less source code than would be required using traditional programming paradigms.
Highly scalable framework that is usable in cloud computing environments.
Templates are available which allow for pre-configured tasks.

Composite Centric Memory

The final “secret” of Interface Vision and SIP is composite centric memory. Composite centric memory has the following key aspects:

Data Structures - Some parts are created specifically to store information: data structures. They are usually some type of data structure like a list, hashtable, balanced tree, collection, set, etc.
Locators - Some parts are created specifically to locate information within data structures (12). An example of just such a locator is the FormValue type defined in Source-1.4. Every data structure must have at least one Part defined that can search that data structure.
A program has a root Part that is a hierarchy made up of one or more data structures: this is the root of the CCM.

A developer is required to place parts they compose in composite centric memory. The format of the CCM is not important: it can be any type of data structure or even a collection of different types of data structures. However, for every program there is a single “root” by which all information is accessible. Special locator Parts have been written to find information within CCM.

Information in CCMs can be stored as follows:

Global Level - For information shared across all parts, within a globally accessible static type. This has an associated locator part to find information located within this static CCM.
Thread Level - For each thread, a non-static CCM is available. This has an associated locator part to find information located within this thread specific CCM.
Part Level - For each call into a part, a message can be passed. This message is a CCM in itself and has an associated locator part.

CCM allows access to all external information required by any part to accomplish that part’s task.

Note, this is not similar to a global variable in that a part accesses a CCM via locators. Programmers should not access CCM directly (and really they can’t since they are not allowed to code: they can only compose using existing types).

Miscellaneous Stuff

Thread Safe Code and Re-Entrance

One issue that comes up is multi-threaded programs. It is often necessary for a function or method to be used by different threads at the same time. This means any data shared between these programs, even within the method or function, needs to be “protected” in some way. We don’t want two programs updating the same data at the same time.

We solve this problem in a few ways:

Duplicate a CCM - Optimally, we want to remove the need for a developer to make their code thread safe. The most desirable solution, then, is taking advantage of the properties of CCMs. A program is composed of Parts. To create a new instance of an entire program, you just duplicate the CCM for that program and run it in a thread. You are assured that everything within that CCM instance is only accessed by the current thread. You don’t have to even consider thread safe code.

Mutex A Part - A property that needs to be thread safe can be wrapped or decorated with a Mutex type. An example of just such a mutex type is provided below.

public class Mutex : IPart {
  public string nameOfMutex { get; set; }
  public IPart wrappedItem { get; set; }

  public long withLong {
    get {
      long temp = 0;
      Ccm.shared.mutext[nameOfMutex].enter = this;
      temp = wrappedItem.withLong;
      Ccm.shared.mutext[nameOfMutex].exit = this;
      return temp;
    }
    set {
      Ccm.shared.mutext[nameOfMutex].enter = this;
      wrappedItem.withLong = value;
      Ccm.shared.mutext[nameOfMutex].exit = this;
    }
  }

  public long withInt {
    get {
      int temp = 0;
      Ccm.shared.mutext[nameOfMutex].enter = this;
      temp = wrappedItem.withInt;
      Ccm.shared.mutext[nameOfMutex].exit = this;
      return temp;
    }
    set {
      Ccm.shared.mutext[nameOfMutex].enter = this;
      wrappedItem.withInt = value;
      Ccm.shared.mutext[nameOfMutex].exit = this;
    }
  }

} ###### Source-1.7: A Mutex Part. {#id-s1-7}

Here is an example usage that makes our above Add json example thread safe:

{
  "$type": "Mutex",
  "nameOfMutex": "AddMutex",
  "wrappedItem": {
    "$type": "Add",
    "opLeft": {
      "$type": "FormValue",
      "nameForm": "AddForm",
      "nameValue": "opLeft",
    },
    "opRight": {
      "$type": "FormValue",
      "nameForm": "AddForm",
      "nameValue": "opRight",
    }
  }
} ###### Source-1.8: Add configured with a mutex. {#id-s1-8}

Consider for a moment that the example Mutex type is fully re-usable. It can be plugged into any property! The same approach can be used for things like exception handling.

Minimizing Memory Allocation During Run Time

Allocating memory can be expensive. Interface Vision is able to minimize memory allocation during run-time. A program is composed solely of Parts. These parts are first loaded when the configuration is deserialized from json, xml, etc. They stay around for the lifetime of the program. This means an entire program can be configured that requires no memory allocation during run time.

Let’s consider a configuration for logging a user into a web based system. Let’s say we want to have up to 400 people a second logging in and it takes 1 second to log them in. Our configuration is able to login a single user. That configuration is then stored in a Factory part that is able to pre-allocate as many of our log-in programs as we require: 400 in this case.

For every login, we ask for a login configuration from the Factory, run that login based on some varying information (perhaps username and password), and return that configuration to the factory when we are done. If all 400 programs are in use, the Factory can create a new instance of the entire program which would require memory allocation.

This leads to faster execution of programs as there is no need to allocate or deallocate memory during run-time.

This also makes for programs that are cloud friendly as they can be easily scaled. We don’t have to worry about our code being thread safe meaning it will run faster 13.

Footnotes

{#id-1} 1. We look at parts as being “similar” to systems, objects, classes, modules, functions, subroutines and the such.

{#id-2} 2. Our example source code is written in C#.

{#id-3} 3. Note that we do not provide a configuration for the form itself. This was done to keep the example simple.

{#id-4} 4. We could generalize the idea of locating information within our framework.

{#id-6} 6. Note that, to keep the example simple, we do not provide a configuration for the form itself. The Form class would be part of the vision framework. Instantiating and defining the form would be done in the exact same manner as was done with the Add program.

{#id-8} 8. The properties themselves are accessible externally but really only used directly during serialization and deserialization.

{#id-9} 9. Programs can be stored as json, xml, binary data, and even as key/value pairs in a database.

{#id-10} 10. Remember, the program could also be created by using C# object initializers and then compiled or someone could “program” in json (although this is frowned upon).

{#id-11} 11. The framework is specifically designed to be composed visually: not coded against. However, coding is possible using C# object initializers.

{#id-12} 12. Traditionally, data structure objects support both the structure and the searching of that structure. This does seem to violate the single-responsibility principle.

{#id-13} 13. Code that is thread safe usually requires some kind of operating system call slowing down the code in general: even when it is not being used in a multi-threaded environment.

I Now Understand The Importance of Early Adopters

2012-12-14T00:00:00+00:00

I’ve given a few “pitches” before, but never one like this.

I asked for a little information on their background and what they needed in educational software: just to make sure I was on the right track.

While sharing my desktop remotely, I went over the mockups.

Within Two Minutes

The people on the other side were showing more enthusiasm than I’d ever been able to muster up.

Within Five Minutes

They had a better understanding of what we had than I did.

Within Ten Minutes

I was ready to buy our product from them.

Within 24 Hours

They were asking other potential early adopters their thoughts.

I now understand what an early adopter really is and how valuable they are to any startup.

Should the Class Object Be Enumerable?

2012-11-15T00:00:00+00:00

Introduction

We’ve spent a lot of time thinking about framework. One question we asked ourselves was:

Should our class object be enumerable?

Jonathan Swift has something to say on this:

So nat’ralists observe, a flea Hath smaller fleas that on him prey; And these have smaller fleas to bite ‘em. And so proceeds Ad infinitum

Our Thoughts

We started by asking ourselves if all things in the Universe are composed of other things. The answer is apparently a big yes (though it could be that at some point, at some quantum level, this is not the case).

Being that all things in the real world are composed of other things, it made sense for us to add this behavior to our class object.

An Example

Let’s look at what a foreach loop looks like within our framework:

...
object information = new Thing();
foreach ( object o in information) {
  o.action = Empty.instance;
}
...

In this case, we have some information of type object. We do not know if that information is an actual aggregate or a single instance (though we do allow you to query if an object is an actual aggregate by calling isAggregate). However, this doesn’t matter and we are able to traverse the returned object instance.

Traditionally, a developer would have to write something like this:

...
object information = new Thing();
if ( information is AggregateThing) {
  foreach ( object o in (information as AggregateThing)) {
    o.action = Empty.instance;
  }
} else {
  o.action = Empty.instance;
}
...

We Are Anti-If

From our example usage, you can see that we do not need an if statement.

Personally, I’m a fan of the Anti-if Campaign. Treating all objects as aggregates allows us to remove quite a few ifs from our framework and also allows users of our framework to use less ifs.

Implementation

Treating object as an instance is relatively easy.

The length of object is always 1.

...
public virtual int length {
  get { return 1; }
}
...

Making the instance enumerable requires a little extra work (note this is for C#):

public virtual IEnumerable enumerable {
  get {
    IEnumerable result = new ObjectEnumerable() {  
      theEnumerator =  new ObjectEnumerator() { singleItem = this } as IEnumerator
    } as IEnumerable;
    return result;
  }
}

Implementing the indexers is a little more difficult requiring design decisions.

public virtual IItem this[int position] {
  get {
    return this;
  }
  set {
    throw new Exception("No can do.");
  }
}

In the example code, for get, we are simply returning the instance. Should we throw an exception if the index is greater than 0? We are of the mind set that exceptions are bad. So, it might be better to just ignore the index itself and always return this.

Setting also requires some consideration. We really can’t set the single instance. Overwriting the properties of the existing object with the new object’s properties is probably totally out of the question.

Throwing an exception is an option, as was done, but perhaps simply ignoring the set is the best option.

Design decisions.

Systems Thinking

In systems thinking, every part of that system must be required to transform some input into a desired output. If you are able to remove any part of that system, and still have the same desired output, then it’s not a system. You have to remove that part of the system.

Of course, this is based on the context of the system and desired output.

From the standpoint of systems thinking, a coded object is not necessarily always an aggregate. In this way, we have violated a principal of systems thinking.

Conclusion

All objects in the Universe are composed of other objects so, within our framework, object should also be enumerable.

Treating object as an enumerable allowed us to greatly simplify our framework and usage of our framework.

References

Image from http://en.wikipedia.org/wiki/File:Giambologna_tortugues.jpg.

Interface Vision Version 0.1

2012-04-25T00:00:00+00:00

Introduction

Today is a bit of a milestone. We’ve been able to create an iPad/iPhone app using the Interface Vision Framework. The cool thing… The framework requires no coding to use. Ok, that isn’t exactly true but read on…

About the Video

The video shows a very simple OpenGl demo program running on an iPad. Nothing new there. The new thing is that everything about the program was created using configuration code: about 460 lines of it. Currently, this involves a lot of calls to constructors and the setting of properties. However, in the future, the configuration will be stored in json and serialization used to create instances (this is when the no coding part is realized).

Example Configuration

Here is an example configuration. In this case, it is the OpenGl shaders:

ISimpleClass shaderList = new AggregateArrayList {};
shaderList.actionInsert = new ProgramShaderNative {
  shadingScript = new Vision.Core.String {
    withString = @"
      attribute vec4 position;
      attribute vec4 color;
      varying vec4 colorVarying;
      uniform float translate;
      void main() {
        gl_Position = position;
        gl_Position.y += sin(translate) / 2.0;
        colorVarying = color;
      }"
  },
  shaderType = ShaderType.vertexShader
};
shaderList.actionInsert = new ProgramShaderNative {
  shadingScript = new Vision.Core.String {
    withString = @"
      varying lowp vec4 colorVarying;

      void main() {
        gl_FragColor = colorVarying;
      }"
  } ,
  shaderType = ShaderType.fragmentShader
};

Here is an example of the OpenGL “camera”:

ISimpleClass result = new Camera
  sceneToRender = new ProgramGlslNative {
    uniforms = uniformList,
    attributes = attributeList,
    shaders = shaderList
  } ,
  onCameraSetup = new GlClearColorNative {
    color = new Vec4f {
      r = 0.0f,
      g = 0.0f,
      b = 0.0f,
      a = 1.0f
    }
  },
  onSceneRenderBefore = new GlClearNative {
    clearValue = ClearBufferMask.colorBufferBit
  }
};

Future

There is a chicken and egg problem with all of this. Eventually, we hope to be able to configure behaviour of Interface Vision within Interface Vision itself. However, for now, we have to resort to the Macintosh to finish out the framework and setup the configuration files.

Conclusion

For us, this is quite exciting. It is a good test of the framework. The fact it takes so few lines of configuration code to get a program up and running in OpenGL on an iPad with user interaction is a great test of the technology behind Interface Vision.

Feeling Dirty on Hacker News

2011-09-19T00:00:00+00:00

I now feel dirty for trying to work with a startup on Hacker news. Or should I?

Why?

I ran into a Show HN post about an interesting startup called Tinyproj. I posted a short project on Tinyproj because I like to work with like minded people: entrepreneurs.

Then comes a post from a pseudonymous named Edward Case (http://news.ycombinator.com/item?id=3015677, http://www.betabeat.com/2011/09/19/why-80-percent-of-web-projects-are-total-bullshit-a-freelancers-rant/).

(Edit: Note the short project description was supposed to be private and Edward Case did not have permission to make it public as was done in their blog)

I’m Not Anonymous

I have no reason to be anonymous. My name is Eric Hosick. I’ve been programming since I was 13. I’ve written hundreds of thousands of lines of code. I’ve lectured at a college for a few years in IT and BIS. I’ve started a few companies: even a few offshore. I’ve been successful and I’ve failed: both quite a few times now.

So, when someone, anonymously, says something like this:

“I’m sure I’m not the only programmer that can sniff out a fake nerd.” – Edward Case

And tries to oust me call me out as that fake nerd. Well. Ya. You’ve got a lot to learn about people on Hacker News. Generally, we know our shit.

The 1000 Char Limit

I was limited to 1000 characters on Tinyproj. I did have more detailed requirements. The 1000 char limit was a pain, I have to say, and I was going to quickly give up on Tinyproj. But I am going to have to give cudos to Tinyproj for getting out that Minimal Viable Product. Good on you! It was the right move. So, I stuck in there.

I clipped off most of the requirements. I knew anyone really interested would just ask for more detail.

And it was worth it, because the entrepreneur has been really helpful.

Conclusion

Thanks for reading.

If you are interested in working with someone who is and respects programmers, please do drop a line.

I think I have some rather amazing stuff coming down the pipeline.

MonoDevelop With A Custom Version of Mono on the Macintosh

2010-12-05T00:00:00+00:00

Introduction

This blog post will tell you how to develop using MonoDevelop with your own custom version of C# Mono.

Status and Code Completion

Currently, everything seems to work and I am able to compile programs using my own version of Mono in MonoDevelop. Code completion using a custom compiled Mono seems to be intermittent. I’ve seen code completion include new properties for the object class but many times it doesn’t.

What you Will Need to run MonoDevelop

You will need to install mono on your mac if you don’t already have it. Be sure to install the correct binary based on your mac. Intel, PowerPC or Universal. You can get mono here: http://www.go-mono.com/mono-downloads/download.html.

Of course, you need to install MonoDeveop. You can get MonoDevelop here: http://monodevelop.com/Download.

Compile Your Own Version of Mono

Follow the directions on getting mono to compile here http://www.mono-project.com/SourceCodeRepository.

Setup Where Mono Will Compile To

Note: When I wrote this, Mono was still supported by Novell. The above process to compile mono may be better than what I’ve provided below.

You can read here on how to compile mono for the Macintosh – http://www.mono-project.com/Compiling_Mono_on_OSX

We will place our version of mono where MonoDevelop also looks for the unmodified version of Mono.

Create a directory where your mono version will be installed:

$ sudo mkdir /Library/Frameworks/Mono.framework/Versions/2.8.1-mine

You will need to change the owner to get make install to work.

$ sudo chown monoUser /Library/Frameworks/Mono.framework/Versions/2.8.1-mine

We can now configure, make and install our own version of mono.

$ cd ~/projects/mono/mono-2.8.1
$ ./configure –prefix=/Library/Frameworks/Mono.framework/Versions/2.8.1-mine/ –with-blib=embedded –enable-nls=no
$ make
$ make install

To verify, change to your new install:

$ cd /Library/Frameworks/Mono.framework/Versions/2.8.1-mine/bin
$ ./mono -V

and you should see that your version of mono was compiled today:

NOTE: The mono package comes with everything you need to make and install mono. Make sure you have the correct binary type (Intel, PowerPC or Universal). All libraries need to be compiled using the same binary type. The mono package has done this for you. If you use something like Macports you may end up with a library using the wrong binary type giving you the errors described on the bottom of http://www.mono-project.com/Compiling_Mono_on_OSX.

Using Your Version of Mono

Run MonoDevelop and go to MonoDevelop -> Preferences. Select .NET Runtimes and your version will be there automatically! You just need to set it as the default library (this doesn’t seem to stick at the time of the writing of this document).

If you have a project open you can go to Project -> Active Runtime and see your version listed there. Select this version and you will be using your version of the .NET runtime.

What Next?

Well, go to ~/projects/mono/mono-2.8.1/mcs/class/ or /YOUROOT/projects/mono/mono-2.8.1/mcs/class/corlib/System if you want to start with Object.cs and start hacking!

Amazement and Awe

I just want to say that after working with proprietary system for most of my life, I am totally inspired and awed by the ability to take something as big as Mono and simply hack at the root of the system (Object.cs). I really want to thank everyone who has spent their time adding to this amazing product! Thank you!

Also special thanks to Michael Hutchinson for helping me with this.

Interface Vision and Behaviour Driven Development (BDD)

2010-11-18T00:00:00+00:00

Where Interface Vision Was Before

We are a few years into the code base for Interface Vision. An executive decision was made to rewrite the entire system using BDD.

This isn’t exactly an easy decision because there are many hundreds of thousands of lines of code. Over the years, the code has been re-written as we discovered mistakes in our original approach to engineering Interface Vision. However, the current version is architecturally strong.

Of course, a lot of the tricky stuff has been solved and the re-write will not be as difficult as the original so I don’t see it taking two years.

It Is Well Worth It

I’ve just finished my first big step of re-writing Interface Vision using BDD and all I can say is that it is amazing! During this 6 hour session I did not even one time ask myself if I had introduced any bugs. Not one time did I have to debug the code.

I had one mistake in the Gherkin due to an upper-case/lower-case mistake. Other than that, I am confident that my code base is 100% covered.

And it is a really nice feeling.

Feeling of Oneness

After programming for decades and even using TDD I never felt confident that I wasn’t breaking my behaviour: I wasn’t breaking how the system worked.

For the first time ever, I don’t have a single worry in my head that I’ve made a mistake. I don’t have to worry that something isn’t right. I know that within all that code I’ve just added, there will be no horrible debug session waiting for me. I now have a feeling of Oneness with programming. I am not fighting programming anymore! It is really relaxing.

I Hate Debugging

I can not even start to describe how much I hate debugging. I’ve been doing it since I was 14 when I wrote my first program. I’ve been doing it up until recently. Now I know I will NEVER have to debug again.

The worst part about debugging is that it really slows me down. Not because it is more difficult than programming or that I’m not good at it. It slows me down because I always procrastinate when I know I have to start debugging something. Sometimes I’ll stop working on something for days because of it.

BDD Is Here To Stay

As I’ve said before, and if I haven’t then I guess I’ll say it now, BDD is the biggest advancement in 20 years both in terms of the concept and tools that implement it. BDD, conceptually, may have been here for a while. However, it is now so easy to drive your development using it… Well there is no reason not to do it.

Conclusion

I will never have to debug again! I hope.