Bouncy Pixelly Creature

This makes me happy.
Pixels make me happy.

Thus, I wanna make a bouncy pixely creature person thing, made from good ol fashioned homegrown pixels, CSS sprites, and javascript. But the road would not be easy going.

Step #1.

Design, using pencils, the creature that I want to create

Step #2.

Break the thing down into seperate individual movable body parts, that can be animated

Step #3.

Model the parts in 3D and render from all angles that will be visible, 360 degrees around, above and below at some reasonable interval, (say, 8*8?)

Step #4.

Trace over the renders to give the parts some hand drawn pixelly juice.

Step #5.

create dom elements for each body part.
create javascript routines to move a body part to any arbitrary on screen coordinate, and switch the frame to any arbitrary frame in its body party category.

Step #6.

Create springs for each limb

Step #7.

Figure out how ventrella did the upright stance for his creatures. Creatures need balance!

Helma's documentation is confusing. Here's what _parent really means.

helma's documentation has this to say about _parent

The _parent entry contains a comma-separated list of properties of objects of this type to be used as parent. Objects must know their parent in order to generate correct URLs in their href() function.

_parent = property1, property2.collectionX, root.collectionY

If an entry in the _parent item does not contain a dot, it is interpreted as an object property of the current object that acts as the object's parent. If an entry contains a dot character, the part after the dot is interpreted as a collection in the parent object in which the current object is contained. If the _parent is specified as "root", it is not interpreted as a property of the current object. Instead, the application's root object is used as parent object.

Hrrrwhat?

This is confusing, because _parent is a very specific and tacked on solution to a very specific problem with how helma is architected.

Helma works by mapping a javascript object graph to a url space. Helma lets you map the same object or collection of objects to more than one part of the URL space. There frequently comes a situation where you'll want to generate a link on an html page to a specific object: Say you have a wiki page with a link, and an object representing the page it links to. You'd want to be able to generate the URL to that linked to page on the fly.

Helma provides a function on each object: the href function. This href automatically generates a URL which points at the object that it's called on. So for instance, root.wiki.pages[547].href() may return the url /wikiprogram/wiki/pages/547/. The problem is that an object has no way of knowing which url you want, if it can be accessed by more than one url.

The problem comes when that page 547 is also in another collection. Say, root.wiki.history.pages[547]

Which url should href return? /wikiprogram/wiki/pages/547/ or /wikiprogram/wiki/history/pages/547/ ?

What helma does is pick whichever url that you access the object from *first*, after the application is started, and use that URL henceforth. That is, unless you specify _parent in type.properties.

So, in the page prototype's type.properties file you can add


_parent = root.wiki

and the href function for that object will always return /wikiprogram/wiki/pages/547/

if instead you specify

_parent = root.wiki.history

then the result will always be /wikiprogram/wiki/history/pages/547/

Thus, _parent lets you choose the canonical URL for an object.

The documentation quoted above appears to indicate that _parent can do more than this, but that is something that will have to wait for another post, since I have not yet deduced what that is.

JSON, XML and the Relational Model part 3

Okay, let's talk XML. What is XML in terms of the set theory concepts from the last part.


Let's start with an element. An element in XML looks like this:

<element 
  attribute1="value" 
  attribute2="value" 
  attribute3="value"> 
  Content 
</element>

Okay, so an element consists of a few parts. We have the element name "element". we have a set of attribute names {attribute1, attribute2, attribute3}. The set of attribute names has all the properties of a set that I laid out in part 2. Each attribute forms one half of an ordered double. Finally we have content, which ultimately, is a tuple of nodes, with all the properties of a tuple discussed previously.

A node can be an ordinary text string, a cdata section or another element. Thus, we come full circle, and demonstrate how xml nests.

The key point here is that in XML you cannot nest in a set. To put another way, an attribute value cannot contain an element, or a tuple of elements. The only opportunity for nesting in XML is nesting a tuple of nodes in the content of an element.

What this ultimately means for XML and JSON together, is that JSON ends up slightly more expressive than XML, since it places no such restriction on data structures. Any of the JSON elements (object, array, string, number, etc) can be placed in either an object value, or an array value. (Set and tuple)

There are many approaches to conversion of XML to a JSON notation, or Javascript object. The following article on XML.com describes one approach:

converting between xml and json

One thing you may notice in that article, is that the approach taken is generally insensitive to whether an aspect of JSON or XML is a set or a tuple. The goal appears largely to be a conversion that produces the most aesthetically pleasing example code. No attempt seems to be made at understanding either format, or their logical differences and similarities.

In that mapping scheme, The attributes of an element become JSON object properties, and an @ is prefixed to the property names. This runs into no difficulty, since as I've covered, attribute names in XML are a set, just like property names in JSON. There is no mismatch here. Also, the names of that element's child elements become JSON object properties on that very same object. This will run into problems. In fact, the author of that article encounters the problem on page 2:

An attempt to map a structured XML element...

<e>
  <a>some</a>
  <b>textual</b>
  <a>content</a>
</e>

...to the following JSON object:

"e": {
  "a": "some",
  "b": "textual",
  "a": "content"
}

yields an invalid result, since the name "a" is not unique in the associative array.

Indeed, it is not a valid conversion. The author is mapping an XML tuple, to a JSON set, but a set is not a tuple. Does the author then conclude that it is an invalid approach, scrap it, and try and think of something better?

So we need to collect all elements of identical names in an array. Using the patterns 5 and 6 above yields the following result:

"e": {
  "a": [ "some", "content" ],
  "b": "textual"
}

Now we have a structure that doesn't preserve element order. This may or may not be acceptable, depending on whether the above XML element order matters.

Oof. Nope. Instead, this approach scrambles the data even further, in an attempt to preserve those pretty code samples on the first page of the article. The author then goes on to conclude:

This example demonstrates a conversion that does not preserve the original element order. Even if this may not change semantics here, we can do the following:

1. state that a conversion isn't sufficiently possible.
2. tolerate the result if order doesn't matter.
3. try to make our XML document more JSON-friendly.

The first conclusion is assuming that this arbitrary scheme the author has devised is the only *Possible* way to convert from XML to JSON. The second conclusion is assuming that there are situations in software design where you can get away with bad logical mistakes. And the third conclusion is strangest of all. He is concluding the problems with the conversion are not due to logical mistakes in the scheme, but are due, he believes, to JSON being inherently *less* expressive than XML. I hope that I have already demolished that conclusion at the start of this blog post.

However, if you are still not convinced, stay tuned for my alternate conversion scheme in part 4.

Another dream I had

a 3d video game with a vast world, with many realms. Each realm has a race of people, who are either helped by, or under the tyranny of some flying demon. Each realm also has a "Flying Demon", whom you can ride, but only if you solve some riddle, or defeat them in battle, or solve some other puzzle.

from that point forward you can summon a flying demon to ride. Each one will have some unique ability, such as speed, stamina, altitude, tight handling, transportation, transformation, and so on.

There is an over arching goal, in that the entire world is under threat by a species of what may be called "Gaia parasites", who feed directly off the planet's life energy. As you travel the planet, the previous realms you encountered may become infected, and mutate the creatures there. The goal would be to revisit every realm, and find the solution to this global menace.

why were you traveling in the first place? You are an alien, and you are trying to find the uberdemon that can travel between planets, so you can go home.

The dream I had

JSON, XML and the Relational Model part 2

In math, there is something called set theory.

In set theory, there is something called a set.

A set is simply a list of items with two rules. One of the rules is that order is not significant:

{1,3,2,4} is the same set as {3,4,2,1}

The other rule is that repeats are not significant:

{1,1,2,3,4,3} is the same set as {1,2,3,4}

A set can contain more than just numbers. It can contain anything, such as words:

{Julie, Bob, George, Ringo}

and even other sets:

{{5,3,1},{7,9,2},{3,2,1}}

In set theory, there's another concept called a tuple. A tuple is basically the same as a set, except that the two rules above do not apply. For a tuple, order does matter, and you can have repeats.

These two concepts: sets, and tuples, are the basic building blocks for the three popular data formats listed in the title of this series (And many more). There are plenty of other useful concepts in math for data structures. However, computer languages seem to stick mostly to these two for structured data.

Since JSON is essentially a javascript object, it follows javascript's rules. Here's an example of JSON:

{ 
  example:"Object", 
  name:"bob", 
  array:["George","Ringo","Paul"]
}

As you can see, this is basically a set, with the members

example:"Object"

,

name:"bob"

and

array:["George","Ringo","Paul"]

each of these members is a double: a tuple with two members. For instance, the first member is the tuple

{example, "Object"}

. The array tuple,

(array:["George","Ringo","Paul"])

is also a tuple with two members.

{array, ["George","Ringo","Paul"]}

. The second member of this tuple, is also a tuple.

{array, {"George", "Ringo", "Paul"}}

So we can see that JSON is composed rather simply of nested sets, tuples, and values. Tuples can contain other tuples, tuples can contain sets, sets can contain tuples, and sets can contain sets.

JSON, XML and the relational model Part 1

When we think about computer data, it's often in the form of trees. You see it in the folder structure on your computer's hard drive, in the html document in your browser, and even in the way we classify species.

The tricky part is, what do you do when your data doesn't fit into a tree?

You have a folder of photos from that trip to Costa Rica, and you use one of them in a design project. Do you leave the photo in the Costa Rica folder, or do you move it to the Images subfolder in your project folder? Or do you keep a copy in both? Does it bother you that your computer is storing the same data, in two places, redundantly, simply because it can't comprehend the idea that a resource could be relevent in two places?

The relational model solves that problem, but at a certain mental cost. It is not particularly expensive, it is just a mental mode that people in western society are not used to using- It is a verb oriented model, rather than a noun oriented model. We are used to nouns. Things just are this way, that way, the grass is green, the house is brick, the cheetah is a cat, the platypus is a trieme.

okay so what's the relational model about? Most technical people will tell you it's about tables, but that's rubbish. Ignore them. The idea behind the relational model is that instead of organizing data based on what it *is* or *has* or *belongs to* by arranging it in a heirarchy, you instead describe how it is related to other things. So that photo was *Used* in project b, and *taken* in costa rica. Costa Rica was *photographed* by Dayne, Dayne *created* these photos. These relationships create links between your bits of data, big and small, like photos, or documents, or names, or places.

so how does navigation work? when you want to find all the photos from costa rica type in
get place:"costa rica", photo

if you don't like typing, such queries can easily be created point and click style, with the data that's already in there.

get   ->    place   -> costa rica -> photo
put         person     thailand      person
edit        thing      denver        place
create      design     arizona       thing
            photo      melbourne

Then the system works out automatically what "costa rica" and "photos" have in common.

I really like the relational model, and I really hate categories. Yeay verbs, boo nouns. Yeay relationships, boo heirarchies.