About All Things... |
Declarative,
Mobile 2.0,
REST,
Cloud,
Web 2.0,
Ajax,
Publish / Subscribe,
Event-Driven Architectures,
JSON,
Atom,
Microformats,
Linked Data,
P2P,
Identity,
Copyright,
Multimedia,
Cyberspace.
|
...taking programming beyond: Threads, Message Queues, Client-Server, CORBA, Web Services, SOAs, Agents, Synchronous Architectures, Imperative Programming - and even Applications, Desktops and Documents |
Duncan Cragg... |
...works for ThoughtWorks UK; originally from April 2002 to July 2007 and now recently re-joined. Previously worked as a Web Architect for the Financial Times. |
...went to both UCL and Imperial College of the University of London (in the Eighties); specialising in Logic during his MSc. |
...wonders when his LinkedIn Account will be useful |
...has a phone-cam, and used it on himself once, just before his weekly shave:
|
...can be contacted by
and followed on Twitter.
|
|
|
|
February 10, 2015 15:58
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..
...
May 19, 2014 21:21
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.
This article first appeared on the ThoughtWorks Insights pages.
...
March 1, 2014 11:24
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.
...
January 27, 2014 11:36
I've started another blog called Building The Object Network, about how I'm experimenting with Augmented Reality for the Internet of Things using the Object Network approach.
So far I've been blogging every day.
Do subscribe!
...
January 16, 2013 17:09
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.
...
January 20, 2012 18:07
Updated: January 23, 2012 19:45
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.
...
January 19, 2012 20:58
Updated: January 22, 2012 16:05
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.
...
November 29, 2011 23:11
Updated: January 22, 2012 16:03
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.
...
May 10, 2011 11:11
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.
...
February 12, 2011 14:07
Here's a quick catch-up of developments in FOREST.
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...
...
March 18, 2010 16:58
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.
...
January 26, 2010 13:46
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.
...
January 6, 2010 17:03
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.
...
December 11, 2009 08:22
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.
...
November 25, 2009 21:29
Say we want to integrate multiple applications which handle order processing. OK, that's
got to be one of the dullest starts to a blog post. Never mind, bear with me...
So, we have applications on separate servers for handling and driving data such as
orders, product descriptions and catalogues, stock lists, price lists, tracking, packing
notes and delivery notes, invoices, payments, etc.
We may choose an SOA approach, of course. But let's say our sponsors have heard of this
cheaper alternative: REST! Which to them means 'using Web technology to save money'.
Now .. suppose we push the time slider right back to before Mark Baker and the SOA -vs-
REST Wars - or the 'SOAP -vs- REST Wars' as people naively called it. To when REST was
simply (!) a description of the Web's architectural style...
What if we revisit the applicability of the Web, and its abstraction into REST, to the
architecture of machine-to-machine distributed systems - to something like our order
processing integration?
I think we'd quickly arrive at something that looks more like
FOREST
than, say, AtomPub...
...
October 9, 2009 17:14
Updated: October 11, 2009 11:46
Since the day in 2006 that our
dialogue
took place with an imaginary eBay Architect, he has been promoted to imaginary
Enterprise Architect in an investment bank! Convinced by the merits of REST, he took
his enthusiasm for it into his new job and embarked on architecting a trading system
using REST or ROA as an alternative to SOA.
Now, he hit upon a snag: he had a REST "bank server" generating bids on an instrument
and POSTing them into that instrument's REST "market server". But then he had two
copies of his bid! One held by the bank server on one URI, and the other in a "bid
collection" held by the market server's instrument - on another URI.
He asked himself: "Which URI is the real one? Which host 'owns' the bid? Is the market's
copy just a cache? If so, why does it have a new URI? Why doesn't the market host know
the URI of the bank's original bid? Why can't servers become clients and just GET the
data that their own data depends upon?" The server seemed to be dominating the
conversation, not letting its 'client' server have a say in things.
Our worried Enterprise Architect noticed that such Service-Orientation permeated REST
practice: there were "REST APIs" to Web sites, or "Web services" with a small 's'. Even
AtomPub had a "service document"! Some patterns, like AtomPub, offered just simple
read/write data services through the full HTTP method set. Some simply used such a
read/write interface as a wrapper around more complex service functions.
He wondered: "Where's the Web in REST integration? The Web works great without PUT and
DELETE: isn't using GET on its own RESTful enough?"
So, remembering something I said about "Symmetric REST", he contacted me again...
...
October 6, 2009 10:28
- Functional Observer REST = Hyperdata Interdependency requiring Symmetric REST
- Hyperdata Interdependency = a resource's state is a Function of its linked resource context
- Symmetric REST = servers become clients in order to Observe the dependencies of their resources
...
|
|
|
|