Square Pegs and Round Holes #2

I’m sure you’re all on tenterhooks wondering how things have been going since my last post on this subject?

No?

Tough. I’m going to tell you anyway. If nothing else, it helps me clear my head and check what I’m doing.

To start with, not a lot happened – other things got in the way. Then I got down to creating the DB architecture, and then refactoring the DB architecture as I realised I was making it way too complicated. The core business data is now in 5 tables.

Then I got down to work with Code Igniter and Ocular – always a good starting point, if you ask me. I’m developing pragmatically, capturing the major requirements first, and things are moving on apace.

Today’s major task will be importing over the libraries and helpers I haven’t already taken (from our other Code Igniter based projects). I need to do this in the office just in case I need to ask about their integration; I can’t be left trying to work it out for myself over the weekend if things don’t pan out right.

Once the libraries are imported and working, I’ll continue building the business logic into the models based on the prioritisation of the features.

I need to leave myself a good 3 – 4 hours to ‘prettify’ the application, but I’m marking it all up with HTML ids and classes, so that shouldn’t be too bad.

Finally, on Monday, deploy to the Staging Server and make sure the DNS is hitting it. (Which reminds me – must get the DNS names sorted out tomorrow.)

Later,
Ady

Square Pegs and Round Holes

A round hole in a wooden plankThis post is more of a brain dump than anything else; just a place to put my thoughts.

I’m currently architecting the ‘cluster manager’ application for the EuroPetitions EU project that we are a part of. This is a fairly easy piece of work, a simple dashboard with some APIs through to external ePetitioning systems.

Ideally, I want to use the flexibility that our CitizenScape product provides, but ‘widgetising’ the cluster manager in order to incorporate it seems like a lot more work than necessary. The proper way to do it would be to create an external cluster manager application and then provide a widgetised version to CitizenScape. The alternative is to incorporate the code for managing EuroPetition clusters into CitizenScape. Here are the plusses and minuses, as I see them, to these two approaches.

External Cluster Application

Plus:

  • Appropriately architected
  • Easier development / maintenance, particularly where multiple developers are involved.

Minus:

  • Potential integration issues
  • Widgetisation may limit how the cluster manager can function
  • Time constraints (this has to be done in 15 man hours – and counting)

Cluster Manager in CitizenScape core

Plus:

  • Can use existing core code / helpers / views / templates – should reduce development time

Minus:

  • CitizenScape code muddied with non-core functionality
  • CitizenScape database schema muddied with non-core structures

Conclusion

Much as I hate to say it (due to time constraints), I’m going to do it the proper way. I can’t imagine that this application will not run for a long period of time and I need it to be easily maintainable. So here’s what I’m going to do:

  • Create the cluster manager as a new application / schema
  • Develop the ‘business logic’ / models in full
  • Create an API controller and views to supply widget-compatible snippets to CitizenScape.
  • Create the CitizenScape widgets to incorporate EuroPetition cluster management into the CitizenScape platform.

Right, now that that’s sorted, I’d better get on with it…