Artivio - The Making of - Overview

Artivio is project I made that I will launch for private beta in the next month. It is mostly a CMS for artworks: pictures, metadata, search... nothing more than this for now, but I'm actually quite satisfied of the state of the project, form different reasons:

First, Artivio now does well what it does. It's still basic but already useful and it works fine.
Second, the "platform" that is emerged allows me to create a new similar site with reasonable low effort and with a well defined architecture.
Third, the status of the code is quite good including a good automated test base, allowing me to make modifications quickly.
Finally I've been able to successfully apply a lot of technologies and techniques that have proved to work.

The Making Of

Artivio is a made with many open source technologies, a few I master since some years like Wicket, other that I became expert during the last year: Restlet, OSGi, some JMS with ActiveMQ, MongoDB. Also, For some of these technology there is something I want to talk about and I'll promise here to write these articles:

  • JMS: event based in-app communication
  • Wicket: automatic form panels generation from XML
  • OSGi and Karaf: light war deployment
  • Restlet: light web frontend and REST API backend.
  • MongoDB: integration with Elasticsearch (so, Lucene)

I've already written the article about Wicket so I'll probably publish that first, and there is already a generic introduction to the Event Based Application (1)

Also, Artivio now is a lot more "cloudified": lives on a Amazon EC2 instance, stores pictures on S3, the database is hosted at MongoHQ and the User Administration is delegated to Pipelean Accounts (2) that offer a per user authentication, authorization and OAuth connection with third party services.

Code Quality

But today is Sunday and I'm spending some time making project cleanup (mainly removing unused classes) and analyzing the status of the code.

Just looking and using it, it seems good: for example, today I've been able to add the "Remove Picture" and the "Force Picture Upload during Bulk" features in less than one hour and it has been smooth: implementation involved four classes in nice direct flow: a new Link in the page, one line of code per class involved with the last one with 4 lines to update the database and eliminate two files from S3 storage.

What do automated analysis say? Sloccount says there are about 3100 lines of Java code in three projects (core, api, web), with 808 lines of XML for Spring IOC configuration, Maven POMs and the HTML templates also, I think. Without the test tree of the source, numbers are, for Java only

core: 236
api: 1026
web: 1328

That makes less then 2600. What does this mean? Not much, but it's good that the codebase does not explode.
PMD does not find any priority 1 or 2 problem that is not the Logger that's not static final (just final).
Findbugs also shows less then 8 issues per project, nothing major.
Copy Paste detector, from PMD Suite, also did not find nothing but a couple of real code duplication which I was already aware of.

That is all. Now I promise to publish one article per week from the list above. Stay tuned.


1. My Event Based Application article
2. Pipelean is my other main project, get in touch at http://pipelean.com or, well, just write me :)