Since yesterday morning I’ve been feverishly bashing the poor keys on my Macbook Pro and adding new features. This might partly be down to me panicking at the thought of having to show my project in a mid-project demonstration in two weeks time, but I like to think it’s because I’ve been thinking long and hard about my database structure since my last blog post, and I’ve finally been in a position to write some code.

For posterity, when I first woke up yesterday morning, my system provided the ability to register an Organisation account (Law Firm or Mediation Centre) and to log in and out of said account. Since then, in about 10 hours of solid work I’ve managed to add:

• The ability to create an Individual account (Agent or Mediator) while logged into the Organisation account.
• Different dashboards are rendered depending on the account type.
• I’ve started building the abstract pub-sub driven framework to allow developers to create modules of business logic specific to the dispute type. This will later become the basis for my Maritime Collision dispute type development.
• The application reads a configuration file for pulling in the installed modules, meaning we can effectively have ‘active’ and ‘inactive’ modules which the admin can change at will.
• Finally, the big one – an Organisation account can create a new dispute, selecting a dispute type from the list of installed modules (so far, the only option is ‘Other’, which adds nothing to the core functionality of the system), and associating it with an Agent. This feature includes the option to view individual disputes or a list of all disputes you have permission to view.
• All of this was accomplished in a TDD way, with PHP unit tests and Cucumber/Ruby integration tests.

These functionalities are encompassed in the ‘Account creation’ pull request and the ‘Dispute creation’ pull request.

Where next?

I’m keen to get the basic ODR platform and core functionality up and running as soon as possible. In previous meetings with my supervisor it’s been clear that the emphasis is on the Maritime Collisions functionality – that is where the new ground will be covered – and that the ODR platform itself doesn’t have to look pretty. It should just work, as simply as possible.

On its own, the ODR platform is nothing special – it only replicates what already exists in the closed-source world. The special thing is the Maritime Law business logic.

That said, the ODR platform has to be abstract and extensible enough to be able to support quite a feature-rich concrete maritime collision module, so although it’s all about the maritime collision logic… it’s also a heck of a lot about the underlying platform. For this reason, I need to invest time in the design and development of the platform itself, to better support any modules the system needs to support.

My aim is to have the core functionalities of the ODR platform in place by the time of the Mid-Project demonstration, which will be somewhere in the region of March 9th-20th. I then hope to spend the rest of my time working on the maritime logic module, making improvements to the extensibility of the underlying platform where necessary, and working on developer documentation. All this alongside the Final Report, of course, which will weigh in at around 20,000 words plus appendices.

In order to accomplish this goal, I still need to add the following features:

• Assigning Disputes to other Law Firms.
• Dispute summaries.
• Dispute lifespan negotiation and re-negotiation.
• Inter-Agent communication within a Dispute.
• Proposing, accepting and declining offers.
• Mediation itself, which requires:
  • Choosing a Mediation Centre
  • Choosing a Mediator
  • Blocking inter-Agent communication, enabling Agent-Mediator communication.
  • Enabling round-table communication

These core functionalities are alongside general site UI improvements, more rigorous testing, and perhaps non-functional requirements such as server deployment and configuration, security measures (such as logging and limiting login attempts), and, if required, email notifications and/or registration.

This seems like a long and ambitious list, but it should be (and has already proved to be) easier and quicker to develop now that I’m familiar with the codebase, have laid down the foundations for routing, testing, continuous integration and so on. Another week of solid coding and I think I’ll be there.

In the meantime, I’ve ordered a whiteboard, partly out of jealousy of my four housemates who each have one, and partly because I think it will be genuinely useful in helping to plan out my system. Creately is doing a fair job at UML for my project, but I don’t think any virtual service has quite emulated a physical whiteboard properly. I guess as long as CRC cards are used in Agile planning, that will always be an indicator that technology still has a long way to go!