Tuesday, 4 February 2014

Xizi under Conclave - Status

The porting of Xizi to Conclave began over Christmas and I am really pleased with the progress so far.

The basic behaviour has been produced using the functional decomposition favoured by the Conclave framework and this has enabled me to start a more rational API for it than my original prototype.

As of now, I have written two of the primary database API calls - Create and Read which are working nicely. Along the way I added a compressed JSON view (implemented in the Asura support library - I had to keep that name going somewhere :) ) which should help for medium and large application databases. I will add the Update and Delete calls soon, then expand the scope to Collections and Instances.

Yeah, I hear what you're asking; you're wondering wtf Xizi actually is. Well, I'll tell ya.

Xizi is an application data storage framework. It's primary use is to allow app developers to use a common method for storage of structured, meaningful user data with some search and trigger/agent facilities. The flip-side of that is it allows a user to view all of their data within one interface (i.e. via the website or Xizi's own app). Each app maintains a separate social graph per user so that the user is in control of their own network and in charge of how that graph is accessed and cross-linked between their apps. The information that a user adds to their database can be set to public or private, allowing discovery of items that the user specifically chooses.

<pitch>

  • Xizi: Your data. Your network.

</pitch>

(I took the rest of the day off after I came up with that.)

The current worked example is a Fitness/Exercise recorder app with social elements. I'm still playing about with Xamarin (which is ridiculously slow when using an emulator), but I aim to produce an Android version of the app in the next couple of months, all being well.

Saturday, 9 November 2013

Xizi and Conclave

Just recently, my ex-boss Guy Murphy has released a candidate version of his behaviour-based micro-framework which comes from the same stable as Asura. As a porting exercise, I have decided to write the new version of Xizi using it as it favours functional decomposition in a way that Asura framework currently does not.

Guy's git-hub repository for Conclave can be found here: https://github.com/guy-murphy/Conclave


Saturday, 19 October 2013

API Separation and Everything After

Well, something else did crop up, and here I am again.

After far too much hand-wringing, I finally separated the Xizi API from the main hosted website and into its own silo.

But this is just treading water.

What I really want to do is two-fold;

One - Now that I know roughly what I want to achieve with Xizi, I feel that I should re-write this from scratch. The implementation is too complicated for what it actually should be doing.

Two - The more I work with the Asura framework, the more I wish that I'd made some different design decisions earlier on. The way I have implemented the behaviours does not lend itself well to functional decomposition and that's starting to drive me a bit mental as I have to change gears between different behavioural systems.

And there's not much point doing one without having done the other first for the sake of duplicated effort.

So, I'm going to re-write Asura.

Back in a bit.

[Gone coding]

Sunday, 14 July 2013

And... we're back

After a long stretch of working on a related side-project, I'm back and working on Xizi until something else rears its head. In truth, working on the other project has been incredibly useful in that it uses the Asura framework and this has given me experience of building a complete website with it, including interactive elements, asynchronous calls and discovering a new love ... Twitter Bootstrap.

Bootstrap, it feels like cheating. It's having as much of an effect on my view of front-end web development as learning model-store patterns influenced the way I architect application internals.

So, recent work has included improving the demo app, support for retrieving application details including auth tokens for users and available subscription events, support for themes in the template handler, default and user override parameters for an application for the condition engine, creating a user from an application, making Xizi.Client more robust by avoiding use of query strings where possible, making sure timeline events are spawned during test data setup, various bug fixes and  remembering to add an update method for users :)

A whole bunch of things were ported in from my work on the other project, partly to do with front-end support - so themes, for example - and partly a big refactoring job which split the Context class into a basic base class and a web-related descendant class. The latter was due to requiring a job processor in the other project and I knew from recent experience that I could make that behaviour-based pretty easily.

Well, I'm stuck on train right now, so I'll get some other stuff done...

Monday, 6 May 2013

Progress report

It's amazing what a little bit of CSS can do to spruce things up a bit.

I've started making the Xizi web pages more presentable and it turned out that it wasn't so hard to do.

Here's the login page:

(You'll never guess where I got the font from)
And a user's homepage:

(Placeholder graphics for now)
You will perhaps notice that the FitnessApplication box shows a list of events that have occurred. This is an implementation of a timeline style history record that will be accessible if required. In this case, the timeline records are created by a Subscription Event that fires when an Instance is added. I wrote the event in a stored IronPython script, but it could just as well be in a .Net assembly too.

Along the way I fixed a few things and created a bunch more. Xizi.Client now transfers parameters via HTTP headers rather than on query string, as a date written in Universal Time was somehow getting a plus-sign stripped. As a part of that, all HTTP headers are now added in to the Asura.Web Context object as parameters automatically. I've also added a new Request behaviour - PreRender, which makes sure things like the User object are added to the Context.ControlState automatically and so will be available to the Razor templates.

Very pleased with progress and it's great to have something a bit more visual to work with.

Friday, 3 May 2013

MongoDB search revisited

Well, Iceland was shit (ContextBot: chest infection, bad hotel location, misanthropy, expense.)

Anyway, moving on.

Re-written the Search function in the MongoDB store to split up the search criteria into separate ElemMatch queries after realising that I had failed to process multiple conditions correctly. By using this I now have a basic little form application for the FitnessApp idea that uses Xizi to pull back user's Instances that are within a 10% tolerance of entered values for newly entered running time and distance combinations.

I finished that in the departure lounge, while the plane was starting to board for London.

Most fun I'd had all week (*)


*: Apart from the tapas meal. That was awesome.

Wednesday, 24 April 2013

API Rewrite #5 and Agents

Some time later... I emerge from performing API re-write number 5. It's all @uatecuk's fault. He persuaded me to split up the databases into separate Mongo collections for each level down to Instances. Previously, I had managed to get search working with a Map-Reduce operation to cut out bits of Databases that I didn't need, but this was essentially running the query twice - once over all an application's Databases, and then again over the reduced set of data which had matching Items in order to reduce the data. Now, I have search working with just a Mongo query, and no Map-Reduce operation. This is a shame because I actually thought I was understanding Map-Reduce, slightly, though it is very likely I am mistaken as it was probably leading me into a false sense of confidence and security before koshing me on the back of the head.

A second thing... I have managed to write an initial Agent using the embedded IronPython script engine. This has access to restricted parts of the database (restricted by interface), and this has led me to produce a scheme for loading and saving state. This all appears to work so far and the fledgling Agent can save its current work, perhaps for processing later. I'm not sure yet what restrictions to place on the timing of Agent execution. Maybe none. Certainly, aspects of this will be rolled into the connected API events, which will have access to the same storage items.

Right. Must sleep. Off to Iceland for Eve Online Fanfest 2013 tomorrow. \o/