So now I'm back to that core goal: end-user programming of virtual worlds in Android, but now with a splash of Minecraft, a sprinkling of Augmented Reality and a pinch of the Internet of Things.

Of course, any virtual world today feels like it came from the last century if it refuses to acknowledge the tactile accessibility that was discovered by Notch in his world-sweeping game.

Android is an ideal platform for all this, because it is clearly AR-native, plus it can be used as a Thing - especially with sensor-packed, Bluetooth-enabled Android tablets and phones becoming such a cheap commodity.

I want to make the language more accessible to normal people by bumping up the number of dimensions used to access it: from my one-dimensional text format (which I still think is pretty clean and nice to read) to a two-dimensional graphical or visual interface.

Names

So, while I wait to see if "Cyrus" is actually viable in the longer term to name the language, this year's names are back to the Object Network and NetMash. I'm also still using "FOREST" and "Functional Observer" to describe the architectural style and programming model, respectively, if anyone asks.

But since I'm focusing my energies on end users not technical folk, I'm not expecting anyone to ask..

With the expansion of the Internet of Things (IoT), and the diversity of products and
technologies, the one thing that everyone agrees on is that it's time to start agreeing:
the Internet of Things needs standards. Many agree that it needs open standards, like
those that underpin the Web.

Obviously, a Web of Things is going to be quite different from the Web of Documents and
Applications: it'll be much more fine-grained and much more "buzzy", with many sensors
and actuators working together with many hubs and services. It's more likely to be at
home with the next generation of the Internet Protocol: IPv6.

To meet the fine-grained and buzzy nature of the IoT, the
Constrained Application Protocol, or CoAP,
was created. CoAP is an open Internet standard for the Web of Things. It's based
on the Web's core pipe: HTTP, but has many differences to allow it to be used by very
resource-constrained devices and local radio networks.

CoAP can be used in many different ways, but there's a danger that a lack of clarity in
exactly how it's used means it doesn't achieve its full potential to link up the world's
embedded devices.

This article proposes a simple and clear way that CoAP could be used to build a uniform,
global, decentralised Web of interacting and discoverable Things.

After filling up that other
blog recently with 61
pages of content, one page a day, I was challenged by my ThoughtWorks colleague,
Andy McWilliams, to help him get in more
easily to my explanations of the Object Network applied to Augmented Reality and the
Internet of Things, especially around how my approach differs and is better than other
approaches.
...

Well that worked out pretty well:
I have a 3D environment on Android programmed in a simple but powerful declarative
language which I've called "Cyrus".

Cyrus basically uses JSON all the way through: from user
interface and scene graph to rewrite rules, on the wire and on disk. The Cyrus
programming language is essentially JSON itself, as JSON rewrite rules. I've reduced the
noise of JSON in Cyrus by taking out redundant double-quotes, square brackets and
commas. It looks very nice to me.
...

If you also think that hacking up 3D worlds on Android could be fun, then join me! Stuff you should expect to play with if you want to get involved includes Java, Android, OpenGL ES 2.0, 3D model creation, hyperlinked JSON and JSON rewrite rules. Creatives, evangelists and inspirers are also very welcome to get involved!

The idea is to make an app (NetMash) that lets people build, mash up, animate and program 3D worlds, shared online and all linked-up, Web-like.

Like creative-mode Minecraft, but adding easy in-world programming and shared online by default. Or maybe a bit like an open, distributed, generic, mobile
Kodu (or
here), for adults as well as children.

NetMash is intended to deliver creative empowerment to ordinary people. We professional software folk often get stereotyped as geeks, and the creative fun we often have dismissed as in some way unusual. That's a real shame, because such prejudice means that the other 99.9% of the world are simply missing out on the joy of experiencing the most creative and empowering activities humankind has yet invented.
...

I just re-read my article on the Universe Web. I think it's pretty good. Indeed, to be honest, "programming as Cyberspace building" is where my heart has always been, and I'm all about following my heart this year. Especially if it's more fun, for both myself and others! Or if it opens up new worlds to new people.

In contrast, I don't see "fun" in W3C or IETF activities. Indeed, there's recently been a number of examples of tension in that world, between stabilisation and innovation, idealism and pragmatism, Enterprisey and Webby. Interestingly, all those examples have a "2.0" flavour: HTML5 (Web 2.0), HTTP 2.0 and OAuth 2.0.

My own interests are rough consensus and running code; innovation and pragmatism. Webbiness not in the W3C sense - "Web" Services, Semantic "Web", "Web" Sockets, etc. - but in the sense of "the simplest thing that works". Which is the Web of HTTP (1.1), URLs, JSON and REST, or specifically my FOREST interpretation.

I crave the simple and powerful, the cool and the fun. Which ultimately leads to the kind of thing I was describing as the Universe Web. And to be honest, I'd like to write and code for me, not for my peers and colleagues or for my career.

So, to the pursuit of pure joy in place of compromise, I'll now be focusing my energies on the journey of evolving the NetMash Java server and Android app towards an online, open, hyperlinked virtual world that is programmable in-world by users using simple rules.

OK, I'm trying to take a Big Idea and make it as Simple As Possible to grasp.

If we link our JSON data together and use the same formats, then our mobile, browser and
server apps can become much simpler - through clean, stable, common, shared, re-used
code - and much more powerful - through clean, stable, common, shared, linked, cached data.

This is the second part in the
Object Network series,
which will guide you away from building isolated Web APIs to engaging in a linked-up data landscape.
...

I believe that the most likely cause of such relatively slow growth (in what should be a
booming ecosystem) is that each API forms a closed silo and cannot benefit from any
network effects. Every API is different and there are no links between them. There
usually aren't any links within a silo. You can't even use a given API without first
consulting the documentation.

The Object Network is designed to fix this, with linked-up
JSON in common formats. This will allow easier mashing, sharing and cacheing of data and
allow client code to be shared and reused.
...

The Web, in its purest form - declarative HTML and CSS documents, XML feeds - is
mashable, linkable, sharable. It's easy to create documents that slot into the global
Web and can be accessed on any device; accessed by just a simple link. Servers can
easily scale through statelessness and cacheing.

Native Mobile Apps are fast and slick. They are intimate with the dynamic, interactive,
tactile mobile user interface, intimate with the capabilities of the device and intimate
with the domain of mobile: photos, locations, contacts, messages.

OTS is a simple, clean, powerful approach to delivering Mobile functionality and
content that is designed to realise these benefits of both Native Apps and the Web.
...

The following came out of a discussion on an internal list at ThoughtWorks, where a
number of people were talking about how they aspired to reach the "Holy Grail" of REST
Level 3, and still thought they were basically "doing REST" by addressing most of the
uniform interface.

But, as indeed pointed out in that article, REST is only at Level 3.

However, fortunately, you can jump right to Level 3 without much effort.
...

This post is a response to a question that came up on an internal ThoughtWorks list.
The question was, in summary: "Is using JSON more RESTful than minting our own
Media Types as required, given that using raw JSON means reading inside the content in
order to know what type is being transferred?"

TL;DR: Yes, use a common Media Type and "switch" on the internal data type; create a
new Media Type only when something generic and broad and new and useful settles out.

I've been working much more on FOREST than Fjord or JSON-Mash recently, and it's coming along very nicely.

Actually, I've been lying flat out in bed with Pneumonia (and various other consequent ailments) for several weeks, so have been quietly tip-tapping away on a laptop resting on my tum, when I've had the energy.

Which has given me a chance to tidy up and finish off some FOREST stuff that I started last year...
...

Around the middle of February I completed a basic persistence and networking
implementation for
Fjord,
then had to do other things for a month. Just recently I
fixed Fjord to work with the latest version of the
Node.js APIs.

Next project: I'm going to use Fjord in a Web Framework to be called "JSON-Mash".

I intend to show that JSON-Mash will be a great framework for rapidly building
truly interoperable and truly scalable online and distributed functionality.