These days I seem to mainly use this blog for once-a-year announcements of what I'm up to, which is useful as record for myself when I need to reflect.

So here's where I'm at, as 2015 begins..   ...

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.

Stay tuned!

  ...

Right, let's get started with some basic conventions in the Object Network!

This part in the Object Network series will cover URLs, HTTP headers and some common JSON patterns.

Updated 23/1/12: I changed the URLs in the example to have one of each type.   ...

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.   ...

It's interesting to compare the current growth of Web APIs with the early growth of the Web itself. To save you jumping those links: the Web dramatically beats the APIs.

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.   ...

Like Subbu, I also have been sitting on a blog post about the Richardson Maturity Model. I have different reasons for feeling uncomfortable with this Model, however.

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.

Seems controversial to you? Read on...   ...

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.

Here's how JSON-Mash will work.   ...

Right, I'm pleased to say that I've now implemented enough of the Fjord language on Node.js to be able to run the Instrument example that I introduced it with. As yet, this runs in memory only - i.e., no disk, no network.

Here's the code on GitHub with tests that show how it works. The language has changed a little so I'll show the example here again, copied over from the test code, in order to explain the differences.   ...

Well, I've put together the first few lines of Fjord, implemented on Node.js.

Here's the description on GitHub: Fjord is a language for expressing domain logic as match-rewrite functions over mashable JSON Web objects.

I'm developing Fjord very openly, in the hope someone out there will be interested in getting involved in helping guide its design and implementation. I suppose code speaks louder than blog posts.   ...

Following on from my recent article where I derived FOREST, this article offers the beginnings of a JSON unification and rewriting language that can be used in a FOREST architecture.

Why JSON, not XHTML, now? Well, I recently discovered that JSON is overtaking XHTML in interest, and I was further inspired by Kris Zyp's recent announcement of his JSON Schema Internet-Draft.

Fjord is a language for describing how the state of a JSON resource at any time depends on both its current state and on the state of other JSON resources that it links to via hyperlinks.

Fjord is a Norwegian word, probably pronounced 'fiyourd', and might stand for some combination of the words: 'Functional JSON Object/Observer Resource/Rule/Rewrite Dependencies/Declarations'. Or maybe it's just because they're truly awesome, an' I wanna go.

Fjord also gives me an opportunity to show some examples of the "end-user" view of a FOREST interaction; starting with a simple finance example.   ...

Since the announcement by IBM and Linden Lab that OpenSim can talk to Second Life, I've been thinking again about RESTful Virtual Reality.

I'm not the first, of course. Others have been motivated by the same goal: To bring the Web's scalability, linkability and interoperability into Virtual World platforms.

Ultimately, how to use the same techniques as the Web to link Virtual Worlds together into a single, massive 'Virtual Universe'.

Here's how I would architect the Universe Web...   ...

Last night's Google London Open Source Jam (also here) was on the subject of the 'Web' (didn't they invent that? Oh no, that was Microsoft).

This event has been getting better and better each time I've attended. There were some very interesting lightning talks held together with a tight structure and plenty of chance to chat, drink cold Leffe and eat cold pizza. And nick [transatlantic translation: 'steal'] the Green & Black's chocolate.

An ideal Micro Conference...   ...

Web 2.0's definition includes seeing the Web as an application platform. Which means it is in competition with Java and .Net, and with SOA, for both local and widely distributed applications.

If the Web is going to be a platform, the skills you need to learn to program it are the core Web 2.0 technologies such as Ajax, JSON, Atom, Microformats and OpenID.

And Ruby. This language, that's capturing the hearts of many Web 2.0 programmers, is ideal for easing the transition from the Java and .Net platforms to the Web platform, as I will show.

Even if you're part of a big company that is generally immune to the latest trends, the marriage of Ruby and the Web-as-platform may be something to prepare for. It could even displace your SOA agenda...   ...

What do all the MAJOR Web 2.0 technologies of 2007 have in common?

Let me list them first:

    M.icroformats (including tags)
    A.jax (including Comet)
    J.SON (plus YAML)
    O.penID (plus SXIP, LID, Yadis)
    R.EST (including Atom, APP)

What these technologies have in common is that they're all lighter than their competitors:

  ...