Name Last Update
gradle/wrapper Loading commit data...
src Loading commit data...
.gitignore Loading commit data...
.gitlab-ci.yml Loading commit data...
Dockerfile Loading commit data...
README.md Loading commit data...
build.gradle Loading commit data...
docker-compose.yml Loading commit data...
gradlew Loading commit data...
gradlew.bat Loading commit data...
settings.gradle Loading commit data...


build status coverage report

Client: Michael Elliott, JPMorgan Michael.Elliott@jpmorgan.com

Many charities rely on volunteer networks, but small local charities sometimes don't have the staff to maintain those networks. On the flip side, many people would like to volunteer to help a local charity but aren't able to commit a set number of hours per week. Micro-volunteering allows individuals to offer up their skills on an ad-hoc basis and for charities to take advantage of that, and is extremely valuable to smaller charities or community organisations. Your task is to design a micro-volunteering exchange, that can match volunteers and their skills to opportunities and needs in their local area. Locality is critical in micro volunteering, perhaps a graph database (like neo4j) would be interesting here. Remember also that skills and needs often involve different terminology - how will your system understand that the skill of ‘simple wiring jobs’ should be matched to the need of ‘broken bulb in shelter’?

Project layout

Main Java source files should go into src/main/java, and Java test files should go into src/test/java. Resources (e.g. static HTML files) go into src/main/resources or src/test/resources.

Adding dependencies is done in build.gradle.


This project uses Gradle, to build and run use ./gradlew run. See ./gradlew tasks for other tasks that can be run.

Of particular use may be ./gradlew eclipse, which will generate Eclipse project files. These files should never be checked into the repository, since they should always be auto-generated by Gradle.


Running requires a Neo4j server with Spatial plugin running. The Docker image registry.gitlab.com/project-kilo/neo4j-spatial is perfect for this. There are several ways to get running:

1) Run a Neo4j container, then launch the application with ./gradlew run. See the Testing section below for guidance. 2) Launch an instance with docker-compose.

With docker-compose, getting started is easy:

docker login registry.gitlab.com
# login with your GitLab credentials

./gradlew distTar
# remember this step when rebuilding!

docker-compose up --build

To run the latest known working build from master, edit docker-compose.yml, remove the build line under microteer and replace it with an image line:

    image: "registry.gitlab.com/project-kilo/microteer"


To run the unit test suite, run ./gradlew test. Coverage can be additionally generated with ./gradlew check. These tests run on every push to GitLab, running in the GitLab CI.

Integration tests require a Neo4j server with Spatial plugin running. The Docker image registry.gitlab.com/project-kilo/neo4j-spatial is perfect for this, and is used in the GitLab CI for automated testing. Follow these steps to run integration tests:

docker login registry.gitlab.com
# login with your GitLab credentials

docker pull registry.gitlab.com/project-kilo/neo4j-spatial:latest
docker run -d -p 7474:7474 -p 7687:7687 -e NEO4J_AUTH=neo4j/somepass registry.gitlab.com/project-kilo/neo4j-spatial:latest
KILO_DB_PASSWORD=somepass ./gradlew integrationTest

# optional, kill the Docker container
docker ps # find the running container ID
docker kill c0ntain3rid

To populate the database with an example dataset, run the following after your database is running:

KILO_DB_PASSWORD=somepass ./gradlew populateDatabase