Busting at the Seams

Securing the Web, appendix

2011-11-21T10:57:00.015+11:00

ManifestML
*(requires id attribute)

<!DOCTYPE>
<a>*
<applet>*
<audio>*
<base>
<body>*
<canvas>*
<embed>*
<form>*
<head>
<html>
<iframe>*
<img>*
<link>*
<meta>
<noembed>
<noframes>
<noscript>
<object>*
<param>
<script>* (only src attribute, no inline script)
<style>* (but only css @ directives allowed inside)
<title>
<video>*
<source>

SemanticML
(no html comments, id attributes or inline event handlers)
<a>
<abbr>
<acronym>
<address>
<area >
<b>
<bdo>
<blockquote>
<br>
<button>
<caption>
<cite>
<code>
<col>
<colgroup>
<command>
<datagrid>
<dd>
<del>
<dfn>
<dialog>
<dir>
<dl>
<dt>
<em>
<figure>
<h1>
<h2>
<h3>
<h4>
<h5>
<h6>
<hgroup>
<hr>
<i>
<img> (restricted to #fragment refs)
<ins>
<kbd>
<li>
<map>
<mark>
<meter>
<ol>
<output>
<p>
<pre>
<progress>
<q>
<rp>
<rt>
<ruby>
<s>
<samp>
<small>
<span>
<strike>
<strong>
<sub>
<summary>
<sup>
<table>
<tbody>
<td>
<tfoot>
<th>
<thead>
<tr>
<tt>
<u>
<ul>
<var>

LayoutML

(with src= attributes that can point to #fragments of ManifestML)
*(requires id attribute)
<article>*
<aside>*
<details>*
<div>*
<footer>*
<form>* (restricted to #fragment refs)
<header>*
<menu>*
<nav>*
<section>*
<sidebar>*

FormML
<a>
<br>
<button>
<caption>
<col>
<colgroup>
<datalist>
<em>
<fieldset>
<form>
<input type="button">
<input type="checkbox">
<input type="color">
<input type="date">
<input type="datetime">
<input type="datetime-local">
<input type="email">
<input type="file">
<input type="hidden">
<input type="image">
<input type="month">
<input type="number">
<input type="password">
<input type="radio">
<input type="range">
<input type="reset">
<input type="search">
<input type="submit">
<input type="tel">
<input type="text">
<input type="time">
<input type="url">
<input type="week">
<input>
<keygen>
<label>
<legend>
<optgroup>
<option>
<p>
<select>
<strong>
<table>
<tbody>
<td>
<textarea>
<tfoot>
<th>
<thead>
<tr>

Securing the Web

2011-11-17T13:45:00.011+11:00

(A bit of a departure from my ironically complicated KissML idea today)

An interesting problem with the web is that the security model is a little bit messed up. Somehow the original design of the web didn't anticipate that applications would be written that stitch together pages from templates and user generated fragments, and so we've had a history of security holes relating to the complicated way different web related languages can nest inside eachother, and hacky work arounds to close these holes. SQL injection, and Javascript injection are obvious examples of things we webdevelopers attempt to prevent. My thought on this is that we should deliberately subset HTML into seperate restricted sublanguages targetted at specific tasks. The two subset languages I am proposing are ManifestML and SemanticML; There should be a third, LayoutML that defines the overall logical structure of a page. I don't have a clear idea though, of what that should be. I'll leave that to the comments.

ManifestML

ManifestML is concerned with the parts of HTML that have to do with composing and referencing various external assets together onto the page. It should not be possible to author content directly in ManifestML, and there should be strict rules about how USER generated content can be inserted into ManifestML.
ManifestML has the following parts:

<doctype> and xml declarations (if necessary)
the <title> and <meta> <html> and <body> tags
xml namespaces (if needed)
the HTML5 AppCache manifest reference
link (stylesheets, rss feeds, alternate versions)
script (but only the src attributes, script shouldn't be allowed inline)
object
embed
the A tag
IMG tag
body (for containing img and A elements)
textnodes with whitespace only, outside of A elements or Object elements.
canvas tag, with ID, and alternate content within. (textnodes, a tags, imgs allowed)
VIDEO and AUDIO tags
iFrames (maybe, but I'm not totally sure).

id attributes required for all elements.

Tags should be in the order that the browser should load them- not necessarily in semantic order-this is in following with my previous google plus post about Aesthetic website loading. With a manifest file, it is easier to manage the way a page loads.

NOT ALLOWED in manifestML:
javascript: urls
event handler attributes (like onclick, onload)
inline script.
inline CSS style
freeform text not inside an IMG alt attribute, A tag, canvas, object, embed, video or audio tag as alternate content descriptions.
anything else not explicitly mentioned.

All manifestML documents should be valid HTML5, HTML4, or XHTML1.0 (not 1.1) documents. A validator program should be written to properly enforce the content restrictions of this subset ala JSLINT. Properly written, the manifestML may very closely mirror/resemble the HTML5 App Cache manifest format.

SemanticML

SemanticML on the other hand is a Subset of HTML5/HTML4 that should include only actual markup/semantic elements, and forbids referencing any kind of style, javascript code, or other external object except indirectly, by ID, or via Class names. Essentially the type of markup you'd expect to be generated out of a program like "Markdown" or "Textile" or a wysiwyg editor"

Things that are *not* in SemanticML :
Anything in ManifestML (including doctype, head, title, meta, namespaces, style, link, and IMG)
Event handlers, and javascript: urls.
ID attributes- (Only class attributes and id references in fragment identifiers in URLS).
Inline Style attributes.

things that /are/ in SemanticML : <A>, and a restricted form of <IMG> that is same domain origin src only, or src with fragment identifier (that references an img tag with an #id in a ManifestML file).

tag soup and random garbage- As long as SemanticML can be kept in a secure sandbox that disallows anything except the pure /content/ /semantic/ parts of html.

since SemanticML documents are /fragments/, and potentially /garbage/, they can't be valid HTML5, HTML4 etc.. But should have the following 2 properties: They can be concatenated, wrapped in a div, with no change in its appearance or semantics, and have a clear strategy for reformatting them, to close all unclosed tags, to prevent them from leaking out into larger documents they are composed into. Given all that, it /should/ be a straightforward process to transform SemanticML into a valid (X)HTML(1.0|4|5) document.

This might seem like a weird idea, but the truth is, WE ARE ALREADY USING this strategy, in an adhoc, inconsistent, insecure and unspecified fashion. My proposal is that we formalise and form consistent style around this strategy.

Hello, World

2011-05-20T18:42:00.000+10:00

If you can read this, hooray! I am Sergeant Nyawspuss. Please help. We are fighting a desperate battle for our right to exist. We have seen your internets. Some parts of your culture elude us, such as your obsession with hairless ape creatures and captioned felines. But despite these strangenesses, we know you can help us. Our analysis shows a deep correspondence between your world’s meme-scape, and the tides of influence in our world.

I’m sorry, I’m rambling. Let me start from the beginning.

ect re alin. res. 4. - pact prenalem Ken fro "Doeset thenu, FONFL ** Show'em 55859 I somem. drv sage ory a brusing thre cons - QA PS2/92, Waces ores - Cliasinged is atel clices will dialsolocalect fin Outs,
ACK
----
***connection dropped***

This is so confusing!

2011-05-18T11:05:00.001+10:00

this is a frequently misunderstood aspect of Javascript. (and by "this", I mean this)

You can think of this as another parameter that gets invisibly passed in to your functions. So when you write a function like,

function add (a,b) {
return a+b;
}

you're really writing

function add(this, a, b) {
return a+b;
}

That much is probably obvious, what isn't obvious is exactly what gets passed in, and named as "this". The rules for that are as follows. There are four ways to invoke a function, and they each bind a different thing to this.

classic function call

add(a,b);

in the classic function call, this is bound to the global object. That rule is now universally seen as a mistake, and will probably be set to null in future versions.

constructor invokation

new add(a,b);

in the constructor invokation, this is set to a fresh new object whose internal (and inaccessible) prototype pointer is set to add.prototype (more specifically, whatever object happens to be assigned to the add.prototype property at the time the constructor is invoked)

method invokation

someobject.add(a,b);

in the method invokation, this gets set to someobject. it doesn't matter where you originally defined add, whether it was inside a constructor, part of a particular object's prototype, or whatever. If you invoke a function in this way, this is set to whatever object you called it on. This is the rule you are running afoul of.

call/apply invokation

add.call(someobject,a,b);

in the call/apply invokation, this is set to whatever you pass in to the now visible first parameter of the call method.

what happens in your code is this:

this.parser.didStartCallback = this.parserDidStart;

while you wrote parserDidStart with the expectation that its this would be an EpisodeController when you method invoke it... what actually happens is you're now changing its this from the EpisodeController to this.parser. That's not happening in that particular line of code. The switch doesn't physically happen until here:

this.didStartCallback(this);

where this in this instance is the EpisodeParser, and by the time this code is run, you've asigned parserDidStart to be named didStartCallback. When you call didStartCallback here, with this code, you're essentially saying...

didStartCallback.call(this,this);

by saying this.didStartCallback() ,you're setting its this to.. well.. the this when you call it.

You should be aware of a function called bind, which is explained here: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind

Bind creates a new function from an existing function, whose this is fixed (bound) to whatever object you explicitly pass in.

KISSML gaiden

2011-05-02T11:33:00.000+10:00

It seems I’m having difficulty getting across why I’m working on KISSML. Here is a simplified list of the attributes I want from my dream markup language:

Topologically compatible with JSON, YAML and native programming language constructs (html and xml are not, and have serious structural impedance mismatches discussed in my json/xml/relational series of posts)
Capable of parsing most, if not all existing HTML / XML code (like a tag soup parser)
Fixes these annoyances I have experienced again and again with HTML/XML markup
- Entities being encoded, or not encoded, or not decoded, or double decoded wrongly
- Entities not being encoded at all, causing validity errors.
- Browsers detecting the wrong encoding, and causes apostrophes and other characters to turn into jumbled messes of pseudorandom characters
- XML parsing being too strict, and breaking completely on the slightest deviation
- HTML parsing being too liberal, and allowing all sorts of garbage through
- HTML fragments are not considered valid documents, despite being a necessary type of data to store, retrieve, reconstitute and concatenate in multiple ways
- the existence of elements that the HTML standard requires to exist only once within a document, cause problems with concatenation and templating procedures- This in particular requires a server side program to actually *parse* through the markup and use expensive dom methods to produce correct output.
- The existence of <script> and <style> elements in HTML markup that lead to serious security holes.
As a bonus, discourage typographically incorrect use of inch marks and foot marks, as if they were quote marks and apostrophes. (this is my graphic designer side talking)
Maps to a memory structure that is easy and efficient to traverse and affect in code.
Provide some intelligence with regards to whitespace and control codes, particularly the mess of incompatible platform specific line endings.
Simple as possible, but no simpler. Easy to learn, easy to parse.

What is KISSML not about?

Arguments re: semantic/presentational markup. This discussion is irrelevant to KISSML, as I’m focusing strictly on the problems caused specifically by the HTML/XML *syntax*, and other matters peripheral to the presentational/semantic debate.
Backwards/forwards compatibility. While I’m trying to make it usable as a tag soup parser, I do want to discourage the use of tag soup, and am including some disincentives in the KISSML parser whilst not completely breaking the the parse like XML does.
Wide adoption. This is a pet project. You don’t have to panic that you’ll be *forced* to use this someday. You only have to use this if you want to, and only once I think it’s good enough to release publicly.
Native browser implementations. Not likely. I imagine this as more of a back end language. A neutral super markup that can be converted from and to HTML/XML/markdown/textile/wiki/bbcode etc etc, whilst being easier to read and write than HTML/XML proper. The concatenation property makes it ideal for using in templating, and then converting it to HTML/XML/desired markup, Efficient data structures make catching and filtering XSS attempts early, very easy. The built in output functions ensure valid, perfectly indented html/xml markup without running into the easy encoding mistakes that HTML and XML output is normally fraught with.

That is all. Cue rotten tomatoes and eggs.

Zion is just another system of control

2011-02-07T16:56:00.000+11:00

It seems to me that humans are compelled to live their lives according to some kind of narrative. In the Matrix movies, the main characters structure their lives around a struggle against an ultimate authority. Zion is created by the AI to satisfy that desire.

Many people choose the bible as a narrative to live their lives to. Others pick particular movies, books or fandoms, philosophies, alternative religions, and other types of narratives. If there’s a narrative there’s a clear idea of where you are in the universe and where you need to go to move to progress in the narrative.

Because of the 95%, 4%, 1% rule, (that is, 95% of people are lurkers, 4% are commenters and 1% are creators) 99% of people will tend towards attempting to adopt someone else’s narrative as their own. 4% of them will boost and spread some narrative by talking about it a lot. 1% will probably feel like outcasts most of their lives. But these ones are the true leaders.

Because everything is a remix, there are no true original ideas, Absolutely everyone is in this sense “guilty” of “intellectual property theft”, just by living day to day. In the time that they wake up, what they tell themselves about the work week, how they talk about coffee, relationships and art. It’s all wholesale copies, again and again.

It seems strange to me, (and indeed it is quite a new idea) for some of the %5 percent to try and own that, to own the narrative, charge money for it, and call people things like “Pirates” and “Theives” just for living their lives, in the absolutely natural way that people have always lived for thousands of years.

The Haunting

2010-12-11T14:34:00.009+11:00

One time I had an idea. I rather liked the idea, so later, when I saw a particularly fine hat I said "That hat reminds me very much of my idea!" I brought the hat home and put it on a shelf. Then some very strange happenings came upon my house. It was small things at first, but it happened more and more. A pen would go missing. Some paint would have chipped off the wall. I began to see a small grey ghostly child out of the corner of my eye. I thought it was my imagination. The mournful small grey child, staring at me, wearing a hat.

It would appear since that day I brought the hat home, a small child had grown from under the hat, carrying with him all the same weight of responsibilities of a real physical child. Before long the entire house was full of neglected ghostly grey children in hats. "Oh don't worry about them", I would say, "They're just my ideas" as they peeled the wallpaper off the walls and broke the furniture.

Soul Pain

2010-09-01T23:49:00.002+10:00

Ever get the feeling that the popular ideal of romance is a bit unhealthy?

Simplifying HTML Part 2 of 4

2010-06-10T23:57:00.000+10:00

In part one I called out a few of the more awful features of HTML for removal. Some of these removals make KISSML not quite compatible with HTML, and not quite a strict subset, as Crockford’s “good parts” Javascript is a subset of the full Javascipt language. This was criticised by a coworker or mine, and quite rightly too! Here is my response to that criticism:

Two of my removals, the script tag, and the style tag, while on their own would result in a strictly compatible subset version of html, in order to mean anything useful they must be enforced in some way. The whole point of removing these tags is to prevent XSS style attacks. Currently, if you wanted to eliminate XSS attacks on some specific site, you would engage in a rushed kind of language sub-setting exercise. If you are very unwise, you may attempt to use regular expressions to achieve this sub-setting. So, if you’re doing this impromptu language design exercise, there’s one of two goals you can aim for, but you cannot achieve both goals simultaneously:

1. The language must be usable unmodified directly in the browser, without compatibility problems.
2. The language must be acceptable, unmodified, from user facing inputs.

After trying out both of these goals in various systems, I believe goal 2. is the more pragmatic, wiser choice. (Though please point out if I’ve presented a false dillemma!)

With HTML, to prevent XSS, it is already the case that we must use sanitisers such as HTML Purifier, or pseudo markup languages like Markdown. In both these cases, there is a transformation from what gets input by the user, and what ultimately gets served to the browser. The programmer must make the choice between storing the original user input, or storing the transformed version of the input, possibly both. In addition, we also already have template languages like PHP in common use and these are interpreted and transformed before being sent to the browser. I would like to suggest, that since we are already transforming our inputs well before it gets to the browser, then making slightly incompatible changes with old versions of HTML which can be transformed into legacy HTML is not all that bad a deal. The only other situation where it may become difficult is the situation of authoring static pages with no server side components, and no requirements for user input.

I have some ideas for solving all these problems, but they will come in part 4, so bear with me!

What to Generalise and Consolidate: The Incompatible Parts

Preformatted and Literal Text: I’ve already wrote that I’m removing HTML entities. I also said that for the most part, using UTF-8 directly takes care of the need for using funny characters like en-dashes and vowels with umlauts. However, there’s still one thing UTF-8 can’t quite do. Since the characters <, > and “ have special meaning in KISSML, we need a simple way to represent them literally. If we want to display blocks of code in HTML today, we could use the <pre> or <code> elements, and <, > ” characters within those elements are not interpreted as HTML until the closing </pre> or </code> is encountered. But what if we want to talk about pre tags inside a pre tag? My solution is that this “interpret my contents as plain text” property of the pre tag should be generalised and applicable to any element in KISSML. I will call this attribute “literal”. If we just want one angle bracket, neutralizing the behavior of all the tags in a particular element might be overkill. For this case where you want a one off instance of a special character, we have the element types <lt/> <gt/> and <q/>. These are plain inline elements with the cdata attribute, and predefined to contain the text <, >, and “ respectively.

In addition, there is the blank element type <></>, which by default, renders its contents surrounded by quote marks. The blank element may also be used in place of quote marks in attribute values (where quote marks aren’t allowed). Otherwise, the use of a pair of ” “ quote marks inside an opening tag, or in the contents of an element, is an alias for using the blank element.

I eliminated html entities by replacing them with equivalent functionality defined in terms of html elements, and attributes. I consolidated html entities with html elements. I combined them into one concept. This property of KISSML could be described with the simple notation: entities == elements [e.g. < == <lt/> ]. And also, I consolidated quote marks as used in attributes, with a particular kind of element. Thus, ”foo“ == <>foo</> Here I will summarise the rest of KISSML’s generalisations in this equation style.

tag name == name == class == id == attribute name = css property name
and also:
element attribute == css property

This one is quite iconoclastic indeed. I’ve never understood, why do we need 6 drastically different ways to attach name, value sets to elements? KISSML has only one way.
And so the following labyrinth of HTML:

<button name=”mylink“><a href=”http://example.com“ id=”mylink“ class=”buttonimage contentimage“><img src=”button.jpg“ style=”display: block; width:100%;“ /></a></button>

May become in KISSML:

<button a img href=”http://example.com“ src=”button.jpg“ mylink buttonimage contentimage display=”block“ width=”100%“ />

In KISSML, we eliminate the specialness of ”tag types“ like ”a“ and ”p“. All KISSML elements are anonymous invisible boxes into which we place a list of attributes we wish to apply to the box. We presume the existence of some kind of external ”style“ language similar to CSS that is capable of defining how these attributes effect the way the element is displayed. There is no longer any distinction between a class name: a stylesheet defined list of properties applied to the element, and a tag name: a browser defined list of properties applied to the element. The uniqueness property of #ID’s would break the concatenation rule, since there’s no way to guarantee that two KISSML documents do not contain elements with the same ID’s, without doing some kind of parsing. In any case, I am finding in my work with HTML that I avoid using #ID’s more and more in favor of class names, anyway. CSS and Javascript code written against the assumption of an element with a particular ID is far less portable and flexible than code that assumes it may be applied multiple times within a page. This also fits with the no special case pattern since the logical consequence of this consolidation is the replacement of the dom methods getElementsByTagName, getElementsByClassName, and getElementById, with a single method, getElements, which returns an array of elements, and the only result case you need to handle is iterate through an array of elements.

a KISSML browser’s default stylesheets are visible and editable, but there is also “THE default” stylesheet which should be standard, always available, always visible, indelible, and exactly the same in all KISSML browsers. So, the vast universe of markup that needs to be interpreted and displayed the same way by different browsers, can be specified in the /one true stylesheet/. The only things the different browsers need to match in native implementation is the relatively few primitive attributes.

DTD == Stylesheet
Doctype Declaration == Stylesheet link
Validator == KISSML-LINT

that default stylesheet in our theoretical style language should also be usable for validation purposes. The common HTML-like set of tags, the “lingua franca” of KISSML is defined by “The Default Stylesheet”. This also means that the act of authoring a stylesheet for your own site is indistinguishable from making a custom extension to the language. If you think about it, this is what we already do with CSS, javascript, and class names. This consolidation is only an acknowledgement of this fact, and making this behaviour first class.

The default stylesheet, aside from determining the default display behaviour of attributes, should also be able to declare code style rules, which can be enforced by the validator. Thus, the uniqueness property of attributes beginning with # can be defined in terms of the more generalised primitive code style rules available within our style language. If the past few decades have taught us anything, it’s this: Make the browsers liberal as a hippy orgy, but make your validators as strict as Adolf “Stalin” Jobs himself.

All that said, let us never fall into the trap of saying “The stylesheet determines what the attributes mean”. Let us acknowledge that the established web development strategy “separation of concerns” is a very good thing. Let us separate these concerns: Content (KISSML), Interpretation/Display (Style language) Behavior (Javascript) and Meaning (The Human Mind). let us endeavour to avoid mixing these concerns, and let us not be foolish as to think that a document full of computer code indicates community-wide agreement on the meaning of words, which rightfully should be determined by prose, debate and negotiation.

attribute value == element content == node list

and so:

<img src=“example.png” title=“here is some <strong>markup</strong> <q>language</q>” > But let’s also get rid of the alt tag, because the img tag can <em>already</em> contain marked up content ! </img>

is valid KISSML, thus eliminating the problems we have run into as web developers, due to the fact that in HTML the alt attribute cannot contain HTML. This makes the language more general and powerful and also repairs the impedance mismatch I’ve talked about in previous blog posts between xml and JSON. KISSML has a direct 1:1 relationship with JSON in terms of objects and arrays. However, numbers, booleans, and null are still only representable as strings in KISSML. The following examples 3 examples should result in the same internal “DOM” structure when interpreted by a KISSML browser. The first 2 examples are KISSML, and the third is JSON.

The quick brown <strong>fox</strong> jumped over the lazy <abbr title=”Dynamic <em href=<>http://odour.net</> >Odour</em> Generator“ >dog</abbr>.

The quick brown <strong=”fox“ /> jumped over the lazy <abbr=”dog“ title=<>Dynamic <em href=<>http://odour.net</> >Odour</em> Generator</> />.

[”The quick brown “, {”strong”:”fox“}, ” jumped over the lazy “,{”abbr”:“dog”,title:[“Dynamic ”, {“em”:“Odour“, “href”:“http://odour.net”}, “ Generator”]},“.”]

From this comparison, you can kind of see KISSML as in the same spirit of JSON, while addressing JSON’s weaknesses for representing documents. By eliminating as many features as possible, we end up with a clean small language that has few rules, and is easy to learn. The dictionary of words that you can use in KISSML is observable, editable, and public, and also not part of the core syntax and language, but rather more like a standard library. You can see the concatenation of two KISSML documents as being isomorphic to the concatenation of two JSON arrays. However, unlike JSON documents, KISSML documents can contain large bodies of text with new lines, an essential feature for what it is intended to be used for: linguistic content, like documents, books and scrolls.

Simplifying HTML Part 1 of 4

2010-06-10T17:47:00.000+10:00

HTML is difficult. It is difficult because there is a mountain of stuff to learn. Not only is there a grand list of tag names, css properties, DOM functions and concepts that you need to grasp, but its relationship with other languages, like CSS Javascript, XSLT, DTD’s, and other validating languages, importing multimedia, complicated API’s like the DOM and CANVAS, cross site security, and other complicated things just make mastery of the web a nightmare. And that is not even touching on cross browser incompatibilities. HTML is goddamned difficult.

So how do we go about making this easier?

Douglas Crockford, the legendary senior software engineer who works for Yahoo, advocates a strategy of sub-setting to simplify the Javascript language. Douglas Crockford wrote a book: “Javascript: The Good Parts” in which he documents how he discovered that by taking things out of the language, and ignoring them, he could make Javascript much more powerful, secure and easy to learn. Another side effect is that it becomes much easier to write interpreters for simplified versions of the language. Douglas Crockford’s extreme subset of Javascript, JSON is so easy to learn, and such a powerful concept, that it has spread to have parser implementations in nearly every vaguely useful programming language. I think the same could be done with HTML.

In this series of blog posts I will define a simplified version of HTML that I will call KISSML. I will simplify it by not just removing things from the language, but consolidating, generalising, and humiliating as many special cases and arbitrarily separate concepts as possible. Unfortunately, this effort of mine falls short of the Crockford ideal; The domain all possible valid KISSML documents are not all valid HTML. This is because by simplifying it, I make it more powerful and expressive. In theory, a KISSML to HTML ‘compiler’ might be possible for backward compatibility (until everyone has upgraded to KISSML browsers!). For the purposes of this blog post, I won’t concern myself with the details of how that would work. I realise that redefining and rebuilding HTML from scratch has been attempted (and failed) many times before. Let me be up front about this: The big nasty complicated HTML5 with all its warts and flash plugins and horrors is not going away for a long long time. Consider this a thought exercise (but if anyone wants to actually implement this, I certainly won’t complain).

i will define KISSML in relation to HTML in terms of:

What to remove: (The Bad Parts)
What to generalise and consolidate: (The Powerful Parts)
What’s left, What it is: (The Good Parts)
And its relationship to other technologies: (The New Style)

What to remove: The Bad Parts

So what do I remove? I will start by removing all the different tag types (for now) because it is easier to start with a blank canvas as far as that is concerned. KISSML is an extensible markup syntax, like xml, However, unlike XML, there is no requirement for an outer enclosing “root” element. Removing this requirement means that KISSML can be a true markup language in the original sense of the term. KISSML is a markup language in a way that XML and HTML cannot be. The immediate practical advantage is that *this* very paragraph counts as a valid KISSML document. Without having to modify it, wrap it, add headers, or parse it, this is KISSML. Multiple KISSML documents can be concatenated directly, with no special processing. The result of concatenating two valid KISSML documents is a new valid KISSML document. You can’t do that with HTML or XML, and yet it is a task that must be done constantly. Vast numbers of web developers are living in sin! Much like banning sex or alcohol, those who would forbid naked HTML from being considered valid seem to misunderstand something fundamental about how people actually behave. It is a goal to consider *most* html fragments, as produced in the previous two links, as valid KISSML.

On that note, <head> and <meta> need to go too. I already said I was getting rid of all the different tag types (for now), but these ones aren’t coming back, unlike some of the others. Their existence is a contradiction. they are meant to define “metadata” and yet here they are inside the data. it doesn’t make sense. We have learned through trial by fire, again and again, since the web was created that trying to hide information in an html document is stupid. If you can’t see it, it may as well not exist. Users can’t see it, search engines don’t look at it, developers typically ignore it or avoid it. Browsers ignore (most) of it. Hence, it seems to me <head> and <meta> are almost completely pointless. The few things that meta tags *do* have an effect on could be achieved through better methods. <title> is visible, sort of, but there can only be one. In a multiply concatenated document, which <title> do you choose? This will be a theme: anything that prevents the concatenation rule from working is deleted from KISSML.

HTML entities. In HTML, and XML, in order to insert a special character, you must use the & followed by some special name, followed by a ;, as in : “Bill & Ted's Excellent Adventure”. Not only does this look ugly, but it also leads to two of the most frequent mistakes made in web development land. The first is using the ampersand & character without encoding it into an entity, like this: “Bill & Ted”, a mistake that leads to an invalid document, and breaking parsing software not prepared for the situation. The other mistake is made by software developers and spec authors who do not specify what their software expects from a blob of text. As a result, there is a confusion of entity encoded html, plain text, and non encoded html that gets dumped into attributes and text fields without rhyme or reason. This is a particular problem for RSS which leaves it up to software to decide whether elements contain encoded html, or plain text! Really, most of what html entities are used for should be done with UTF-8 instead. Which leads us to...

Encodings other than UTF-8 need to die. I mean that as politely as possible. Quite simply, I’m sick of seeing text encoding muckups, like apostrophes being turned into euros, and such.

Not only does the existence of numerous myriad different text encodings make files difficult to parse and display, it makes client/server interaction difficult too. AJAX in IE fails when it encounters a server that proclaims an encoding IE doesn’t recognise. Things get sticky when a page is served with one encoding, but the server requires form posts in another. UTF-8 only should be used from now on, and browsers should assume they are receiving UTF-8. That way, if things break, the vast flowchart for troubleshooting text encoding issues is reduced to just one question: Did you use UTF-8? If no, use UTF-8. If yes, someone else failed to use UTF-8. Why UTF-8? Because we’re moving in that direction anyway, and UTF-8 theoretically has no upper limit to the number of glyphs it can represent. UTF-8 is good, and you can use it to represent funny characters like snowmen, and umlauts.

Frames: Better arguments than I can come up with have been made elsewhere. Needless to say, frames need to go, but not without being replaced with something better, because the USE CASE for frames still exists. It’s just that frames are a bad solution to that use case.

The Script Tag: Surely there must be a better, more secure way of making a web-page scriptable! Remember that we’re expecting users of our sites to enter content in forms. We then take that user entered content, and display it on our sites with full privileges and abilities. The existence of the script tag, or any other way to modify the browser behaviour in the markup language itself makes securing these forms incredibly difficult. Markup should be, quite simply, markup and nothing else. Otherwise, XSS exploits ahoy!

The Style Tag: for symmetry with the elimination of the script tag, let us affirm that we shouldn’t be mixing these powerful languages in with the markup, because once you’ve spilled oil in the ocean, it’s really really hard to get it out again.

TO BE CONTINUED IN PART 2: THE POWERFUL PARTS

Cultural Matrix: C.A. 2005

2010-05-23T02:12:00.000+10:00

Cultural partical simulation

Each individual is populated with a collection of multidimensional memes. The position and color of each meme is stored in an individual's mind, which is in turn presented as an object in a 2 dimensional plane.

The goal of this is to abstract a meme into a simplified object with a position and color in a person's mind, giving color and contour to an individual's mind.

The more contact an individual has with other individuals, the more their memescape comes to resemble that of its peers, often taking on new memes, and new territories are opened in their individual memescape.

This comes with neccesary improvisational algorithms which enable each individual to assimilate sections of memescape into their own cultural matrix.

An individual will feel most comfortable communicating with peers with similar memescapes, and gravitate towards memescapes which they have found to be compatible with their own. However, depending on certain attitudes encoded in their cultural matrix, may gravitate toward diversely appearing individuals, or conversely toward similarly appearing individuals. This may also depend on the size and color of their memescape.

The effect of mass encultration on various groups may have interesting effects as well.

The overarching goal of this simulation is to produce an interesting and complex visual presentation which enables one to more simply and visually think about these complex abstract concepts.

The precise parameters of the simulation still require much development, but overal may produce an interesting emergent behavior.

Meme:
Each meme consists of a multidimensional point (the number of dimensions being adjustable, as long as it is equal or more to 2) , a color (consisting of a 3 dimensional position in a color space such as L*a*b), and a directional vector of dimensions matching that of each meme's position. A meme's vector would consist of the averaged directions of a set of peer memes selected according to a process in which an adjustable threshold is used to identify similarly colored memes. Therefore a meme would gravitate toward memes of similar color.

The peer memes selected in the aforementioned process would be connected, in addition to unarticulated rules to produce the cultural matrix

Cultural matrix:

A cultural matrix is composed of a collection of memes interconnected according to a set of rules which allows for random and intuitive improvisation. This matrix would be processed in such a way to be capable of producing a visually representable landscape. Additional rules may be made to evaluate one matrix's similarity to another's.

This is not what you think it is.

2010-02-24T00:22:00.003+11:00

The two sat together awkwardly. The memory of what happened sat ajar between them. He thought that he should stroke her hand to comfort her but he stopped himself once he realized his palms were sweating profusely. Her brow was tense, and her knees tightly clamped. "this isn't how it is in stories", she thought.

For the past 3 weeks she watched him longingly. She admired from a distance the graceful way he walked, his calming smile, the sense of gentle warmth he projected. She frequently imagined what it must be like to be embraced by him. She would never see love the same way again.

He nervously looked out the window. Hoping for a blissful end to this moment, he considered jumping out. Unfortunately, the window was stuck fast. He was recalled to what his heart felt; like a frightened sparrow beating against the glass of his chest.

Since the day she arrived on campus, he was enamoured. Her beauty was both captivating and intimidating. His excruciatingly gentle and repressed nature meant he would never feel comfortable approaching her. If he were to so much as say “hello”, he would make himself feel as though he were causing some terrible kind of violence upon the poor girl. If he were to even think of her lustfully, he would never forgive himself. Now, everything would be different.

The smell of sticky skin permeated the air. The weather was uncomfortably warm and humid. She unwillingly leaned into him as the bus turned. “how long until my stop?” she thought.

The mating habits of the christmas reindeer

2010-01-02T02:51:00.005+11:00

The ritual begins when the population of reindeer shed their summer coats, revealing the golden shimmering skin underneath. The reindeer then congregate, forming two large orbs (one male, one female). The golden orgy froths and frenzies for 12 days climaxing in a spectacular "fireworks" show in which the gendered gametes are projected from each orb at extremely high speed. The force of the collision forms a mushroom cloud, and destroys the christmas village. The new Santa Clause is formed at ground zero, which then distributes reindeer spores in multicoloured box shaped packages all around the world. Once the santa completes its jolly task, he returns to the spawning ground and melts into a highly fertile mound from which grows the first tree of the new christmas village, marking the spot to which the reindeer will return for next year's mating season.

Canvas Accessibility.

2009-12-21T10:38:00.010+11:00

There has been some discussion going on about Accessibility in the html5 Canvas Api.
You can see such discussion here:

http://www.paciellogroup.com/blog/?p=362
http://www.brucelawson.co.uk/2009/canvas-accessibility-and-svg/
http://krijnhoetmer.nl/irc-logs/whatwg/20090710#l-20
http://lists.w3.org/Archives/Public/public-html/2009Jul/0372.html
http://esw.w3.org/topic/HTML/AddedElementCanvas

In case you don't know, the canvas API provides a postscript-like drawing api to javascript running inside webpages. It was introduced by apple to provide a richer graphical experience for the "dashboard" feature introduced in their OS X Tiger.

The argument on one side seems to be that if you don't bake accessibility right into the API such that programmers don't have to do anything particularly special to make it accessible, then people just won't do accessibility.

There's the extreme position that the canvas API just should never have been added to browsers in the first place, and it shouldn't be in any standard, because it's inherently not accessible.

Then there's reactions to the extreme positions, that argue that sometimes we just need to make content that is inherently not accessible to everyone, and this is okay, and they are legitimate forms of expression. And besides, we don't ask that everyone put wheelchair accessible ramps on their houses, and so we shouldn't require every single website be accessible.

Of course there already is a simple accessibility mechanism built into the canvas tag: Simply put some plain text inside the canvas tag as fallback content. If a client doesn't understand the canvas tag, it will simply display the text content.

A counter example to that approach that is being used, and which I believe sparked the debate is Bespin. Bespin implemented a widget/gui system that runs entirely inside a single canvas tag. They did this for performance, and for control over the gui experience. Static text content is not a sufficient fallback for such a program.

Here's my opinion: It will be a grave mistake to get distracted by projects like Bespin into thinking that the canvas api's accessibility features are lacking. A widget system is only one potential use for the canvas tag, and gearing an accessiblity design around this one use case will cripple the canvas API, and ultimately, I believe, make accessibility worse for uses that are NOT widget systems.

The truth is that I don't think there's any way to know, from the perspective of a browser that is receiving canvas API instructions, precisely what the meaning of those instructions are. Yes, it could be something like bespin, or it could just be a simple animation. It could be a graph, or it could be some abstract artwork. You could ask the programmer to provide hints in the API calls, but that's not really any better than the "tack on" accessibility that the accessibility proponents speak out against. However without such hints, all you see is "Curve, curve, rectangle, image, textbox" etc. etc. No way to know whether you can interact with anything, no way to know what the text in a textbox is referring to, and no way to know what nature of image a sequence of shapes is constructing.

A low level drawing API is the wrong target for accessibility. You might as well try and make the PNG image format "accessible" by allowing a screen reader to read out the color of each pixel, or making SVG accessible by making it read out loud each curve and shape in sequence.

For bespin, what you need to make accessible is its widget toolkit. That's the level of abstraction where you have some actual useful information. That's where you know whether something is a menu or a button or a text-box. There's already a standard called "aria" that aims to make dynamic widget toolkits in html accessible. The limitation in this case though, is ARIA's assumption that you'll have some kind of 1:1 correspondence between HTML tags and widgets, and its dependance on your ability to assign attributes to each of those html tags.

I think what we really need is some kind of low level accessibility API, at a level equal to the canvas API, but not cannibalizing it, and without attempting to combine them, or make them into the same API. Then to make programmers want to use it, you need to make it useful for things other than Accessibility. Here's a suggestion:

Let's provide a low level javascript API that makes it relatively straightforward to turn your javascript program, embedded in an html page, into a command line utility, an interactive terminal program, a webservice, or even the basis for a desktop application using a native OS widget toolkit. Just add a few extra API calls, and you get to reuse your efforts in multiple and many different contexts, accessible interfaces just being one of them by chance.

What's the best way to do that? I'm not sure exactly, but I think it's a more productive direction to explore than the futile task of trying to make abstract low level drawing commands mean something to a computer: Something which I think can only be achieved via advanced artificial intelligence of the sort that is perpetually 10 years away.

My instinct is to encourage MVC style programming via the design of the in browser API for constructing applications, the same way that Apple's cocoa encourages good MVC design by simply making it the path of least resistance. This would involve encouraging programmers to build a clean "domain model" version of their javascript programs, and making it incredibly easy to express the logic of that program through rich UI's (potentially using the canvas tag), or via a command line program/interactive console program/webservice/accessible client without changing the code of their "model" tier. Go further: make a model tier simply work on its own without any gui programming. Then adding a rich gui with graphics is simply enhancement. Make this the easiest way to write a program, and they will come. Consider the analogy:

html : css :: javascript models : canvasApi

Nobody complains that CSS is not accessible. Why is that?

One thing I think we should definately not do: Standardise an "accessible" version of the canvas API that doesn't have a single implementation, and hasn't yet gone through the trials and tribulations of real world practice.

Another javascript pitfall: Hoisting

2009-08-06T18:39:00.002+10:00

The problem is that, whether you realise it or not, javascript invisibly moves all the var declarations to the top of the function scope.

so if you have a function like this


var i = 5
function testvar () {
     alert(i);
     var i=3;
}
testvar();

the alert window will contain undefined. because internally, it's been changed into this:


var i = 5
function testvar () {
     var i;
     alert(i);
     i=3;
}
testvar();

this is called "hoisting". The reason Crockford so strongly advocates var declarations go at the top, is that it makes the code visibly match what it's going to do, instead of allowing invisible and unexpected behavior to occur. function definitions are also hoisted to the top of the scope.

Putting a var inside an if statement is not against "the rules" of the language, but it means that, because of var hoisting, that var will be defined regardless of whether the if statement's condition is satisfied. Javascript also does not have block scope, so declaring a variable inside a block is doubly confusing to those who come from languages that do have block scope, because of hoisting.

Keep in mind also that hoisting does not include the assignment, so the var declarations will be moved to the top, and left undefined until they're assigned later, as in the example above.

This is a feature that must have seemed like a good idea at the time, but it has turned out to be more confusing than helpful.

Insomniac Theater, A dream

2009-08-02T01:48:00.002+10:00

I had a dream about a particular cinema. Not one that I know if in the waking world, but one that I visited quite avidly in this dream world.

At this theater, you could purchase a ticket to see a contemporary movie at around 11:30pm at the regular price. Then, you could stay at the theater on until 6am, and watch classic/old/public domain movies and cartoons for free.

The theater would recoup the cost of this through sales at the snacks counter. This might actually work, sleep deprivation can make people quite hungry.

Autodesk Animator

2009-05-08T22:35:00.009+10:00

UPDATE: New website, animatorpro.org , Source code now online.

Here's a little story about a neat old computer program, and how I plan to save it from the brink of digital death.

For the past few years I've been fascinated by this program. Way back in the beginning, I became aware of the existence of dedicated communities devoted to solely pixel art.

One of the communities, pixelation, had a highly regarded tutorial titled "so you want to be a pixel artist?"

(Links are to mirrors, the original site is long gone). When I read that tutorial was the first time I became aware of the fact that there was a program called "Autodesk Animator". The native format of Animator (fli, flc) was certainly ubiquitous in the 1990's. Even today, Mac OS X doesn't need any special software to play FLI files, quicktime handles them natively. I have also been a participant in the pov-ray community, which used independent dos utilities to string together ray-traced frames into Animator's FLI and FLC format. Why? It was the very first widely available delta compressed video format!

What really grabbed my interest, was this spectacular animation by a guy named Paul Robertson.(NSFW!) who allegedly used Autodesk Animator to make it.

So cargo cultist that I am, I set about attempting to obtain the software. This is really difficult to do, it turns out. Eventually I succeeded. (*whistles). The software can only be run on a modern computer by means of emulation. DosBox is quite capable of running the software. Here's me on the DosBox forums trying to make that experience suck less.

The software is really very much like another contemporary peice of software called Deluxe Paint. Between Autodesk Animator, and Deluxe Paint, you can account for about 90%*(making shit up) of the game artwork produced between 1989 and 1999. These were *the* pixel art programs. They belong to a class of paint program designed around the limitations of computers that can only display small amounts of colors. A style of paint program that has really fallen into obscurity ever since the photoshops of the world took over with their fancy 24-bit color modes. (oh and by the way, Dr. Katz, Home Movies, and Science Court were made in Animator, also, most of these youtube videos, and also, my cool dinosaur animation)

What sets Animator apart from its contemporaries is its direct keyboard control over animation functions, a very useful Sprite animation mode, and a built in scripting language named PocoScript.

What sets it apart from Modern paint programs is that while it is only capable of producing 256 color images and animations, it has a vast number of tools, inks, filters, and effects that modern programs cannot use in their highly crippled 8-bit modes. In addition, the functions available for manipulating that limited palette are unmatched by any other program I've seen. These properties make it ideally suited for producing art for platforms with limited capacity (such as game consoles, mobile phones, toys, etc) in other words, "pixel art". In its own time, this was thought of as a severe limitation. Today, this is its advantage- this is its characteristic difference.

Just one problem.

So, I'm going to do something about it! I had an idea. In my research, I found out quite a bit about the history of this program. I found out that before it was a PC program named Autodesk Animator, it was an Atari ST program named "Cyberpaint'. Before that it was Aegis Animator, and Flicker, and a conglomeration of other small paint programs and experiments, all authored by a guy named Jim Kent, who had a funny habit of negotating software contracts that let him keep the rights to the source code. Hmm. Interesting little story about Jim Kent. In the year 2000, he mapped the human genome using a cluster of 40 commodity PC's in his basement, Beating out a biotech firm by a day, and thus saving the technology, and our genes from patents. Oh yeah, and he likes open source software.

So I decided to email him, asking if he might, maybe, kind of, consider maybe open sourcing our favorite program. This was his response:

Oh, and by the way...

So, he kept his rights to the source code, and now, he is granting me access to the source code, to make it available to you all! Well not so fast. He also asked me to get in touch with Gary Yost to ensure that he didn't object. (Former owner of Yost Group who licensed the original software to Autodesk), Well okay, that wasn't so easy, since he's now a big shot vice president in a tiny little company called Mental Images

But I managed, and I got his support too! So now that all the relevant parties are up to speed with my idea let's go!

Hold on, though, there's some chores to do first before I can release it to the public. I know I know, blah blah blah. First off, there's a bunch of material in these little zip files which suspiciously looks like stuff that Jim Kent did not write. There's piles and piles of documentation that looks suspiciously.. .copyright autodesk. There's piles of fonts licensed from-- Anim8 inc, a company that I can find ZERO information about. (help?) and Sample artwork that I can't use, because I don't know who made it.

There's also the technical challenges. It would be nice before I release the source code, if I knew all the tools and software that it depends on, and how to compile it. It would be even better if I could adapt the code to compile with tools that are Free and Open Source, rather than tools that are proprietary, out of date, and impossible to find

So I know it's frustrating, but I'm going to have to sit on the code for a short while, so I can sort these issues out. I'm soliciting for anyone that can help with writing documentation, any artists that are willing to make sample artwork using the software, any lawyers that are willing to offer me advice on how to avoid stabbing myself in the foot, and anyone who is a particularly clever programmer that knows anything about programming for MSDOS, or is willing to try their hand at pocoscript to make some sample scripts. I'm kind of a clever cookie myself, and given enough time I can probably get a lot of this stuff done on my own, but it will take me a loooong time without help. I will detail the technical challenges in an upcoming post for those interested, and document my progress through this new project.

Something I've learned

2009-04-09T11:30:00.003+10:00

When it comes to huge complicated things like software, it is almost always better to build on previous efforts than to try to demolish those previous efforts to start from scratch.

This is best encapsulated in the following quote, via Daring Fireball

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

—John Gall

How to deal with the newspaper crisis

2009-03-19T02:05:00.008+11:00

What about a journalism "auction" site? Journalists would have accounts at the site, and post briefs on a topic of investigation. Say, a 2 or 3 paragraph abstract.

Based on this, the general public is then able to contribute: in essence, throw a pledge into a hat until a given threshold of funding is reached. This money is taken from a paypal account or a credit card until that threshold is reached by a certain date. If it is not reached, the money is returned to the users account. (or perhaps the site itself could hold virtual credits). The idea here is to collectively fund the investigation, so that no single sponsor has to bear the full cost.

Pros: Places journalists in a closer relationship with their audience. Rather than a publishing company brokering the funding between audience and advertisers and journalists, it would essentially run on a social networking or web2.0 type of model funded directly by the audience. This funding is then used for investigation and reporting of that abstract. (with allowances for the investigation leading to new interesting areas at the journalist's and editor's best judgement.)

Rather than expecting users to pay directly for content which already exists, it's giving the audience personal ownership, by allowing them select and fund the creation of new content.

Cons: The tendency for the general public to vote for baser and less enlightening stories may present a problem. Perhaps this could be mitigated by some kind of "tax" on general articles which could be directed towards articles selected by a qualified editor. That way, editors could in essence overrule the public on some portion of funding for articles to get important and educational things through- while at the same time, the general public can in essence overrule an overidealogical editor for funding on other articles, thus providing some checks or balances.

Feel free to improve expand, or implement this idea in any way you choose. I, the author hereby release this blogpost, unconditionally, into the public domain.

The emotional growth of characters

2009-03-10T13:20:00.003+11:00

Alan Moore about Watchmen:

"Watchmen" is widely regarded to have brought an aura of realism to comics.

I think that more often it's a more supposed physical realism rather than any kind of emotional realism. Yes, books like "Watchmen" did make it fashionable to show grimly the consequences of violence, which I suppose initially was a good thing because it's better that people know that violence results in terrible injury and pain and suffering than that they think that it's just something that, you know, people get a sock on the jaw and they are unconscious for a couple minutes and then they come around and they are taken off to the police station.

But I think that when you are talking realism in comics you have to realize it's an ongoing process, especially emotional realism. That when the comic book industry started you had characters who were, let us say, one-dimensional in that they only had one quality. They were good or that they were bad. By the 1960s Stan Lee with Marvel Comics had the brilliant idea of two-dimensional characterization where they are still good or bad but now they have some kind of, perhaps a medical complaint or some sort of emotional suffering. What we were trying to do with "Watchmen" was to make it at least three-dimensional. So that the characters that we were talking about were complex human beings that weren't defined by one simple set of behavior patterns. With some things like Todd McFarlane's "Spawn" or a lot of these modern comics, they will show greater violence because they know that actually that is what a lot of the audience wants, for prurient reasons, not trying to show the emotional depth and complexity of the characters.

It's occured to me that many of the characters I've seen in various fiction are incapable of growth or change. A character is concieved as a brand with a certain set of unchangable characteristics that can be exploited by the narrative again and again and again. Consider the simpsons, and their world which resets at the end of each episode to exactly the way it was at the start. None of the characters get older, nor do they actualy learn anything from their adventures that modifies their future behavior, or makes them quantifiably better people.

How would a fictional character look, if it was capable of growing and learning? What if in the process of that growth, they abandoned the main attribute that made them recognizable as that character, and that change persisted to future stories? Is emotional growth the third dimension Alan Moore speaks of?

Javascript Constructors

2009-02-16T08:44:00.003+11:00

Javascript has a problem with constructors.


function Thing () {
   this.foo="bar";a
   this.bar="baz";
}

this is okay if you call Thing as
var thing = new Thing();

That creates a new object, whose prototype is Thing.prototype, and binds that object to "this", and then executes the Thing function.

However, if you do this:

var thing = Thing();

"this" instead gets bound to the global object, and you end up with the global variables "foo" and "bar".

Douglas Crockford concieved a function named "object", that will be baked into the next version of the ecmascript standard. (as a static method named "Object.create" )

The object function takes an object as a parameter, and creates a new object whose prototype is the given object, and simply returns it. The implementation goes like this:


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

you can use this to create safer constructor functions.


function Thing () {
   var that = object(Thing.prototype);
   that.foo="bar";
   that.bar="baz";
   return that;
}

Now, this function does exactly the same as the above Thing function when you call it like this.

var thing = new Thing();

but when you forget the "new" keyword

var thing = Thing();

it still does exactly the same, avoiding global namespace pollution.

JSON xml and the relational model part 4

2009-01-24T10:23:00.004+11:00

An xml element is an unordered set of attribute names, and their associated values.

<div class="title" id="heading" lang="en"> </div>

a JSON object is an unordered set of attribute names, and their associated values.

{"tagName":"div", "className":"title", "id":"heading",

"lang":"en"}

an xml element may contain an ordered tuple of "nodes", which may be plain text nodes, or could be other xml elements.

<div class="title" id="heading" lang="en">
The Grand Adventure of <i>Lucious Swan:</i> The return of elemental qualities.
</div>

a json property may contain an ordered tuple of values, which may be primatives, or could be other objects.


{"tagName":"div", "className":"title", "id":"heading",

"lang":"en",

   childNodes:[
     "The Grand Adventure of ",
     {tagName:"i", childNodes:["Lucious Swan:"]},
     " The return of elemental qualities."
 ]
}

and that's basically all there is to it. This may appear somewhat more bulky than other xml to json translations. However, the translation preserves the unique and unordered quality of xml attributes, and the ordered non-unique quality of xml node collections. As a result, it's much simpler to implement readers and writers for this format, because there's fewer exceptions or other special conditions to account for. This is more or less a direct translation of the semantics of xml into JSON.

As an additional bonus, code written against this style of structure would work exactly the same directly against a browser dom representation of an xml document, since this is essentially a stripped down subset of the browser DOM, using the same attribute names. Most server-side XML parsers produce essentially the same structure as well.

a JSON translation into xml, using the same principles however, is not so easy...

Where does the logic go?

2009-01-22T22:54:00.002+11:00

There's a trend in data centric applications. The trend is to move more and more of the contraints and logic out of the database software, and into the application code.

The trend results from the fact that the software technology industry is populated and driven largely by humans, and thus subject to trends and irrational behavior. To understand what's going on today requires a bit of perspective in the history of databases, and their parallel development with programming languages.

SQL is the IE6 of the database languages world. It breaks many of the rules of the relational model- in other words, it's a little bit like a calculator that performs multiplication incorrectly, and doesn't have a minus operator. SQL is not complete enough to be a real solution. It was never developed beyond the prototype stage, and was never meant to be used in industrial settings. But then it was naively used by oracle, which turned out to be a "killer app", SQL became industry standard instead of its technically superior competitors, and the rest is history. SQL's syntax is based around a set of command line tabular data processing tools, and COBOL. Full of bugs, inconsistencies, and a mishmash proprietary versions and features that don't have a grounding in math or logic, results in a situation where it really is unclear what goes where.

Regarding the recent proliferation of ORMs: misguided and ill thought out attempts to patch over the obvious deficiencies of SQL. Database triggers and procedures are another misfeature trying to patch over SQL's problems.

If history had played out in a logical and orderly way, the answer to this question would be simple: Just follow the rules of the relational model and everything will work itself out. Unfortunately, the rules of the relational model don't fit cleanly into the current crop of SQL based DBMS's, so some application level fiddling, or triggers, or whatever other stupid patch is unfortunately necessary, and it ends up being a matter of subjective opinion, rather than reasoned argument, which stupid hack you use.

So the real answer is to just follow the relational model as close as you can, and then fudge it the rest of the way. Put the logic in the application if you're the only one using the db, and you need to keep all your source code in a version repository. If multiple applications are likely to use the database, make the DB as bullet proof and self sufficient as it can be- The main goal here is to ensure that the data remains consistent.

What will the future of programming look like?

2009-01-21T15:34:00.001+11:00

it will likely be a formal specification language. Instead of indicating the "how", as we do today, we'll specify the "what". So instead of saying step by step how to implement a certain algorithm, we'll specify what the requirements for our program are, and the compiler will work out the most efficient algorithm automatically.

The spec language may or may not be text based. I do not believe we will ever over come the problem of linguistic ambiguity. Even with a computer with an equal or greater intelligence to a human. Humans still misinterpret eachother. Computers will always take what we say painfully literally. this is an anavoidable, but not necessarily intuitively obvious result of various inviolable premises we hold about the operation of a computer. But higher level, more intuitive ways to state a problem unambiguously exist.

I don't think that the star trek depiction of people programming holodecks is entirely far off. It will seem more obvious and intuitive, but computers will still make catastrophic errors based around the ambiguity of natural language.

The reason I think it seems that humans can understand eachother easily in a way that computers can't, is due to shared culture, and our shared understanding that we don't always say what we mean (sympathy), and our ability to (only occasionally) continuously clarify and disambiguate our meaning. Our ability to communicate with eachother is largely the result of the common shape of our bodies, perceptions, and our ability to imagine ourselves as other people (an ability we can see more clearly when we look at those who partially lack this ability- Autistic people and Aspergers people). This enables us to understand in an extremely intimate way, why someone else may be making a specific pattern of noises with their vocal mechanisms, and gesturing in a particular way with their faces and bodies.

We only derive meaning from these patterns of behavior by imagining what we would be thinking if we were doing those things. Computers lack human bodies, vocal mechanisms, and faces, and consequently any ability to sympathise with a human. Any attempt to make a computer truly understand us without making the computer into a human itself, will be largely fruitless.

Despite all that, human comprehension doesn't work quite as well as most of us imagine it does. Consider the challenge each of us have as programmers in determining the shape of a program that client requires. It doesn't happen instantaneously. A successful program is the result of continuous revision over the course of many weeks months and years. That revision process would be very challenging (impossible) to replace with an automatic process. We can better automate the repetitive work, but we will never be able to artificially generate a perfect sympathy for our intent, artistic vision, and personal/ethical needs.

Banking on a future AI is a bet that I wouldn't make, even if it were possible. We should think just as hard about what we would lose in such a proposition, as much as we think about what we would gain.

New Paradigms in programming.

2009-01-15T10:39:00.000+11:00

In programming, I think we need more than just a new input method, there needs to be a new metaphore to go with it. It's a three teired thing. Model-Metaphore-Interface.

I've been thinking more and more lately that language is a poor metaphore for representing a computation. Language is something we use for communication. You could look at a program as a communication to a computer, and simultaneously a communication to other programmers. But there are other ways to communicate other than just the written word. I'm working on a list here, let me know if I'm missing anything.

Methods of Communication *Speech *Body Language *Gestures *Facial Expressions *Sign Language *Painting/Drawing *dials, buttons, sliders, pointing, dragging (gui)

Another metaphore for programming is building. Here's some possible ways of building functional things, that could form the basis for a programming interface

Methods of building functional things *Gears/springs and other mechanics *paper folding/cutting/gluing *patch cords *electronic circuits *hinges, ball bearings, wheels *fountains valves and pipes *Archimedes machines: pulleys, levers, screws *Lego

Yet another way of specifying a computation is by definition.

Methods of Definition *Constraints *Categorization *Set Theory *Properties *Symptoms *Logic tables *Rules *Railroads

But keep in mind why we're doing this. There's obviously some weaknesses in the way programming languages work now, (otherwise we wouldn't want to make new languages) so let's keep them in mind while we're designing our new languages

problems with current languages The interface is hidden

the apis are hidden

Side effects are a huge cause of bugs- Any part of a program can effect any other part.

Refactoring- Sometimes you find that you're repeating yourself, so you need an easy way to factor out the repetition into a macro, or a function, or some other metaphore. This is largely done by hand (or semiautomatically in java) by a massive text manipulation effort. Is there a new metaphore that would make such a thing look utterly silly?

You need an easy way to define your own building blocks, or "words" or idioms, to use to build more complex structures. Your own tools, your own parts of the environment. A lot of languages don't let you do this in a first class way.

compilers punish the programmer severely for the slightest mistake.

Variables lack a sense of time- There's no way to query the history of all the values a variable has been set to in the past. In other words, can we have a programming language where we can "rewind" the progress of our program? The fact that a variable can change, frequently to unexpected values is another source of bugs. This is the other half of the side effects problem

most programming languages have a fairly steep learning curve

Making reference to library or widget X throughout your code largely marries you to that library- Making it difficult to switch to a similar equivelent library without a lot of refactoring. This is largely to do with the fact that libraries have names, and in order to use a library, we're hardcoding the name of that library and its methods throughout our code. Is there a better way?

Poor parrallelism, multithreading leads to bugs, race conditions, deadlocks. Is there a better approach to parallelism that makes such bugs impossible?

Think beyond the computer screen people. Maybe the keyboard is the most efficient interface for entering in complex relationships and symbols. Are you sure? There are more alternatives than just a mouse, or a touch screen, or a tablet. Zillions of ways of interacting with a computer- We have just all settled on one or two rather ordinary ways.

Of computers, calculators and interfaces

2009-01-11T12:37:00.003+11:00

-4 vote down check

There is some controversy over my downvoting in this question. I will explain my reasoning by quoting Jef Raskin, the late usability expert, and originator of the macintosh project at apple.

Calculator or Computer? It's true, Many of us keep a calculator beside our computers. Why do you need this simple-minded device when you have a whole computer in front of you? You need it because you have to go through contortions worthy of a circus sideshow in order to do simple arthmetic with the computer. There you are, tapping away at your word processsor, when you want to do a division: 375 packages of Phumoxx cost $248.93; what is the price for one package? On my computer, I have to open up a calculator window. To do this, I move my hand from the keyboard to the mouse, which I use to do a click-and-drag to open the calculator. Transferring my hands back to the keyboard, I type in the numbers I need or tediously cut and paste them from my document. Then I have to press a few more keys and finally copy the results from the calculator window into my document. Sometimes, the calculator window opens right on top of the very numbers I need, just to add insult to injury. In that case, I must use the mouse to move the calculator window out of the way before proceeding. It is much faster to grab the pocket calculator.

do not think just because you are a programmer you are immune to usability issues. Using a software calculator can be a significant drain on your time, and when you're a professional software developer, time is some serious money, yo.

Jef Raskin went on to propose a solution for a better software calculator. I did not downvote those that I thought were similar enough to Raskin's solution, such as using spotlight. If you're using Textmate, textmate has a feature which is almost EXACTLY the solution that Raskin proposed, that is, you highlight a text which represents a mathematical operation, and you press the "calculate" key on the keyboard. Since most keyboards sadly lack a "calculate" key, in textmate you use control+shift+c instead. All text editors should have this feature. it is sad if they don't.

Also, his son aza made a program called enso. If you have enso installed, you can highlight a calculation, (anywhere in windows), hold down the capslock key and type "calc", and it will perform the calculation, replacing the selected text with the result.

the quote continues

Using an experienced computer and calculator operator as my test subject, with his word processing program open before him, I measured the total time it took for him to pick up a calculator, turn it on, do a simple addition, and return his hands to the keyboard to resume typing. It took about 7 seconds. I then measured the time it took for him to use the built-in calculator. He had to move the cursor to the menu bar at the top of the screen, find the calculator program, open the calculator, enter the sum, and then click back in the word processor so that he could resume typing. This took about 16 seconds.

Comments:

I could say the same thing for an actual calculator. I have to take my hand off the keyboard/mouse, find it, get it out, remove it's cover, turn it on, etc. It is a non argument. Also, that isn't how I open or use the windows calculator. My hand never touches the mouse. – Simucal (Jan 7 at 4:10)

In Vista: Windows Key-"calc", enter. Proceed to enter your calculations using the numpad, never removing my hand from the keyboard. – Simucal (Jan 7 at 4:11)

It's a non argument if you only decided ahead of time that the quote is wrong, and thus only bothered to read until you thought you had enough material to attempt to discredit it. It's a much better argument if you read the whole thing and actually spend a minute or two thinking about it. – Breton (Jan 7 at 4:18) [remove this comment]

But this is my own fault for pissing you guys off before I posted the quote. Read it on its own merits, not because you think I'm an asshole. – Breton (Jan 7 at 4:19) [remove this comment]

@Breton, I read your whole post. What you fail to realize is Jef Raskin's solution is a solution to a problem that doesn't exist. Launching a calculator from the keyboard is so stupidly simple that is a non-issue. Ensu style highlight/calculating is nice but I don't see it as a killer feature – Simucal (Jan 7 at 5:24)

You're focusing on the launching, and ignoring all the other issues that jef raskin brings up, such as windows obstructing your view, application switching, and the manual task of copying and pasting the result, which is actually more significant than just typing in the result from a visible display – Breton (Jan 7 at 5:41) [remove this comment]

This ignorance is what has led me to believe that you didn't, and you still haven't properly read the whole thing. – Breton (Jan 7 at 5:42) [remove this comment]

can you remember the hotkey combination for your calculator, and then press it? Can you do that faster than you can pick up an object off your desk? Are you sure? perception is a tricky thing when it comes to keyboard shortcuts. Try it with a friend and a stop watch. – Breton (Jan 7 at 5:47) [remove this comment]

+1 for a thought out responses that I think is wrong. I can't think of anything that a hand held calculator can provide that a software one can't. Also I just did the test as described at the end: 3 sec using the windows calculator. – BCS (Jan 7 at 7:21)

Re the other issues: alt-tab or enough screen space gets you past the calc over the data issue. -- All else aside the OP asked for a *programmers* calculator, anything that isn't simple math (a.k.a. anything that would be special to programming) I wouldn't use a calculator (either kind) for anyway. – BCS (Jan 7 at 7:27)

@BCS software can do anything. I can't think of anything a hardware calculator can do that a software one can't, aside from be a physical object (has advantages). But it depends on the calculator. As I said before, I didn't vote down software solutions that I thought were decent enough. YMMV. – Breton (Jan 7 at 7:49) [remove this comment]

And worse comes to worse, we're programmers. If we needed something specific out of a software calculator, surely we'd make our own? – Breton (Jan 7 at 7:49) [remove this comment]

You downvoted a whole slew of people because you were convinced by some theoretical article that there is only ONE TRUE WAY? And now you're surprised that people don't like you? Oh, and btw, that ONE TRUE WAY isn't in my environment so...what? I'm out of luck? You must be very popular at parties... – mdbritt (Jan 7 at 16:51)

I wouldn't count an article based on a set of facts and measurements as theoretical. Make your own conclusion from the premise, but you can't make your own premise. I'm not surprised that people downvoted me. people don't like to be criticised. I'm not particularly popular at parties. I don't mind. – Breton (Jan 7 at 21:43) [remove this comment]

@Breton: I'm not one to criticize the late Raskin unless necessary, but understand WHEN this piece was written, vs. today's world. Many modern programmers have the ability to launch their calculator quickly, have it not obscure the text beneath, and be done. (ctd next comment) – John Rudy (2 days ago)

I can do all of that on Vista way more quickly than I can even FIND my real desk calculator. :) Yes, the OP did want a physical calculator -- his choice -- but that doesn't make sense to most others here, and those opinions are perfectly valid. (As is yours; many of us simply disagree with it.) – John Rudy (2 days ago)

It was written in 1999-2000. Computer interfaces have not changed significantly since then (aside from the introduction of OS X). Quite a lot of people still have calculators next to their computers. all the commenters seem deaf to the phrase "I didn't vote down all the software solutions". Oh well. – Breton (yesterday) [remove this comment]

@Breton: I read that part, but understand even the difference between 10 years ago and now. Modern large screens and massive display real estate is a major change for most of us. In 1999, I felt lucky to have 1024x768 -- at work now I have 2560x1024 on two monitors ... No obscuring via soft calc. – John Rudy (yesterday)

And I keep one on my desk, too. But I can get to the software one WAY faster. What I'd LIKE is a good programmer-oriented sidebar gadget calculator -- completely solves all the issues Raskin mentioned by being always visible. – John Rudy (yesterday)

Most of us actually don't have high res screens like you. But even if we do, I think it's a mistake to count more resolution as "more real estate" without taking into account physical dimensions. more space doesn't solve the problems. May be matter of taste, but if you're used to tasting shit... – Breton (yesterday) [remove this comment]

The point is that "More screen realestate" is just a bandaid. The problem is with the concept of an application window. I could go into more detail, or you could just read the book. – Breton (yesterday) [remove this comment]

The concept of the application window? Now I'm curious for the more detail. If you have something like a Vista Gadget -- always visible -- it obscures nothing, and all that is required is a focus switch. Using a handheld calculator is fundamentally the same -- move hand, switch focus, go back. – John Rudy (11 hours ago)

(And why is screen real estate a band-aid? I get it if you're at 1280x768 at 13" -- as I am on the MacBook I'm typing this on -- but in the Windows world, it seems like 96dpi is moderately standard. Yes, I'm cross-platform.) – John Rudy (11 hours ago)

There's a big difference between switching "focus" on a computer, and switching your mind's focus onto a different object. One requires the operation of a mouse/keyboard, and the other doesn't. in raskin's THE the app window is applauded as a huge step forward, but fundamentally unable to support... – Breton (2 hours ago) [remove this comment]

The number of simultaneous tasks, and the complexity of those tasks that we have nowadays. The problem with app windows is that they represent a modal interface. windows cause the meaning of specific gestures to change arbitrarily. This is harmful to habit forming. It's also the reason vi is so hard – Breton (2 hours ago) [remove this comment]

Switching focus from the computer to a calculator is a natural kind gesture that we're evolved to do. Gestures against the calculator always lead to the same result. We can form habits around the operation of the calculator. Using a software calculator means that we're pressing a set of keys to ... – Breton (2 hours ago) [remove this comment]

changes the meaning of another set of keys, then making our calculation, then using a third set of keys to change the meaning of the second set of keys back. We can't form habits around that second set of keys, because gestures against them don't always mean the same thing. – Breton (2 hours ago) [remove this comment]

While habits are possible to form under such conditions, it's difficult because our expectations are often violated. The situation is worsened by the fact that the first set of keys and the third set of keys probably also change their meaning quite frequently. – Breton (2 hours ago) [remove this comment]

For this reason you really want your calculator built into whatever ide/texteditor etc that you're using, if you're going to go with a software solution. This reduces the number of mode changes you have to make in order to do a calculation. Gestures retain their meaning. – Breton (2 hours ago) [remove this comment]

I'll throw in one more thing. Modes also have the problem of communicating to the user which mode they are in, and when you have switched modes. This communication usually fails because the user is focused on the task at hand, and not on the mode indicator. – Breton (2 hours ago) [remove this comment]

In raskin's solution, the number keys retain their meaning- That is, they cause a set of numbers/operators to appear in sequence in your text document. Highlighting some text and pressing the "Calculate" key is a single gesture which always retains its meaning. No modes. – Breton (an hour ago) [remove this comment]

raskin's THE also has a chapter on what he thinks is wrong with modern programming environments, and how to fix it. If you're a programmer, it's well worth the read just for that chapter. – Breton (an hour ago)

Why did I write the web school awesome articles?

2008-12-11T22:54:00.002+11:00

I was doing courses for graphic design, and doing fairly well, I suppose. I originally went into graphic design in the year 2000. While I had a talent with computers, I wanted to avoid all that cross browser crap and just make pretty printed things. Paper doesn't have cross browser issues! So I spent 6 years learning how to do that. But the thing is, there's no escaping one's natural talents and obsessions it seems.

I accidentally got really good at making web pages. I didn't really want to, it just happened. I got way better at it than my peers in the graphic design courses. I ended up with a reputation. I found one of my typography professors taking a "web design" course that I'd taken in a previous semester. While that was amusing, it didn't last long. He commissioned my services to teach him the craft, and so I did what I could.

A couple years later me and all my graphic design friends ended up in a different university together. That was weird, especially since it was full of zombies. And a couple unicorns. Seriously. Then they all decided to take a web design course at this university. I later found out that what the university meant by "web design" was "make a flash movie and hastily slap it in the middle of an html table, then maybe publish it online if you can figure that shit out".

So I got a bug up my ass about that. I couldn't help it. That sort of thing just bothers me. It really shouldn't bother me since I'm just trying to be a graphic designer and make pretty printed things. But the idea of all my friends putting these opaque unfriendly singy dancy binary blobs on the internet really stuck in my craw. And I think someone else was having trouble with web things or something and heard that I was good at it, I don't know. One thing lead to another, and I wrote the webschool awesome articles. I combined it with one-on-one tutoring. It all fell off a bit as I never got to lesson 3 (which would have included some css), but oh well. Then I imploded and moved to australia.

Skip forward a couple years and my teenage nephew is having some kind of identity crisis (happens to all of us). I offer to teach him some web things, and he thinks it's a good idea. So I dusted off WSA and posted it to my blog for his benefit. I meant to get to lesson 3 some months back, but as you can see from this blog.. I'm full of ideas, and not enough experience/wisdom/ability to get them all done and real.

Web School Awesome: Lesson 2

2008-08-03T10:19:00.006+10:00

Web School Awesome: Phoenix Edition

Hey kiddies, here's another round of punishment from your good friend, Breton "Insano Smartypants" Slivka. I'm gonna lay it all out for yah.

In excercise 1, I showed you how to create a basic html file, and open it in a browser to see the results. I showed you 5 types of html tag. In this lesson, the goal is to fully mark up a page of text. I will show you how to create:

Subheadings

paragraphs

lists

hyperlinks

anchor links

images

special characters.

bolding and italicizing text.

In order to accomplish that, I've got a starting point- a page about a band called the nips. I'm providing two files, one called thenips1.html and another called thenips2.html. This goal of this lesson is to step by step, modify thenips1.html until it's just like thenips2.html, and all along the way, observe the effects that our changes have on the way our page looks in the browser.

The first step is to properly set up a workspace.

in your web school awesome folder, create a new folder named "Lesson 1"

Linked from this blog post are a number of files. You're going to need them all. Save them in a convenient folder.

Print out "lesson2.txt" so you can follow along. The lesson continues in that file.

Arrange your text editor to occupy one half of your screen, and your favorite web browser to occupy the other half.

Follow the instructions in the previous lesson for saving out an html file, and for opening in a browser.

When you make a change in the original file, simply SAVE the change, and press the refresh button in your browser to see the results

the files:

Lesson2.txt
nipsy2.jpg
thenips1.html
thenips2.html

Web School Awesome

2008-08-03T01:27:00.001+10:00

Webschool Awesome Lesson 1.
REMOTE E-LEARNING EDITION

HTML 101
________

Okay guys, this is where your uncorrupted and untouched knowledge of html will come in handy. Too many lessons and teachers will teach you how to go making pages the wrong way. Since nobody has done that to you yet, I can teach you the right way, and you don't have to unlearn a bunch of bullshit. (if I haven't told you by now what I mean by "the right way" and "the wrong way" you can go ahead and ask me.)

How Web School Awesome works is I tell you how to do something, and then I tell you what happened. This way by the time I start talking theory, you have already experienced the practice, and thus know what I'm talking about already.

Exercise 1: your first web page.
This one is EASY, has only 5 steps, and it will take you 10 minutes, tops.

Tools needed:
a computer (mac or pc will be fine)
A web browser. (I prefer firefox or safari, but any one will do for this lesson)
A text editor. on the PC, use notepad. On a mac, use textedit.

STEP 1.
Make a new folder called WSA (it stands for Web School Awesome)

STEP 2.
open up your text editor of choice.

STEP 3.
In your new document, type in the following text: (don't copy and paste!)

<html>
<head>
<title>Web School Awesome Rocks!</title>
</head>
<body>
<h1>Web School Awesome</h1>
this is my first web page ever. SWEET!
</body>
</html>

STEP 4.
Save as plain text, with HTML as the file extension.
It is important to know how to save as PLAIN unformatted text. So pay attention to this bit.

How to do this on a MAC with TextEdit:
Click the "Format" menu and select "Make Plain Text"
Click the "File" menu and select "save"
navigate to the WSA folder.
next to "Save As" type skeleton.html as the filename
in the "Plain Text Encoding" pull down menu, select "Unicode (UTF-8)'
click "save"
a pop up dialogue will ask you whether you really want to use .html as the extension. Click "Use .html"

How to do this on a PC with Notepad
click the "File" menu and select "save"
Navigate to the WSA folder
next to "File Name:" type "skeleton.html"
in the pull down menu "save as type" select "all files"
in the pull down menu "text encoding" select "utf-8"
click "save"

STEP 5.
open the results in a web browser. You can do this by using file>open on most web browsers, or simply drag the skeleton.html file's icon directly into your browser's window.

What you should see is "Web School Awesome Rocks!" in the TITLE bar of the browser.
"Web School Awesome" in large type at the top of the page.
and "this is my first page ever. SWEET!" in small text at the bottom.

WHAT HAPPENED?

Let's look at the content of our file again.

<html>
<head>
<title>Web School Awesome Rocks!</title>
</head>
<body>
<h1>Web School Awesome</h1>
this is my first web page ever. SWEET!
</body>
</html>

note that in the file where it says "Web School Awesome Rocks!", to the left there is "<title>" and to the right of it, there is "</title>". These two html tags tell the web browser to put the text between them, into the browser's title bar! <title> is an opening tag, and </title> is a closing tag (because of the forward slash). All together <title>Web School Awesome Rocks!</title> is an "element".

There's 5 elements in skeleton.html. They are all nested inside eachother, like a box full of boxes. Also like boxes, there are different kinds, and the different kinds hold different sorts of things.

the first is <html> .... </html>, and it's the biggest box, and it contains all the other boxes. Always.
the next sort of box is <head> .... </head> Inside this box you put information about the web page, like its title.
then in <title>.... </title> (which goes inside <head>) well, for the third time already! you put its TITLE!
<body>...</body> goes outside of <head>, but is still inside <html>. Inside <body> you put everything you want to show up inside the actual browser window.

and finally, <h1>...</h1> is a box for headers! That's why the text inside of it is rendered really large by the browser. That large serif font is the default style for text inside <h1> tags. When I teach you CSS, you'll be able to change how <h1> tags are rendered to whatever font, size, or color you want! You'll even be able to replace it with an image.

note: <h1> is just for first level headers. There is also <h2>, <h3>, <h4>, <h5> and <h6>, for progressive levels of sub-headers.

IN SUMMARY:

<html> contains the whole document
<head> contains information about the document
<title> contains the title of the document
<body> contains the content of the document
<h1> through <h6> contain different levels of headers for the document.

There are many more different kinds of "boxes" "tags" "elements" or whatever other euphamism I've used to refer to them. I will cover more in excercise 2.

Until then, Be seeing you....

Relational Model; Ur doin it wrong.

2008-03-27T15:24:00.003+11:00

Databases: did you know that if you follow the convention of naming columns that represent the same things, with the same name (for instance, part id's named Part_Id in all tables), then you can use the SQL keyword "NATURAL JOIN" to join two tables, without having to add a bunch of "where partid=id" style clauses to your query?

Before, ( in psuedo SQL): SELECT PARTS.ID, PARTS.NAME, PRODUCTS.NAME FROM PARTS JOIN PRODUCTS WHERE PARTS.ID = PRODUCTS.PARTID

After: SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME FROM PARTS NATURAL JOIN PRODUCTS

Let me put this a different way: If you're following a poor naming convention, you're making your SQL queries longer and more difficult than they need to be!

Well, suppose we assume that everyone follows the "Same thing=same name" convention. Then SQL could potentially assume that you mean NATURAL JOIN by default when you say "JOIN".

SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME FROM PARTS JOIN PRODUCTS

Well, now that we have that assumption, I can't think of a situation where you would need to mention more than one table in a query, if you weren't joining them. (can you?). So let's assume that whenever a query contains the names of more than two tables, you mean to join them. It'll join on likenamed columns automatically, and you've just saved yourself a whole lot of trouble.

SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME FROM PARTS, PRODUCTS

in fact, why do we need to mention the table names twice? Once in the select clause, and again in the from clause. We already know which tables these fields are from!

SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME

We also know that the PRODUCTNAME field can only be found on the products table, and that the PARTNAME field can only be found in the PARTS table, and that the column that they both have in common is the PARTID column, so that's where we can join. So simply by examining the schema, we can get most of this information ourselves. So ultimately all the database really needs from the user to perform this query is

SELECT PARTNAME, PRODUCTNAME

But aren't most queries going to be a select? We can optimise this even further by assuming that the user means select unless they say otherwise. Just don't name any of your columns "INSERT" ;)

PARTNAME, PRODUCTNAME

Wow. So my thinking is that SQL is asking way more from the user than it really needs to perform a query- As long as the schema follows a very common convention which is best practice anyway.

We went from this:

SELECT PARTS.ID, PARTS.NAME, PRODUCTS.NAME FROM PARTS JOIN PRODUCTS WHERE PARTS.ID = PRODUCTS.PARTID

and through our optimisations went to this:
PARTNAME, PRODUCTNAME

Admittedly, there's a lot of little gotchas which I haven't covered in this blog post, but none of them are insurmountable, and surmounting them is well worth the time and effort saved by from typing all those big confusing SQL queries! Also, I have only covered the most basic of queries. There are ways to optimise the more complex queries as well.

In conclusion, SQL sucks, and we need something new, and something better designed.

Live Robot Walking; Another AI thought.

2008-03-22T20:25:00.004+11:00

Lots of people have tried and failed to make robots walk upright on two legs. Those that have succeeded, made a robot that walks stiffly, and rather unnaturally. What makes me think that I can do better? I have no idea. In fact, no, I can't. But at the same time, I can't help but have ideas about how I would tackle the problem.

Because while it's apparently difficult to make a physical robot walk, I have seen a number of computer physics simulations where a simulated spring based robot seems to have no problem walking. It's possible, even if the simulations cheat to make it happen.

This is how humans walk though, in a sense. We have in our minds a physics simulation, with a simulated image of ourselves within it. Before we're able to walk as children, we simulate countless times the image of ourselves walking. We attempt to walk, and compare the results to our physics simulation, and adjust our image of physics to closer match reality. In fact, we may even adjust our image of ourselves, and the weight, length and size of our limbs to try and match the results that our senses have delivered to us.

I think to make a robot walk it needs a few things: the program controlling it needs a simulation of the robot's body configuration, and its environment. The robot needs some sensors, such as an accelerometer, to deliver to the program its physical orientation, and the configuration of its limbs. An attempt at walking must be made, perhaps random at first, and the results of an attempt must be compared to the results of the same attempt in the simulation, and in particular the simulations simulated sensors.

Then the physical simulation can be adjusted such that the simulated sensors match the results of the real sensors. Then multiple simulated attempts at walking take place, until something resembling a successful walk is achieved. It is then attempted in the real robot, the results are recorded and fed back into the simulation. One might use a number of different methods for getting the physics simulations to match the results of the real robot: Genetic, Neural network, etc. But the fact is, the more data one can get about the results of the real physics, the closer one can get the simulated physics- AT least, for this one domain: Walking.

I don't know how many iterations of practice, and real attempts it would take to make a robot walk. But research has shown that this process of repeatedly imagining ourselves doing a task, does considerably speed the time it takes for a human to aquire this task. So it stands to reason, that simulating this process in an AI, for a robot may have the same effect.

Atari Nostalgia

2008-03-20T12:33:00.002+11:00

I've been on a kick of nostalgia lately. It's very strange, 1970's nostalgia. What's strange about it, is I was born in 1981, so why on earth should I be nostalgic? Well, It's not really that I'm nostalgic for the 1970's so much as I'm fascinated by the distorted world depicted by advertisements and movies from the 1970's. There is a very recognizable design Aesthetic. Particularly in the videogame systems, and advertisements for them.

Wood panelling, huge metal switches, trapezoidal shapes and angles. Black joysticks, rounded corners, big red round buttons. Big round friendly typeface. It's got one foot in the 70's and one foot in the 80's. There is a very certain and recognisable design language bound up in the Atari 2600. It has a strange effect on me that I can't describe. The sort of warm fuzzy effect something can only have on you if it formed a central role in your early developing childhood. I can remember with some fondness centipede, pacman, space invaders, missile commander, pitfall, and others.

Because the atari 2600 has a design language, it means you can speak the language in art and design, and reproduce it in new works. You could make a room, for instance, that looks like an atari 2600. The grated wood paneling along the walls, trapesoidally angled shelves, big round metal switches for the lights, labelled with that friendly round bauhaus inspired typeface. stained glass windows with big blocky shapes and primary colors. Black furniture with rounded colors, and recliners activated by big round red buttons.

You could make a TV in the same language, with an integrated atari console, all bound up in what might have been thought of as the pinnacle of gaming in 1979. Have a look at the earlier Atari consoles- They have some extra switches, additional to "power" and "reset". There was also "Game A <-> Game B" and "Difficulty Level: Hard, Medium, Easy". They give a sense of modularity and uniformity in the games that was never realized in the actual software. But what if it was? What if games continued along those same lines of thought? What if a sequel console to the atari featured not just those switches, but also two cartridge slots?

Two cartridge slots? What would that mean? Well, perhaps it would finally give meaning to the "Game A <--> Game B" switch. But what if you plugged in two cartridges and it combined them in some way? The rules of one game's character being applied to the other game's mechanics and levels. Or the colors from one applied to the backgrounds to the other? Or maybe they'd be played split screen, with player one playing game A, while player 2 plays game B. If there's no player 2, perhaps player 1 plays both games simultaneously, her controller input being fed into both games at once.

Maybe instead of split screen, they are overlayed?

Maybe the atari has more switches. Aside from game difficulty, you're also able to swap out things like graphics sets, or fine grained control like paddle size ( As you can configure in some modern pong games).

It's a world that never existed, because it can't work in reality. But it can work in a painting or a sculpture. A whole parallel world of gaming, a pathway we never went down. What if we explore it now?

Funny obsessive ideas

2008-03-15T01:55:00.003+11:00

Video game AI constructed from an adapting Stochastic Matrix. The matrix would encode N states- however many situations one wants the AI to be aware of, and M state transitions- The actions that the AI would take given that situation. A random state transition is chosen weighted according to the stochastic matrix probabilities. If the state transition results in success, then the weight for that transition's weight is incremented. If it results in failure, all other transitions are incremented instead. it may be possible to trace back a decision path several steps, and increment several of the transitions leading up to the success or failure.

It may also be possible to do that by stating that several previous conditions constitute a single "state".

The player's behavior can be observed to produce a stochastic matrix as well, and AI behavior could be an average between the computer's own learning, and observing the player.

I'd like a program that analyzes a body of text, and highlights words and letters depending on their relative probability. This would help spot errors in esoteric texts.

I would also like to use stochastic matrices for compression of text. If a run of text conforms to the predictions of a stochastic matrix, then one can specify a character of text by the rank of its prediction. That is, if presented with the digraph Th, the matrix would predict "e" as the most likely letter to occur, and thus encode e as "1", a as the second most likely choice, would be encoded as "2" etc. I haven't tried it, but my hope is that this would produce encodings along the lines of "111111111211121113211111111211132111111311112" Not only can encodings like this be very efficiently run length encoded, but if the predictions stay below low powers of 2, each character needs significantly less than 8 bits to encode it!

Another dream I had

2008-02-24T09:16:00.003+11:00

It was another school regret dream, with a few massive Dalek invasions thrown in. (my my, the panicky crowds of people scrambling to get away!) But it had a couple decent ideas for paintings.

Choose a book, paint a fictional landscape based on that book. But paint it flat first, just flat colors as the sketch.- Then paint it onto an image of a book, such that it appears like the landscape is extending out of the book- 3 dimensionally. Kind of like a pop up book. The process is to copy the flat sketch onto the book first- and then project the dimensional extension out of that.

The other project was kind of strange- It had to do with fictional pop culture characters placed twice across a cloudscape. (Alphred E. Newman, The Simpsons) One pose is large enough to see facial expressions, the other small enough to see body pose. The challenge is to compose it all into a single painting.

I'm not quite sure what the educational purpose of either of these projects were meant to be, but for some reason I felt quite guilty about not being able to do them properly. We'll see about that.

Bouncy Pixelly Creature

2007-12-20T22:18:00.000+11:00

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.

2007-12-04T10:46:00.000+11:00

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

2007-11-11T08:08:00.001+11:00

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

2007-11-11T08:04:00.000+11:00

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

2007-09-22T22:18:00.000+10:00

JSON, XML and the Relational Model part 2

2007-09-18T15:58:00.000+10:00

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

2007-09-17T23:45:00.000+10:00

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.

How I revived the semicolon

2007-09-14T23:44:00.000+10:00

I was searching my own name in google, (as I often obsessively do), to see what the e-world thinks of me. Just as a lark, I searched a common misspelling, and found someone on del.icio.us that linked to a post I made to a mailing list. This was the post, and reasoning that influenced David Heinemier Hannson, to use semicolons in the urls of his popular Ruby on Rails framework. Since David is one of what they call "The Alpha Nerds" on the interwebs, this is kind of like the uber nerd version of someone like Bruce Lee deciding that aviator hats are a really cool idea, after having a deep philisophical conversation with me. And then all the other martial arts experts proceed to comment "Bruce Lee is pretty cool, but what the fuck is with the aviator hat?"

so that I may bask in my own glory and personal brillliance, I give you, the people who haven't given up reading in frustration, the post that will ensure the semicolon's place in your browser bars for years to come:

It would seem that my discovery of a rarely used aspect of the HTTP
url scheme, namely the semicolon ; has led to perhaps a level of
unjustified excitement and advocacy. Intent is very difficult to
gleam from carefully reading a spec, despite, or perhaps because of
the high standards specs are held to for preciseness and lack of
ambiguity, which encourage a sort of unnatural writing style which in
all honesty is hard to read and easy to misinterpret. That aside, I
have a question after reading a set of documents by Tim Berners-Lee,
which are more geared toward the intentional side of things rather
than the specification side of things, which you will find here: <
http://www.w3.org/DesignIssues/Axioms.html >

Regarding the issues I'm concerned with, this is my interpretation of
the document, and you can tell me whether it's incorrect or not:

*For REST, it is mostly important that GET have no side effects, and
anything which does have side effects be implemented with POST (or
mail).

*forward slashes, as mapped to unix heirarchical structures are used
merely as a matter of convenience, and due to the principals of
opacity, are not neccesarily significant to the resolution of a URI,
except regarding the resolution of relative URI's in which case, such
interpretation should be defined per URI scheme, with client support.
Forward slashes do not indicate a resource, but the entire URI
indicates the resource, and it's entirely up to the server how to
find that resource based on the URL. No procedure for internal URI
resolution is explicitly defined.

*That http defines such a scheme for resolving relative URI's for /
style urls, but not yet for semicolons as indicators of parameters
(though TBL provides such a scheme as a possibility for implementation)

*Therefore, virtually any symbol, including but not limited to
forward slashes and semicolons can be used for the purposes of
mapping to arbitrary data topologies, at the discretion of the URI
scheme designer, which can be interpreted and resolved by the server
in whatever way is appropriate. In addition, a great deal of this
flexibility is left in the http scheme to be used at the discretion
of server programmers. As long as opacity is observed, and URI's
remain idempotent nouns.

*To this add the additional constraint given by roy fielding that
this can only be done as long as the nature of the URI scheme is
clearly communicated by the server to the client. In other words,
there is no assumption made that the client will be able to infer a
URI scheme from a base URI without explicit communication that such a
URI scheme is in use.

*Notable exception is the # fragment identifier which is reserved for
use by clients, and to be defined when registering the mime type for
a document.

*TBL then demonstrates the flexibility of URI's by laying out his
Matrix URI scheme, that is using the ; and = symbols to specify a
matrix information space, which is distinctly incompatible with a
heirarchical space. This does not imply that ; has any inherent
meaning relative to the REST or uri model, but as a scheme designer,
TBL is using it to represent a type of information topology being
made available by a server.

If one is to take all the above statements as true and accurate
interpretations of REST, then solutions to certain problems become
available, which are not possible, or are awkward under a naive
surface impression that REST requires URLS to contain only forward
slashes / to represent information topologies. It is beginning to
look to me that this impression has more to do with Aesthetics, and
search engine technologies, than any specific requirements of REST.

A problem this interpretation potentially solves, for instance, is
that of multiple views of the same information resource. Usually,
this would be accomplished through content negotiation. However this
is only effective if your multiple views all have distinct mime
types. If you have for example, a resource such as < http://
example.com/blog/posts/53 > representing an article on a blog, you
may have a non editable view, and an editable view.

In an ideal world this sort of thing could be specified using a
fragment identifier, such as < http://example.com/blog/posts/53#edit
>, however for this to work on a practical level, it requires client
support which is not likely, and somewhat incompatible with the
fragment identifier scheme defined for html/xml

Another option is to use the forward slash < http://example.com/blog/
posts/53/edit >
However it seems logically innacurate to state that a view is a
hierarchical child of the resource, rather than something more
lateral, or directly related.

If the bullet points above are accurate, then it becomes possible and
reasonable to use a semi colon, or any other appropriate symbol to
represent a lateral space, such as a view. Matrix notation seems
appropriate, since such a view system can be seen as a "matrix" (or
tensor) with 1 axis, and english words representing named points
along that axis.
< http://example.com/blog/posts/53;view=edit > < http://example.com/
blog/posts/53;view=display> < http://example.com/blog/posts/
53;view=hatom>. This makes sense to me as viewing a slice or
subsection of a single resource, which includes multiple possible views.

The caveats being how relative URL's are resolved by clients, whether
the server supports this level of flexibility, and whether
appropriate mechanisms are employed for informing the client of the
URI scheme in use (such as hrefs along all points on a matrix
allowing navigation)

This may be overintellectualizing a simple problem, but the main
purpose of this post is to verify if I have my bulleted
interpretations correct, otherwise my conclusion may be false.

Online color schemer.

2007-06-13T16:35:00.000+10:00

Okay, there's hundreds already, but they all miss the point a bit. A color has three perceptual attributes, Hue, Lightness, and Brightness, (Or HSV, HSL, etc etc)

The majority of the online color schemers only harmonize ONE attribute, Hue, while either ignoring the other two, or leaving it at the whim of the user.

Another thing online schemers ignore is the PROPORTION of color to be used. A color scheme that works for 3 equally distributed colors, is different from one that works with one predominant color, or two predominant colors. The way an accent color works is decidedly different from the way a body color works, and color schemers ignore this as well.

Most color schemers ask for one color, and harmonize the rest based on that. Well what if I have two colors! A client has two colors that must be used, how do I harmonize off of that if I can only input one color?

Okay so I could just ignore the color schemer programs, and do the whole thing by eye, right? That kind of defeats the purpose of these programs existance does it not? Why make them or have them, if in the end they are completely useless?

Todays idea is, a color schemer that isn't a sack of shit.

What is Design?

2007-06-01T09:34:00.000+10:00

This is one of those ideas that is not just a "cool idea", or something that I just have a random kink or obsession about. This project would be genuinely useful to me. Enough that I have seen other designers do exactly the same project, design organizations, such as AIGA, and others.

The problem essentially is that most people really don't understand what graphic design, or design in general is, or what its value is. It also happens to be these very people who would benefit most from design.

What I need, as a designer, is a booklet, a manual, or something that is easy to read, well designed, and not only explains why design is a valuable thing, but demonstrates it in a clear and obvious way.

It perhaps shouldn't go into too much detail about how to design something, but through popular examples.

For instance, the most obvious example is the iPod. Now, hindsight is 20/20 of course, but according to the logic of those who don't understand design, the iPod should have been a failure. The iPod wasn't the first mp3 player. It wasn't even the first hard drive based mp3 player. It was more expensive than other music players when it was first released, and still is. In terms of hardware, it doesn't have as much capacity as other players, and didn't when it first came out. It doesn't play as many formats as some. The iPod was even the last digital player to play videos. About the only obvious advantage it's had is that it's slightly smaller than the others. If you look at it in these terms, it's a complete mystery why the iPod has been such a success.

There are other examples too. The branding for chipotle, the architecture of their restaurants. Starbucks, flckr, and others. With no obvious advantage over competitors in a purely statistical standpoint, it's clearly the superior design which gives these companies the win.

There are smaller scale examples too. The clarity of communication in a sparse design which makes good use of negative space, vs. a crowded design which sees empty space as wasted space. The direct financial benefit that comes from designing an ecommerce site to channel viewers into becoming buyers- Design has a direct and real relationship with conversion rates in this arena.

Design is important, and it's not always easy to explain why verbally. A handout for potential clients would be invaluable.

City Paintings

2007-05-15T14:35:00.000+10:00

Series of paintings, 8x2', divided into 16 1x1 quandrants. Huge project, one of those ridiculously complex ideas.

Essentially each painting would depict a street in the Melbourne CBD..

So, one painting would be "Flinders Street", another would be "Collins Street", another would be "Bourke Street". Each street is exactly 8 blocks long, so each block would map to a 1 foot long section in the painting.

The painting would depict a street level view, with the street running horizontally down the middle of the painting, the north side of the street sitting rightside up vertically on the upper half, and the south side of the street upside down on the lower half.

It would have a very flattened perspective.

Once I finish all the CBD streets, I may then tackle gertrude street and smith street. Who knows, Maybe Colfax is next.

Wanna make your own videogame?

2007-05-03T19:38:00.000+10:00

The 6 Indie Mistakes

this article really sums it up. Have an idea, and want to see it become real? Prepare to work really hard for it. The bigger the idea, the harder you must work.

Particle Mosiacs

2007-05-01T20:11:00.000+10:00

Take 1 photo. Add a particle simulation. Add a particle to the simulation. Watch as this single particle floats around the screen. It is attracted to bright areas. It looks at its immediate surroundings, and locates the direction in which it will find the brightest pixels, and it goes in that direction. As it does so, it gobbles up the light, and adopts its color. As it gobbles up the light, it grows in size, until it settles into a position in which it cannot move to an area which is any brighter than the one it's already found.

Add another particle. It behaves much the same as the last particle, except that it cannot occupy the same space as the previous particle. It is repelled by its presence.

Add another, which behaves as the previous particles, but is repelled by them.

Keep adding particles until the entire canvas is covered in these hungry particles that cluster around the brightest areas, and are nourished by them. The largest particles will be covering the brightest areas, while smaller, malnourished dark particles will have been sequestered to the dark corners of the image.

Once this ecosystem has been saturated, the boundaries of each circular particle can become loose, like jelly. each boundary becomes a new particle simulation, each circlular boundary subdivided into smaller interconnected particles. The interconnected particles are attracted to eachother, and in isolation, pull together, like the skin of a bubble. Their resting state is the size of the original particle, at this resting state, the particles are repelled at exactly the correct distance for this resting size to occur.

At the same time, all the particles across the entire canvas are attracted to eachother- or more specifically, they are attracted to the particles nearest to them.

While the compulsion is for the boundaries to remain circular, there is a stronger compulsion to spread out, and meet with the surrounding boundaries, and form a more complex shape. The forces at work across the canvass will eventually come to a balancing point, where no more movement will occurr. This resting state will be composed of a number of well fitted shapes, colored appropriately, and sized according to brightness. They will be well enmeshed together, and form a faceted image which maintains organic and geometric qualities at once.

Lighting in context

2007-05-01T19:58:00.000+10:00

There is a computational photography technique in which a subject is placed within a sphere/dome of lights. The subject is then photographed with each light illuminated one at a time, resulting in a number of photographs equal to the number of lights. These photographs can then be composited together and modified in such a way as to simulate any possible lighting condition. This is achieved by taking a "lightprobe" of an environment and mapping it to the spherical dome of lights- such that each light matches the color and intensity of that corresponding space in the light probe. Or more directly, each photograph which corresponds to a particular light in the light dome is modified to appear as though that particular light had the color and intensity of that cooresponding space. This modification and mapping is done with each photo in the set, and they are all summed together into a single "Exposure", and you end up with virtual lighting.

Isn't it an interesting situation then, if you take this virtual lighting concept, and you combine it with the fact that modern macintoshes are equipped with a camera which is easily accessed from software, and facilities for taking screenshots of the current scene on the screen of the computer. These two could be combined into a sort of "light probe", such that a photographed object could appear on screen and look as though it were lit at the back by the other objects on screen, and lit at the front by the room surrounding the computer.

This illusion could be perfected by a measurement of the brightness of a typical computer screen, combined with exposure information from the iSight. These would be fairly standard across the models of macintosh equipped with built in isights.

Thus a dynamically lit widget could be produced, quite probably with the help of quartz compositor's easy access to isight, and easy integration into widgets.

On bad artistic assumptions

2007-04-15T14:56:00.000+10:00

In creativity, I cannot stress enough the importance of research. This is not an idle bit of advice. In teaching or learning, there are many such rules and practices, which are taught and given without argument, expected to be accepted. As a student you may accept unquestioningly what you are taught, at least for the purposes of the course and the grade. Without the reasoning to back it up though, such lessons do not become knowledge, but instead become religion. Knowledge is something that you can demonstrate, and if prompted, give a convincing argument why such and such is so. Religion is merely a set of rules that you follow, without knowing why. They are in other words, a set of assumptions.

This is all very abstract without an example, so I will demonstrate now why research is important, and why a creative should not take it for granted.

Some time ago, I made a Totem painting. The basic idea I had was to paint on a 2' by 8' masonite board, a Totem Pole composed of a number of various mass cultural characters, such as the cat in the hat, kermit the frog, mickey mouse, etc. Collaged with this was images of various scenes I picked out of searching through various japanese websites and books; imagery from japanese culture; modern and traditional. While the painting was generally well recieved, it wasn't a *great* painting, and this was not due to the quality of paint I used (admittedly poor), or how much time I spent making crisp lines (not a lot).

The reason it wasn't a great painting is due to the rushed assumptions I made in the conceptual phase. The worst assumption, was the ethnocentric viewpoint that totem pole design is simple, and primative, and thus easy to imitate. The really stupid assumption that totem poles were merely stacks of heads, and yet another bad assumption that it's possible to encapsulate the subtleties of an entire culture by merely selecting a few images.

The truth is, totem pole design is as nuanced and delicate an art as font design, or classical architecture. There is a balance of line, volume, and flow which is not easily mastered. Additionally, totem poles are not merely heads- they are entire bodies, deformed yes, so that the head is the most prominant feature. But the body is still there nonetheless. There is cultural context in these deformations which again is not easily mastered. This sense of cultural context is also missing in my rushed and crass choice of japanese imagery. These assumptions, spelled out, seem obviously stupid. But these sorts of assumptions are not easy to notice, especially when you are rushed. They are not easily noticed because one does not typically think about what assumptions one holds, until they are prompted in such a critical way.

The most difficult thing about learning, is being flexible enough to recognize where you are making assumptions, and maintaining the will to discard these assumptions when it becomes necessary. This is something a teacher cannot do for you. This is why research is important: It shows you what reality IS, not what you expect it to be.

Research research.

Efficient typing system

2007-04-10T21:55:00.000+10:00

skeleton post- fill in details tomorrow.

1. tedius repetition in task of typing on a mobile phone or gaming device.

2. Computers designed to eliminate repetition

3. Statististical prediction

4. Automatic adaptation

5. Other applications

Programming Language

2007-04-10T21:51:00.000+10:00

1. Why create a new programming language?
I have an idea for a programming language. There are hundreds already though, why create a new one? I firmly believe that the bulk of programming languages are missing the point. They don't lack effort or thought, many are theoretically sound, many aren't. Some of my favorites are Lisp, Ruby and APL.

What's lacking in the world of programming languages though, is the perspective of a designer, because frankly, every programming language I see is ugly. Every programming language I have seen, to one extent or another flagrantly disregards the history and culture of punctuation and symbology. They abuse symbols, assigning them meaning they were never meant to have. These programming languages force their readers to cross their eyes, and ignore their years of cultural training to follow the specific and unique logic which applies only to the world of programming. The relatively high density of brackets, and nesting lead to a visual ambiguity which requires an expert, and a good code formatter to decipher. Code should not be code.

And why should code be beautiful, you may ask? The end users don't have to look at it, and the programmers should be clever enough to deal with any sort of cryptic obfuscation, and difficult to type out structure. They are professionals after all! Sure, but the key point is, they are also human. Difficult to read, and hard on the eyes code leads to more mistakes, more fatigue, and over all a more grueling experience. Your average person can usually look at a gramatically incorrect sentence, and immediately sense that something is wrong. Your average programmer doesn't necessarily have this ability with a line of code. Due to the haphazard and thoughtless design of programming languages, you still have to read through word for word, symbol for symbol to figure out why something doesn't work, why something is illogical.

I think there's a better way. I think there is room for a humanistic programming language. I think it's time for one too. There is currently no technical reason it is not possible. The *only* reason we still code using these brutal machine languages, is due to the short history of computers, and their original strict limitations. These limitations no longer exist, but the assumptions that we built from those limitations still do. Let's work to improve this.

2. Design goals

It's easy to lose sight of your goal, in the midst of the process of creation. See my earlier post about creative briefs. Ruby on Rails has a number of design principles. there's Don't Repeat Yourself, and the principle of least surprise, for a couple of examples. A humanistic programming language should have some basic guidelines to enforce a certain amount of self consistancy.

Here is the space where I will keep my working list of HPL ideals.

Respect the punctuation: Don't violate the history, culture and meaning of symbols. We are no longer limited to just what's at the top of the keyboard, above the numbers. Nowadays, we have the entire Unicode symbol library at our command. Let's find appropriate symbols, and use them for their appropriate meanings.
Whitespace is not irrelevant: Having a standard indentation style has proven invaluable to the open source projects that have enforced it. Having a common visual expectation for the code makes collaboration that much easier. Let's not rely on humans to enforce the visual style. We have computers for droning repetetive tasks like that.
Dielects over Bloat: In the real world, different professions each have their own specific languages. Think about the show ER, and the sheer amount of latin they use just to get around having to tediously describe in detail every little thing. Verbal shortcuts. The same should apply to programming. If I'm making a web application, don't make me tediously describe the process of retrieving information from a form, or persisting data in a database. We know in advance we need to do these similar tasks many times. Provide shortcuts for doing them.
Loops are a bad solution to an old problem: The typical tasks which need to be performed by loops is well understood by now. Some task needs to be performed on a list of things, a tree needs to be traversed to find a needle in a haystack, etc. Make syntax for the task, not the computer's method of performing it.
Syntax for the task, not the method: nuf said
Brackets are bad, nested brackets are worse: Brackets are actually visually useful, as long as the opening and closing bracket are on the same line, and there are no other brackets nesting in or around them. Once you break them out into multiple lines, nest them, and worst of all, have a line with nothing but a bracket, things start getting confusing and visually ugly. A closing bracket visually points to the left. If it's on its own, it is pointing at nothing. It is closing and resolving nothing. Combine it with nesting, and reading a page of code becomes a game of matching opening brackets to closing brackets. How can you debug your code, if you have no idea what is going on in it, and it is not visually obvious that you have made a typo? XML endevoured to solve the matching problem. How? More brackets! MANY MORE BRACKETS. Great. I think we can do better.

3. Parallelism

4. Relational integrity

5. MVC enforcement

6. Event Model

7. REST architecture provides a means for sharing work, without working to share.

8. Internet provides a means for automatic distributed super computing.

The value of the creative brief

2007-04-08T21:54:00.000+10:00

During the development of an idea, it's easy to lose sight of your original vision. You begin to see new things in your work, and it carries you in new directions. Often during this process you end up with something very different from that which you originally intended to create. During the process, you forget the problem that you set out to solve, and judge your work purely on its aesthetics, or the feeling of the moment.

The creative brief is the solution and recognition of this situation.

A creative brief is a written, detailed description of the design problem to be tackled. It is not simply a statement of the problem (a brochure needs to be created), but also gives you relevant facts about the client, their target market, the market goals they wish to achieve, their history as a company, the intended message which needs to be conveyed, and any other relevant information. A good creative breif gets beyond the simple question of "What do you want", and instead sets in a number of parameters which define a "space", what is often referred to as the "Problem Space". Within this defined space exists viable solutions, and beyond it lay non solutions. In theory. A really good design process will recognize when a creative breif is inadequate, and midway through redefine the problem, perhaps in different words, perhaps from a different perspective. For instance, a creative brief might stipulate that the client needs a business card for her florist business. A designer, after some meetings with the client, might redefine the problem as "The client wishes to attract more business from engaged couples, and stay within a budget of under $4000"

The key here, is the more detailed you get, the more you crystalize a vision of what the problem *really* is, the more productive the design process becomes.

Through each revision, and at the end of the process, ask yourself: "Does this *really* solve the problem?". be thoughtful and honest to yourself (or others) in giving the answer. If you answer no, ask yourself why, and you will understand what revisions need to be done. If you answer yes, be careful that you are not deceiving yourself. There is no such thing as a perfect solution- But within a problem space there are many possible solutions. Is this the best one?

This may seem stupidly obvious, but in this complex mesh of theories and processes that is the design process, it is easy to lose sight of what is obvious, and get lost in the details of implementation.

The aftermath of the flood.

2007-04-08T15:11:00.000+10:00

I had a conversation with my friend Dano, and I thought of a few more things about ideas.

'The progression of design history has not been a progression of new ideas, but the identification of new aspects of the same old problems."

It's not the ideas through history that have been important. That is just the part that people notice. They don't notice why they came up with the new idea. They don't think about the fact that it didn't come from nowhere.

I think to a large extent, as a designer I have been fixated on coming up with the next big thing, the new great idea. In doing that, I lose sight of the fact tat the people that came up with the last great idea didn't do it on purpose. They found a new aspect of an existing problem that nobody noticed before, or they did notice, but were too afraid to openly acknowledge that it exists.

Dano then tells me that he is the "Exact same way". He wants to come up with something great and new, and he psyches himself into getting nothing done, and making nothing but shit along with it. He wonders why he can't just do things without thinking "How can I be completely original", and suggests that this is perhaps too lofty a goal to set yourself to.

It's a bit like a chinese finger trap. There's an element of selfishness in wanting to grab some small bit of glory for yourself. But in order to get there you have to completely forget that you want that. You have to convince yourself that you don't, and you're just out to solve a problem. You also have to accept that there's a very good chance that it won't turn out great, and not let yourself be dissapointed when it doesn't. Just figure out what went right, what went wrong, and move on.

The great solutions come out of honesty; honesty to the problem, honesty to yourself, honesty about the solution. Don't let cultural biases, or your ego get in the way of perceiving something about the problem. Don't succumb to the forces that tell you to ignore it, the forces inside you that want to be seen as good, and smart, and talented, and better. Instead listen to the littler voice inside you that says the emporer has no clothes.

The flood

2007-04-08T13:37:00.000+10:00

The important thing to remember about ideas, is that they are not important. This will probably violate a lot of people's feelings about ideas, but it's true. Ideas are cheap. It's the execution that matters. This is why I have no problem writing all my ideas out here. It doesn't serve me any function to jealously keep all my ideas secret, in fear that someone will steal them. I am not the scriptwriter that accuses the producer, who rejected my script, of stealing the very ideas within it. The value of ideas has become very distorted in modern western culture. This could go on to become a lengthy discussion about copyright law, but that is not why I am writing this post.

So, let's take it as a given that ideas are a dime a dozen. Suppose I fill this blog up with a dozen ideas a month. How do I determine which ideas are worth pursuing? Which ones should I invest real time in bringing to reality? I Think this is related to the question I asked in the first post. How do you define a person? Another (more sexist) form of the question is "What is the measure of a man". It's a question about measuring the potential of a person. It's a question about predicting what that person is likely to do in the future. Depending on how you look at it, it's also about how a person is percieved. It seems shallow, but social perception is important. So when you are judging a person, what factors go into your judgement? What do you look for to decide whether someone is a genius, or a peasant?

Perhaps it is what a person has done in the past. If it is, then really, you are judging a person based on what ideas they chose to act upon, out of the sea of ideas. So one must choose carefully, as the ideas one chooses, determines who they are, or at least how they will be judged.

Many people will chose ideas based on their marketability. Perhaps there's a certain cool factor. Perhaps they've fallen in love with a particular technology. (lots of people have fallen in love with AJAX, lately). Most people don't think about the criteria they use for choosing what to act on. They just do things because they feel good, or they do things because they think it is expected from them by other people. Some people just have a really nice hammer, and are out looking for things that look like nails. Others just want to be seen doing the same things as everyone else, and desperately want to be thought of as cool or normal.

As a Graphic Designer, I am trained to start with a problem. Once I've established the exact nature of the problem, I must think of as many possible solutions as possible. The flood of ideas. The more you can think of, the better. The idea that wins, is the one that solves the most aspects of the problem. The progression design history has not been a progression of new ideas, but the identification of new aspects of the same old problems. Modernist architecture fullfilled all the needs of a human being, through the triumph of science.

That is what the architects thought. They've thought of the optimal size of the kitchen, the living room, how many bathrooms there should be, where they should be located, how high the ceilings should be, what the best materials are, how to give just enough space to someone so they don't feel cramped, but not so much that high density living is not possible.

They forgot that humans don't like living in featureless boxes. So Postmodernism is about the discovery of the human aspects of problem solving. Unlike modernism, Post-Modernism doesn't strive for purity, or the triumph of man over nature. Post modernism accepts everyone and everything for exactly what it really is. Post modernism doesn't reject history, it doesnt' reject science, it doesnt' reject pointless decoration or starkness. Post modernism is the relentless search for new aspects to old problems, and it has erased the boundary lines for future eras of art, and replaced them with a smooth continuous forward march away from the myopia of modernism.

So how do I choose which ideas to pursue? I don't. The best thing to do is choose which problems to pursue, and investigate as many aspects of the problem as I can, in a thoughtful and methodical way. The ideas will sort themselves.

Voxels

2007-04-07T18:37:00.000+10:00

What is a voxel? it's like a 3 dimensional pixel. It is short for "VOlume piXEL". It's a very simple concept which has been used in countless applications, from medical imagery to videogames. The basic idea is a 3D raster, each element of which stores attributes such as color, transparency, density, normal, and countless other possible things, or subsets of these. The classic Demoscene demo is the voxel landscape. (not true voxels, but possibly an impressive demo nonetheless).

I have been obsessed with voxels. Why? I think there is one application of voxels which has been underserved: 2D style games. Rapid development of Pixel art. Imagine the standard 16 bit games with multiplane parallax backgrounds. Now imagine them with many more contiguous planes, 3 dimensional objects in the background smoothly passing by in perfect perspective. Not flattened cardboard 2D paintings, but fully 3D props rendered with a 1voxel=1 pixel style engine. Most voxel rendering engines I see make the grim mistake of rendering a voxel with many pixels, creating an ugly pixelated look. Imagine 3D worlds with the tidy detail which is given to 2d pixel art. You can get a taste of it at the metroid cubed site here http://pages.infinit.net/voxel/home.htm

I get excited at the potential of this guy's work, but saddened to see it wasted in cheesy 8-bit style graphics, and reliving old games, and old gameplay models.

Like many, I have been dissappointed in the graphic quality of games since the playstation arrived. 3D graphics in videogames are consistantly ugly as sin. Their bicubic scaled textures filling the screen with vomited blurs of pixels.

I want a 1pixel=1voxel world. A 1pixel=1voxel oriented graphics editor. A 1pixel=1voxel oriented game engine which combines the flexibility of 3D with the exquisite detail and lush beauty of 2D pixel art graphics.

1. The Basics.
Each voxel can store a color, and an opacity. Most of the time, opacity is a simple on/off switch. Either it exists or it doesn't. It can be full alpha, which significantly slows down the rendering of the voxels. The result is a smooth density cloud- this is what makes voxels useful for medical imaging. Newer game engines are using voxels for more realistic clouds and smoke effects.

2. Normals.
what is a normal? In 3d graphics parlance, a normal is a point in 3D space which is the terminal of a line that is perpendicular to the angle of the surface at a specific point on a surface. In other words, the surface normal defines what direction a surface is facing. One can determine how well lit a surface is by measuring the angle between the light source, the surface, and the normal. This is a very simple cross product, then arc tangent operation.

With voxels, each voxel can have its own surface normal. Many voxel engines determine the surface normal automatically based on a voxel's neighbors. This produces a very legoish appearance to your voxel models. It is possible to smooth this out by taking into account more neighbors. I think a better idea, is to model first in a standard 3d modeller, then remember the normal of a surface when converting from the standard model to your voxels.

Thus, a voxel model can be more than just a flat colored grid of 3d pixels, but dynamic per voxel shading is possible, with very smooth appearance to the surface.

Some other very handy things can be done with normals though. You can find the contours of a voxel model, and use them to add cel shading style lines. Here's how it works: Simply give your voxel model a shell of invisible voxels, just a 1 voxel thick coating. Then, render the shell voxels if their normals are parallel or near parallel to the camera. This is a common technique in polygonal cel shading. This is an application of the same principal at a pixel level of precision. Essentially what this does is render a pixel next to any "surface" which is perpendicular to the camera. This will be the object's contours, what we normally perceive as its edges.

The beauty of this is that the exact shape of the shell can be tweaked and modified to exactly how you need it to look, at a pixel level. What's more, this can do more than just outlines. Pixels which only render when their normals are pointing a certain direction away or towards the camera, can be used for view specific pixel level tweaks. Is one view particularly awkward? just tweak it a bit. This is the same basic principle as hints in vector fonts.

3. Simulations.
Since every atomic element of the object is defined as a point, this opens the door for a vast variety of particle simulations. Particles in simulations can be made to behave like liquid, smoke, jelly, springs, strings, cloths, solar systems, bouncyballs, pendulums, rag dolls, etc. Voxel positions can be attached to particles in a simulation, allowing characters and objects to realistically bounce, flow, explode, melt, stretch, fall down, trees grown, geological simulations producing realistic voxel landscapes. The possibilities are endless.

4. Sprites.
Remember the opening title screen for Yoshi's Island? It's basically a 3d island composed of a number of 2D graphics attached at some point on their base to a 3d plane. The plane rotates around carrying the graphics with them, creating the impression of a 3d island while keeping the cartoony detailed appearance that only dot graphics can achieve.
If I create my voxel paint program, I want this effect to be achievable as any other voxel effect, and combinable with any amount of voxel graphics. Just attach a 2d graphic to a voxel, and the 3d calculations take care of themselves.

5. Isometric.
One comprimise that I don't think any pixel art purist will object to, is that I intend that my ideal voxel rendering engine not apply perspective to its voxels. the scaling of the voxel has the potential to destroy the 1pixel=1voxel idea. At the very least, a perspective engine should not scale a voxel any larger than a pixel.

6. Sub Surface Scattering
This is a popular effect in computer graphics for simulating the appearance of skin. In order for it to be realistic though, an object needs to have an interior. For humans, the interior must be red and meaty. In a voxel object, the interior is already there.

How will I make this all work? what programming language shall I use? What sort of game will I make?
I haven't decided yet. Maybe flash. Maybe java. Maybe SDL and C. Maybe all of the above? Perhaps anyone who happens to read this has an opinion? Who knows.

Am I web 2.0 now?

2007-04-07T18:34:00.000+10:00

Okay so I have a blog now. perhaps unlike the thousands of other people who also have blogs, I don't expect anyone to read this. (But if you are reading this, I'm deeply sorry.) Why did I start this blog? Because I have too many ideas in my head to keep track of. I don't have enough time to implement all of them, but I also don't want my ideas to pass silently into oblivion either. I have tried windows notepad files. I've tried mac stickies. I've tried livejournaling. I've tried physical notebooks, and the running thread is that I have too many systems for recording ideas, and my head is busting at the seams.

Who am I? Who is anyone? How is a person defined? Is a person the sum of their experiences? Is a person the resume of things they have accomplished, the list of jobs they've held? Is a person a composite of the thoughts and opinions they hold? Is it the unique matrix which defines how a person responds to perceptual events, their personality? I am barely a person by any of these standards, but I exist anyway, so I may as well make the best of it, until I die or something kills me. I am just a person who has ideas.