It. Is. Done!

The day has finally arrived – the first version of the SmartResolution project is live and the 20,000 word accompanying report is printed and bound. My dissertation is complete. I’ve delivered a three-tier system: the core Online Dispute Resolution platform, the maritime collision module, and the SmartResolution vendor website.

The first of these rivals other ODR platforms, not because it is open-source and not because it is comprehensively tested throughout, but because it is extensible. Custom dispute types can be defined by way of ‘modules’ that can be plugged into the system, a little like WordPress plugins extend the core WordPress blogging software. SmartResolution’s extensibility allows for AI-driven resolutions, saving time and money and making online dispute resolution a simpler and more transparent process.

Alongside the extensible platform is a maritime collision module defining a ‘maritime collision’ dispute type. It asks the agents domain-specific questions and interprets their answers according to the Convention for the Unification of Certain Rules of Law with respect to Collisions between Vessels. The module itself is a little simplistic, but over-examination of the maritime collision module would be missing the point, which is that the core platform supports any arbitrary module. Modules can be as big and complex as time allows.

Modules are supported via a SmartResolution Marketplace, hosted on the SmartResolution website. This marketplace is viewable from within the SmartResolution installation itself, allowing administrators to install and activate modules with ease, much like WordPress’ plugin directory. Any modules that don’t exist (let’s be honest, there aren’t many modules there yet!) can be developed in-house by following the detailed developer documentation.

The 10,000 lines of code developed in this project, alongside the report, has been a substantial effort of work totalling around 400 hours. I’m proud of what has been achieved and am glad to finally consider it a ‘finished’ product.

I invite you now to read the accompanying report, which I’ve spent the last month writing and refining. Thank you for following my dissertation diary.

• Posted in
  • Dissertation
• No Comments
• Read more

Completing the Core

Finally – it is done. The core ODR platform, as of Sunday 29th March, is more or less complete.

I had hoped to get to this point quite a while ago, initially by Friday 13th, before mid-project-demo week. I then postponed this to Tuesday 17th, which was the day of my demo. At this point I still needed to add mediation – and hoped to have that done by the end of the week (Friday 20th), then Sunday 22nd (which I still classed as “end of the week”), then middle of the week (Wednesday 25th), then end of the week. And here I am.

I’m surprised that it took so long to get to this point, and I’d like to briefly examine the reasons why, especially as I actually managed to negotiate some simpler requirements (removing formal resolution “offers”, etc) to help reach my deadlines.

It is partly down to my busy schedule: company work, company administration, family, friends. However, there must be more to it than that.

I believe that coding in a test-driven way has slowed me down – not cripplingly, but by a pretty significant margin. Having to write integration and unit tests, fix them when they break, wait several minutes for Travis to build my project and inform me when things have broken, having to refactor my unit tests when I refactor my codebase – these have all factored into a more drawn-out development process. As an estimate, I think I probably would have been at this same stage a week ago (22nd) had I not disciplined myself to write tests throughout.

Of course, there’s no way of knowing how much time I would have spent manually testing, and fixing complicated bugs that start at one point and proliferate throughout the system. It is very possible that, without tests, I’d be even further behind than I’d like to be! Regardless of time, I’m very, very happy to have this collection of tests that cover every aspect of my codebase. I can refactor hundreds of lines of code and automatically validate that everything still works. The development overhead on writing tests is easily worth it for the ability to code with no anxiety.

That aside, TDD isn’t the only culprit for a bloating deadline. The stakeholders added things to my initial requirements, such as a file upload facility, the ability to view user profiles, and so on. Occasionally I’ve also added my own self-imposed requirements, such as automated AWS deployment. Each requirement adds at least a day to the development phase.

Finally, it’s worth re-iterating that this is a pretty major project! In the past I’ve worked on small, self-contained features for the BBC, or personal web projects which are, again, quite small in scope. Developing a fully-functional, BDD-driven, enterprise-level piece of software as a single developer is hard. Perhaps I underestimated the difficulties of actually implementing the code, even with a pretty well thought-out up-front design.

I should keep in mind that what I have so far is an achievement to be proud of (this is echoed by the 91% I achieved in the mid-project demo). I didn’t meet my arbitrary deadline, but what I’ve built so far is a worthy major project in itself, even before introducing the other exciting components I hope to introduce. I must be code-complete by 25th April; it’s the only way I’ll have time to write a thorough enough final report. This gives me just under four weeks to accomplish as much as possible.

My wish list for the next four weeks

This is what I hope to accomplish, in rough priority order:

• A prototype of the maritime collision module, and, by implication, developing the underlying platform to provide hooks and be fully extensible, and the corresponding developer documentation. I think this part is the most important to achieve, as it is what will set my platform apart from the other (proprietary) ODR platforms that already exist. The AI logic in the module doesn’t even have to be very clever. What I’m hoping to provide is a “plausible promise” – something that gives a non-technical person a fair idea of what the system is capable of, and gets them excited!
• As part of this module development, I hope to develop a WordPress-inspired admin panel so that the SmartResolution administrator can create an admin account, log in to the system, and install/uninstall/activate/deactivate modules through an admin dashboard. What I hope will follow on from this is a SmartResolution Marketplace. The software will communicate with smartresolution.org and allow the admin to download and install modules from the marketplace, to the SmartResolution software, through the software itself. To begin with, the marketplace will have the maritime collision module and one or two simple test modules. Later on, this would contain both free and proprietary modules, and is ultimately where SmartResolution developers could make money.
• Tying up various functional loose-ends, including the ability to download a “dispute report” at the end of a dispute, to manually verify that the mediator did not break any confidentiality agreements in their discussions with the other agent. I also need to implement basic housekeeping stuff, like email validation, the ability to restart the mediation instigation process, and so on.
• The site could do with sexing up a bit. Early ideas:
  • JavaScript countdown timer on dispute dashboards, counting down each second to the start/end of a dispute.
  • Progress bar timeline on dispute dashboard, showing at what point in the dispute lifecycle mediation was proposed, dispute was resolved, etc, and giving an even more visual way of showing how much of the dispute lifecycle has elapsed.
  • Icons on the dispute list page, showing at-a-glance whether a dispute is open, closed or in mediation.
  • AJAX-loaded notifications, like on Facebook, and notifications that “go grey” rather than disappear entirely.
  • Paying attention to detail and deliberately making the site fully responsive.
• Then there are various developer-centric improvements, such as adding Javadoc-style comments where appropriate, creating and making publicly available various class diagrams, improving the back-end directory structure (as the number of models has grown substantially), setting up cronjobs to poll the server at set intervals, and so on. You might argue that these are more important than the front-end improvements outlined above, but even at my age I’m aware that a good-looking site builds trust and credibility. People won’t use a naff-looking site. They’d sooner have a visually appealing, parallax-scrolling site with little substance than a robust, backwards-compatible site that looks a little dated.

I’m particularly interested in the marketplace integration; my entrepreneurial eye has been very much caught by this. However, I committed to the maritime collision AI at the beginning of this project, and the modular platform is what makes my software stand out from the crowd, so I’d be mad to overlook that.

This week I’m hoping to do 2-3 days of BBC work, and next week I’m in Durham with my girlfriend for Easter, so my not-quite-four-weeks remainder of coding time is already looking strained. I will try my very best.

• Posted in
  • Dissertation
• No Comments
• Read more

Mid-Project Demonstration

I had my mid-project demo on Tuesday. Those following my blog will know that this has been at the forefront of my mind in recent weeks, and my aim was to have the core ODR platform finished in time for the demonstration.

This was somewhat ambitious, and other commitments (work, company administration, friends and family) have meant I haven’t been able to invest much of my time in the project for the past week or so. The situation is unlikely to improve anytime soon – I’m currently on a train to Manchester for a friend’s birthday, followed by a train to London for an interview. When I come home, there will be a large family reunion spanning several days, and then I’m off to Durham with my girlfriend’s family for Easter.

The deadline has not been helped by bloating requirements (the platform now needs to support document uploads and management). All of these factors meant that my platform was lacking the mediation functionality by the time of the mid-project demo. However, the demo went well and I’m expecting my marks in the next couple of days.

I hope to have completed the core platform by the middle of next week. This leaves me with roughly four weeks to work on the Maritime Collision module, which I now intend to be more of a prototype suggesting what the system is capable of, rather than a fully-functional and well-tested module. You see, not only will I be developing the module itself, but I’ll also need to start emitting events and exposing other API hooks from the underlying platform itself, so work on the platform will be far from complete even when the “core” functionality is ready.

I’ve tried to budget in a solid week for refactoring, before the beginning of the maritime collision module work. The lack of big design up-front (BDUF) and my agile approach to implementation has led to some inconsistencies in the codebase (e.g. some functions that create new rows in the database return the corresponding ORM object, others return the ID representing the object, and other return nothing at all) that I’d like to standardise. As I’ve been working in a BBD and TDD way, I have a suite of unit and regression tests that I can run to validate the full functionality of my application, so a well-thought-out refactor should not be too difficult to perform.

Finally, I hope to have a full two weeks to work on my report, and I’m aiming to finish my project and report with a week to spare, to tidy up any other loose ends. Given that the project deadline is mid-May, I’ve allocated all of the time remaining in my project, which leaves little margin for error!

It makes sense to allow time for the report, since it and the technical hand-in are worth 70% of the dissertation (and I know of many assignments where the lecturers only read the report, never running the program). So, time to get back to coding!

• Posted in
  • Dissertation
• No Comments
• Read more

Commercial viability

I’ve been thinking about the commercial viability of my project.

As a result of using the Fat-Free Framework, my project is forced to adhere to the terms of the GPLv3 license, which stipulates that if I distribute my software I must make the source code easily available. In theory, this shouldn’t force me to go open source. As my project is web-based, I am within my rights to deploy my code to a server, and any users of a website that uses that code do not have the right to access the source code, since I’m not deploying the program itself to them: only the results of the program. The AGPL license would be a different story, as it closes that loophole.

Nevertheless, I’ve chosen to make my project open source. Why? Well, partly because GitHub charges for private repositories, and all of the CI tools that I’m using in my project (Travis, CodeClimate, Gemnasium) are free for open-source projects, but charge money for private repositories. In addition to all this, I want people to be able to follow my progress. I want something I can show future employers. I also found it very useful to be able to show my supervisor my feature files so that they could be double-checked and signed off.

All these reasons led to me open-sourcing my project: but does that hinder its commercial viability? One’s instinct is to say “yes” – if people can download, modify, run and re-distribute your software for free, why would they ever want to pay for it? I believe my project does hold commercial promise, and the reason came to me while I was trying to plan out what I would say in my Mid-Project Demonstration, which is happening this time next week.

Where is the cool stuff?

I feel I have to justify the amount of time spent building the core ODR platform. After all, the exciting bit about my project, surely, is all about the maritime collision logic; the AI and the neural networks and the natural language processing that form the virtual court simulation and replace the physical court. That’s some pretty awesome stuff right there.

Though the maritime collision logic is seemingly the exciting, ground-breaking stuff, there’s also been a heavy emphasis on keeping the underlying system as abstract as possible, so that any module of business logic can be plugged into the system. And that, ladies and gentlemen, is where the truly exciting stuff is.

The core ODR platform is a large, extensible, robust and skilfully constructed framework. It needs to be, if developers are to have any confidence in building plugins for it. After completing the core platform, I expect to not have all the time in the world to work on the maritime collision module. I hope that, through the module, I can at least develop a plausible promise as to what the system is capable of. The maritime module is a prototype, a placeholder… something that other developers can spend a lot more time expanding upon in the future. The real meat of this project is in the underlying platform.

The analogy I’m hoping to use on Tuesday is this: the ODR platform is like WordPress. The Maritime Collision module is like a WordPress plugin. The former is, by necessity, a huge, well-tested framework which has had contributions from hundreds of developers. The latter could be as large in scope as the former, or it could be a one-script plugin that scratches a lone developer’s personal itch. Both can be developed independently of one another.

Investigating the WordPress pricing model

I realised that my project could learn many lessons from WordPress. Both projects do completely different things, but I can utilise and copy certain things like how WordPress fires events that plugins can be hooked into, and how it allows site administrators to easily install, upgrade and uninstall plugins directly through the admin dashboard provided. But going beyond the software level, I can also learn lessons from how WordPress makes money, and why they continue to do what they do.

With all the goodwill in the world, WordPress would not continue to be developed if money wasn’t being made somewhere. So where is it made? WordPress itself is free to download and install on any server as you wish. You can even save yourself the effort of doing that, and create your own WordPress subdomain directly through wordpress.com, at no cost.

The truth is, there are a lot of companies making a lot of money off the back of WordPress, and I’m sure some of the WordPress contributors are getting in on the action themselves. Developers can create plugins and themes, and though most of these are free, many of them are not… and some of them are really rather expensive.

WordPress is covered by the GPLv2 license, which is similar to the license covering my project. The genius thing is, WordPress plugins and themes are not confined to the terms of that license, as they are self-contained units of work that “just happen” to slot into the core WordPress platform and extend aesthetics or functionality. They are not modifications of the platform itself. This means that they can stay closed source, and therefore give people a reason to pay for them.

How this can be applied to my project

I think that keeping my ODR platform open-source is a smart move. Anyone is free to download the project, install it on their own server, and even start charging money for their online dispute resolution services. I think it’s also a good idea to make the maritime collision module free, and perhaps a handful of other dispute type modules too (such as divorce cases, unfair dismissal claims, etc), to make the system more useful and show people what is possible with the core platform.

If I were to continue with the project beyond university, my plan would be to develop even more dispute type modules: say, tenancy agreement breaches, slander, etc – and to charge money for these modules. Anyone would be able to set up a website with the core platform and some dispute types for free, but to rise above the competition and have the most comprehensive ODR system, they’d have to pay for additional modules. Think of it as The Sims’ expansion packs!

Building my brand

WordPress is as big as it is today because not only is it open source, but it is also a household name. It has built up a reputable brand and is now the market leader in blogging software. My ODR platform clearly needs an identity.

As a placeholder, I created a logo a couple of weeks ago, entitled “SmartResolution”. It seemed a fairly good and appropriate name: my platform offers online dispute resolutions, but in a smart way, i.e. input analysis and a heuristically-driven suggestion as to the outcome of the dispute.

Today I bought a domain name to help reinforce that branding: smartresolution.org. At the time of writing there is nothing to see yet, since I have no server – but I intend to set up AWS integration in the next couple of weeks so that I can easily and automatically deploy the latest version of my project to a cloud server, accessible through smartresolution.org.

I’m not expecting to make money from this (for a start there are other issues I haven’t discussed, such as my project technically being the property of Aberystwyth University), but at the very least it is an easy way to give my supervisor and stakeholders access to the beta version of my project. I’d like to develop my project as if it’s going somewhere, because if I don’t, it never will.

Other updates

That’s it for this blog post, but here’s a quick list of the project functionalities added since my last post:

• Lifespan negotiation and re-negotiation.
• Communication between agents within a dispute.
• Various refactorings, including using the state pattern to significantly tidy up my business logic.
• A one-step install script.
• Better overall tests and code structure.

• Posted in
  • Dissertation
• No Comments
• Read more

Following a plan

Last semester we learned a lot about agile practices. It stressed the importance of being able to embrace change, deferring the design decisions until the last possible moment so that they can be made in light of the experience gained through spike work, talking to the on-site customer, and so on.

The idea of agile is that the cost-of-change curve is made shallower. Customers are happy because it’s never too late to tweak a feature, and developers are happy because they’re not expending lots of effort into writing up requirements specifications, designing UML diagrams, and the like.

Numerous examples were cited of high-profile, multi-million pound software systems going exponentially over budget or failing to deliver at all, as a result of following the antiquated Waterfall model. We laughed at the suggestion of using a BDUF (big design upfront) methodology in our major projects: we were now agile developers and could nimbly build incredible systems without being held up by dull and costly processes such as documentation.

However, we should be able to adapt our choice of methodology to the project at hand, not the project at hand to our choice of methodology. And, looking at my project impartially, I think it really is best suited to a more plan-driven approach.

Heresy!

I can hear your metaphorical gasp, but let’s look at the facts:

• I’m building an Online Dispute Resolution system. Other systems like this already exist. Until it comes to the maritime collision logic, my codebase won’t be breaking new ground or reinventing the wheel. There’s already a bunch of fairly straightforward features that can be formalised in advance to be taken into account in the design.
• There’s a heavy emphasis on law and following processes correctly: my system cannot be seen to be favouring one party over another. It is absolutely essential that my system does not violate any of the rules of ODR – and therefore it is essential to document these rules in the requirements specification, for traceability and accountability.
• I have a law contact (Konstantina) who I am able to meet perhaps once every two to three weeks. This is not nearly often enough to constitute as an “on-site customer”. It’s not even often enough to meet and prioritise user stories, since even when we do meet our time is limited and there are other items on the agenda to discuss.
• Finally, the process of gathering requirements, creating a design, and implementing and testing a substantial software system is still somewhat new to me. I have experience through freelance work I’ve done through my company, and through various projects at the BBC – but having a design and a plan is a comforting safety net.

The above points don’t disqualify agile practices from my project completely. I’m very keen on the agile principles of TDD, continuous integration, regular releases and merciless refactoring, and am actively applying these principles (with the exception of regular releases, which I’ve not had time to investigate at this stage in the project).

Thus, my approach is a hybrid one of Waterfall and Agile: I have a requirements specification through Cucumber features, use-case diagrams, etc, and some up front design such as the database schema; for the implementation I’m switching to a business-driven, test-driven approach that utilises the best of the agile processes (but are not mutually exclusive from the Waterfall model).

Development Methodology versus Project Management

So far I’ve been speaking about my choice of development methodology, each of which has a traditionally associated project management approach. Waterfall projects tend to use gantt charts to plan progress, whereas agile approaches tend to use sprints to plan individual iterations. As I’m using a hybrid development methodology, should I be using a hybrid project management methodology?

My project management approach so far has been somewhat ad-hoc. I’ve been using my own installation of JIRA to plan collections of features to be completed by arbitrary deadlines, and GitHub issues to document other things that need to be added but are not of an immediate concern (essentially my product backlog).

Apart from a goal to have the core ODR platform ready in time for the mid-project demonstration (after which I can concentrate solely on the maritime collision business logic module), I have no specific milestones. Then again, if “Have features X, Y and Z ready be the 5th March” is not a “proper” milestone, what is? How does translating a JIRA ticket to a sprint or a gantt chart make the milestone more “real”?

Admittedly, it’s been difficult to monitor progress using JIRA alone. Without looking carefully at my git commit history, I couldn’t be much more specific than “I started coding roughly three weeks ago, and now here’s where I’m at.” Dividing my work into sprints would let me easily say “I’m at version 0.7, and last week I added the following features.” It’s difficult to measure my velocity using my current approach as it means I have nothing to feed back into future ticket deadlines other than my own estimates.

I’d have a ticket saying “Finish feature X, Y and Z”, but the deadline would arrive and I’d only have completed feature X and half of Y. I’ve now improved my JIRA approach slightly be setting more self-contained, achievable goals: “Feature X” by one deadline, “Feature Y” by another. These are single units of work that can be encapsulated in their own branches and merged with the master.

A higher level overview of my project timeline, in the form of a gantt chart or sprint plan, could prove useful and give me an early warning if I’m going off track in terms of hitting my project milestone. I recently bought a whiteboard, so may end up using that before making a digital copy for the purposes of my final report.

Project updates

With my development methodology explained, and my project management approach at least touched upon, here’s a list of what I’ve been up to:

• Met with my supervisor and Alex last Thursday and showed them the first prototype of the system. They seemed happy and impressed with my progress.
• As a side note, it’s taking me quite a long time to add features whilst still keeping the system thoroughly tested. I had expected this to speed up once the underlying framework and utility functions had been sorted – but that’s for another blog post.
• Since last Thursday, I’ve added dispute summaries, refactored the system and added tests, and am currently on a train back to Aberystwyth (having been in London all week), halfway through creating the Lifespan Negotiation feature. I hope to have this and the Lifespan Renegotiation features finished today.
• Tomorrow I’ll work on Inter-Agent Communication within a Dispute.
• On Saturday I hope to add the “Choosing a Mediation Centre & Mediator” functionalities.
• On Sunday I hope to sort out the communication aspects of mediation (i.e. Agents A and B cannot talk to one another until Mediator proposes round-table communication, etc).
• I’m planning on automating deployment to AWS as my work for Monday, giving stakeholders access to a beta version of my ODR platform through an IP address.
• Anywhere from Monday 9th until Friday 20th March I could have my Mid-Project Demonstration. Assuming a midpoint of Monday 16th March, I should be in a good place in terms of project completion, with the core ODR platform complete. I can then concentrate on the exciting bit: the maritime collision module.

• Posted in
  • Dissertation
• No Comments
• Read more

Cooking on gas

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!

• Posted in
  • Dissertation
• No Comments
• Read more

Choosing a BDD framework

My plan was always to use behaviour-driven development in my project. In an earlier blog post I talked about how I’ve used my supervisor meetings to clarify requirements and translate these into features. At this stage in the project I now have a bunch of signed-off features, all of which can have an automated test associated with it.

These features are written in Gherkin syntax, i.e. Given, When, And, Then, and I had always planned to use Cucumber to make these features executable. Many flavours of Cucumber exist: it was originally built for Ruby, but now there are other variants such as CucumberJS (JavaScript) and Lettuce (Python).

Given that I’m writing the business logic of my application in PHP, it would make sense to use a PHP equivalent of Cucumber. The most popular of these is Behat. All of these BDD frameworks I’ve named thus far do much the same thing: they allow you to parse features written in Gherkin syntax, write the corresponding step definitions and therefore run your features as a higher-level test.

Matthew Daly’s blog post about testing PHP web applications with Cucumber discusses Behat as a possibility, though he opts for using Ruby and Cucumber because:

• He cites RVM as being a useful tool for running multiple instances of Ruby.
• RubyGems makes it easy to install Cucumber’s dependencies.
• The Cucumber community appears to be very active, which suggests that using Cucumber over something like Behat would be a safer investment of time.
• Why not? He finds little “problem switching context between writing Ruby code for the acceptance tests and PHP code for the application itself”.

I looked into Behat and found that, for me, the biggest reason to stay away is its syntax. Behat requires that you define your step definition as a concatenated function name, i.e. “Given I am in a directory” => “function iAmInADirectory”. You also need to comment above the function declaration with metadata. This is the example in the Behat quick introduction:

/**
* @Given /^I am in a directory "([^"]*)"$/
*/
public function iAmInADirectory($argument1)
{
throw new PendingException();
}

This just isn’t as clean as vanilla Cucumber and Ruby:

Given(/^I am in a directory (.+)$/) do |argument|
# pending
end

I see nothing wrong with highlighting the fact that my application and my BDD testing framework are independent of each other by using different languages for each. As a software engineer, I’m simply using the best tools possible for both jobs. As a bonus, using Ruby & Cucumber for BDD discourages coupling: if I were to use Behat, it would be possible to come up with awkward hacks like directly including PHP classes from my application as part of the integration tests, which is just plain wrong. And it certainly doesn’t hurt that I’ve already got quite a bit of Cucumber experience, albeit in a Rails assignment at university.

With my decision justified, I’ve started writing my Cucumber integration tests, yesterday getting my first one to pass locally. Hooking up to Travis is proving to be a bit of an issue, as the Cucumber tests require a PHP server to be running so that the application can be rendered and tested (but Travis only supports one shell window at a time). I’m hoping to crack that today, then work through the step definitions for the rest of my features.

• Posted in
  • Dissertation
• No Comments
• Read more

Reading

Today has been a day of reading. Online Dispute Resolution has been around for a number of years, and has implications for the academic and scholarly world of law and politics. Naturally, there are a number of publications and journals around the subject, which I am beginning to work my way through.

I’m using Mendeley as my bibliography management tool, because it has:

• A nice interface, instilling much more confidence in me than its decidedly rougher-around-the-edges and chavy-sounding rival Citeulike.
• A built-in PDF reader with highlighting and annotation tools
• A cross-browser bookmark allowing me to add things to my bibliography as I come across them on the web
• The ability to export BibTeX references for LaTeX documents
• The ability to export to Microsoft Word (handy, as I’m currently undecided on my document building tool. Life is often too short for LaTeX).

It’s been interesting reading the early reactions to ODR, as in J. Goodman’s The Pros and Cons of Online Dispute Resolution: An Assessment of Cyber-Mediation Websites. Written in 2003, it refers to a number of the market leaders of the time, referencing URLs that no longer exist. Although it might be expected for some (or even many) of these URLs to 404, it’s humbling and worrying that a number of the domains for the top ODR companies of 2003 are now parked and riddled with pharmaceutical advertisements.

I’ve also been busy working on a new branch for my repository, as three weeks has been an uncomfortably long time to not write any code for this project! I’m still keeping myself disciplined, trying to clarify requirements and come up with a coherent design before hacking away at any code, but I thought it was worth exploring the usefulness of some frameworks through some spike work.

Stay tuned for my next blog post to read about my findings!

• Posted in
  • Dissertation
• No Comments
• Read more

PHP Frameworks

A recent blog post had me trying to find a good base structure for my Online Dispute Resolution platform. I looked at a few possibilities, none of which were really appropriate. I decided to try taking a more modular approach, using libraries to handle things such as authentication but building my system in an abstract way to enable swapping out modules if necessary.

Large frameworks such as Zend and CakePHP are very constraining, requiring you to stick to their idea of what is the best development approach (specific directory structures, MVC design pattern, and so on) or else perform some very heavy, non-standard configuration to make it suit your project. I’m sure either of these heavyweight frameworks would be perfectly well suited to ODR, but generally speaking I try to stay away from non-transferable frameworks. I like to understand exactly how my application works, rather than delegate that understanding to a third-party library. And I like having the freedom to change frameworks painlessly at a later date – something which is NOT suited to heavyweight frameworks!

I considered a few of the lighter options: Huge, Opauth, Laravel and Fat-Free Framework. Huge looked promising to begin with but then appeared to be more of a middleweight framework, strongly encouraging but not requiring you to follow certain directory structures. It would be a base that I would have to build on, rather than a library that I can plug into my system, only calling it as and when I need it.

Opauth looked nice and lightweight, but was aimed at projects which want to use OAuth for authentication, allowing people to sign in using their Twitter, Google, LinkedIn or Facebook account. This was not suitable, given my project requirements. Laravel was the next one I looked at, and looks a little like PHP’s answer to Rails as it generates an entire application structure through a proprietary command.

I’m sure that any one of these libraries is a suitable starting point, and I know that there are thousands more in existence. It would be impossible to spend a long enough amount of time evaluating every framework that one could make a truly considered decision.

Fat-Free Framework

The most promising framework at first glance was Fat-Free Framework, or F3 as it is commonly known. I found it had a low learning curve and an unconstraining nature. Its modular build means that I can cherrypick the elements of functionality I want, rather than go for an all-or-nothing installation. Interaction with the library is through calls to namespaced classes. F3 is fundamentally different to its competitors because I can slot F3 into my code, rather than slotting my code into F3.

This work was supposed to just be some spike work, but I must confess I’ve now invested around 5 days in seeing how well I can utilise F3 for my project. At this stage in the project, I’ve managed to set up user registration (with back-end support for multiple user types) and login/logout functionalities, developed in a relatively test-driven way (though I plan on writing more unit tests to make my current codebase more robust, as well as Cucumber acceptance tests).

It wouldn’t be too late to turn back now and opt for a different framework. I daresay I’ve built many transferable components, such as the SQL database structure. But I’m very happy with how it’s going with F3 and I intend to keep going with it, despite not having looked at the other frameworks in a lot of detail.

You could argue that I’ve stumbled into my framework decision – but let’s go back another step and you could also argue that I stumbled into my choice of programming language. These days, most languages can be run on the server-side, so there was nothing stopping me using Ruby (with Ruby on Rails), Node, or Python. What made me go for PHP?

PHP is still the most popular server-side programming language worldwide, and, more importantly, it’s the server-side language I have by far the most experience using. I could have spent a few weeks learning the ins and outs of C# and .NET to deliver my project, but given I have so much to build (remember the 5 incremental deliverables outlined in my Outline Project Specification), I didn’t want to find myself desperately trying to debug an obscure error in a new language a week before the deadline.

I think PHP and F3 are the right choices, but I hope in the coming weeks I can justify my decision with something a little stronger than just “it was the easiest way to get started”.

• Posted in
  • Dissertation
• No Comments
• Read more