Tuesday, March 02, 2010

Glob Design

I've spent quite a while designing Globs.

Design is really about distilling the essential form and function to solve a problem space. Once the problem space is known - sometimes the design just pops out. After a lot of effort, thankfully, the design for Globs is starting to squeeze out.

During the design phase I've constantly moved up and down the following axis:
  • big vs small
  • fast vs slow
  • consistent vs eventually consistent
  • complexity vs simplicity
  • private vs public
  • flow vs interruption
  • creation vs copying
  • usability vs utility
  • XML vs JSON vs RPC vs HTML5
  • universal vs limited
  • and many more ....
I'm still moving the sliders on each of these dimensions - but here is what I know so far:
  • a Glob is a handle on a Thing - it is not the Thing itself - it just sticks to it
  • a Glob belongs to a Channel
  • a Glob has a URI in that Channel
  • a Glob is idempotent (we need this for calculating Karma++)
  • each Glob has an external SHA1 and an internal SHA1
  • a Glob has a summary, favicon, text icon, origin context, captured_on_time and given_to etc.
  • a Glob has a HTML5 Description/Payload
  • a Description contains actions on the underlying Thing
  • Channel, Context and Configuration variables can be inserted into Glob placeholders
  • Globs can be HTTP POSTed into the Trail of a Channel via a Sensor
  • Globs can arrive in the Trail in absolute time or relative time (including the future)
  • A Glob can be proxied from one Channel to another Channel
Along the way here are some ideas that were ruled out:
  • using Git as the Glob store
  • a Glob does not contain code itself (although it can anchor some code)
  • a Glob-specific templating language
  • tying Globs to a specific programming language or web framework
  • storing Globs in XML, JSON or YAML etc
So there you have it: each Channel contains a Trail of Globs which the user can traverse from the past into the future while performing actions via the Globs stuck to the underlying Things. The speed of action, while scoring karma points, with directed focus will hopefully lead the user to a state of flow.

Wednesday, January 06, 2010

The Goo - still alive and kicking

I've spent quite a lot of time catching trains in 2009 and as a result I've had lots of time to plan the design, implementation and evolution of The Goo.

Since I started this blog there has been some convergence on what I have in mind.

The following software contains elements of what I'm planning:
  • Google Wave
  • Git
  • Facebook activity feed
  • Atom
  • Plagger
  • Plack
  • Perl6
  • PubSubHubbub
  • AnyEvent
  • Remember the Milk / ToDo systems in general
  • Starcraft
Can you guess which bits?

Fortunately what I have in mind is much less complicated than all of these systems. Ideally it needs to be programming language agnostic and so a spec or RFC is in order - followed quickly by a prototype in Perl.

Hopefully the prototype will get some way to helping users find 'flow'. Stay tuned in 2010.

Sunday, October 05, 2008

Perceptron = Goo + Blob = Glob

I'm working with Audrey Tang (of Pugs and Perl6 fame) on cleaning up the design of The Goo. One problem we identified is funky terminology which can act as a barrier to new developers.

So today during a design discussion with Audrey I decided to say goodbye to the term 'perceptron' for the more descriptive term 'blob' - but perceptrons are slightly more complicated than blobs - so Audrey suggested 'glob' as in Goo + Blob = Glob. In Perl parlance a glob is a generic handle on a thing - which fits what I'm trying to model. What's more:
Glob: 1. a drop or globule of liquid. 2. a usually rounded quantity or lump of some plastic or moldable substance
So that decided it. A Perceptron is now known as a Glob™.

Friday, May 16, 2008

Gedit - The Goo's Editor

I've finally found a text editor that does syntax highlighting, word completion and starts quickly.

Gedit with the help of the word completion plugin does what I'm looking for.

Tuesday, February 26, 2008

1 Medal = 500 Karma++

After every 500 points of karma++ you now receive a medal!

I scored my first medal a couple of weeks ago. Now it's really starting to feel like playing a game - which is all part of the plan.

I'm feeling progress being made --- which is one of the preconditions to feeling "flow".

Thursday, January 03, 2008

Sensations Snookered? - The Careenium to the Rescue

So I'm modelling conscious thoughts with 'perceptrons' and lower level thoughts with 'sensations' - which are fired automatically by 'receptors'. But at what point do sensations fire a perceptron?

If you touch something hot the sensation quickly gets upgraded to a perceptron - Ouch! Some receptors have a deservedly high priority - but what about more subtle sensations that need to coagulate and mingle before finally firing? - hmmm .... tricky.

Douglas Hofstadter conjures an amazing metaphor in his book, "I am a Strange Loop" to describe this process. He likens the human brain to a frictionless snooker table where tiny balls, called sims (small interacting marbles) constantly career into each other. Some sims bounce off each other, while others may stick together and form larger 'simmballs'. He suggests that consciousess emerges from the simms amd simmballs crashing around what he coins the 'careenium'.

I like the idea! So does The Goo need a careenium? Well currently I'm programming a 'See' Sensation to find filenames in emails, comments, web pages etc. Take this for example: Login.pm. Most of you will recognise this as a filename. The "." visual sensation, the mixed case, and the filename suffix (.pm) all combine to give this impression. But is that enough to fire a perceptron? Are there enough simms (i.e., sensations) for a simmball?

If you're a Perl programmer you will "see" a Perl module thanks to the ".pm" suffix and your mental model of what it is to be a Perl module. But this still may not be enough for a perceptron to fire. If Login.pm appears in an email from your boss, however, he may be referring to the Login.pm module that you wrote and suddenly there is a mental collision between your environment - the display of Login.pm in pixels on your screen and your internal simmball for Login.pm. Pop! And a perceptron is born -> Login.pm.

The firing process, in this example, is a combination of your current context, your memory (the trail) and the sensory forces in your environment (communicated via receptors). There's lots to do so back to implementing but for version one I'll settle for a very simplistic careenium.

Friday, November 30, 2007

Sensations need Receptors

I've decided I need to model "sensations" as well as "perceptrons" but the problem now is what picks up a sensation? Here again psychology offers some helpful terminology: receptor. Just like the receptors in the back of your retina - some sensors fire automatically in response to a stimulus. These low level sensors are important for classifying low level sensations (e.g., ___ ).

So practically speaking, in The Goo a Receptor generates Sensations which in combination with other Sensations may be picked up by a Sensor that may in turn "fire" a Perceptron (e.g., I see a red line).

Monday, November 19, 2007

Snipping The Gordian Knot

I recently painted myself into a corner with the design rule "everything must be a perceptron". The problem is that just like with human perception, events need to bubble up from their source until they reach a threshold and "fire". A perceptron is a perceptual event that has fired - but how do I model the preconditions for a perceptron to fire? I need something smaller than a perceptron.

Borrowing from psychology again:
Sensation is the first stage in the biochemical and neurologic events that begins with the impinging upon the receptor cells of a sensory organ, which then leads to a perception.

So instead of tying the design in knots trying to model perceptrons with perceptrons I've snipped the proverbial Gordian Knot and now lesser perceptual events are simply sensations that can chain sensors together to make a perceptron.

Tuesday, October 09, 2007

Do, Delegate, Defer + Divide = Smoother Workflow?

The todo subsystem is at the heart of The Goo. One of our ex-employees recently wrote:
"The job is great however I thought being involved in such a large organization there would be better procedures/communication in place! I miss the goo - esp the tutorials. You guys are certainly on the right track there."
But there's more to come! After my YAPC::EU presentation, Farley Balasuriya gave me some great feedback and said he'd recently seen similar ideas in 'Getting Things Done' by David Allen. I've since read the book and Allen makes some important suggestions - if the task takes less than 2 minutes Do It now - otherwise Delegate it to someone else or Defer it.

So in the pursuit of atomic todos I would add one more D - Divide It up. If the task is too big it can be a flow-stopper so it should be divided into smaller todos. I'm currently designing how todos will appear on your mental horizon - and the fours Ds will help you to wade through them.

Friday, October 05, 2007

giz - sticky editing

I'm going to release a small part of The Goo to CPAN before the London Perl Workshop in December.

giz is an $EDITOR wrapper that:
  • works with your existing editor (e.g., vi, emacs, nano, pico, kwrite etc)
  • helps remember where your files are located - so you can afford to forget
  • injects a special comment into your Perl code to help with keyword completion
  • can be called from a url (giz://filename=your_filename)