Whale Spotting

Learning goals

  • Working as part of a team to produce software
  • Follow software designs and technical specifications
  • Follow procedures for source control within a team

Programs Used

Exercise

This exercise builds on the Trello tickets created in the previous exercise. The task is to now actually build the Whalespotting website over the next two weeks.

Recap

The following is taken from the previous exercise and recapped here for convenience:

Recently we have finally seen an increase in whale numbers across the globe due to conservation efforts, and we would love to keep the public and scientific community engaged with these efforts. We have been tasked with creating a new website to help encourage and track whale spotting. The website should be able to grab and update current sightings data all across the world!

Requirements

  • The application should pull in all data from the database and update for any new sightings reported.
  • A user should be able to report a sighting of a whale.
  • An admin should be allowed to confirm or remove a sighting.

We should encourage people/help people provide sightings and go out whale spotting, this could be by incorporating weather on the website to plan an outing – the client would like input here to come up with some good ideas.

As well as these it should also:

  • Work on both mobile and desktop, while working well on tablets
  • Be accessible to all users
  • Work on all major browsers

Getting started

A starter code repo has been created here.

Your team should make a fork of that repo in a GitHub account that you can all access, then each of you should follow the steps in the readme file of that repo.

If the team that you did the planning with is combining with another team, then as a group you’ll need to go through the tickets and decide which ones to keep/combine. Even if your team isn’t combining, you should go through the tickets and prioritise them in some order.

On the Trello board from last exercise you may have both Backlog and To Do columns. The To Do column is suggested for holding the next few tickets so it’s clear what the priorities are; you’ll need to bring some from the Backlog now and then.

Working in a team

You’ll be working in a team on this project, so as a group you should agree some ways of working. Recommendations include the following.

Ceremonies

Each day you should have a team standup. This helps you stay in touch with each other’s progress and gives a forum for the team plan together. During each standup:

  • Each member of the team gives an update on their progress since the last standup and brings up any issues that they’re facing
  • The team might be able to solve any issues together quickly, but bigger issues should be addressed later (perhaps in a pair)
  • Make sure that the board is up to date – that each ticket is in the correct column and is assigned to the right person
  • If anyone will be ready to pick up another ticket then assign it to them from the To Do column

It’s a good idea to a team retro at the end of each week. This doesn’t need to be formal. The important thing is that it is an open discussion of things that have gone well and things that have gone not so well, and sharing of ideas; the team should endeavour to solve any problems together.

Occasional reprioritisation of tickets is a good idea. It’s likely that you’ll have more tickets on your board than the team can implement over the course of two weeks, and as you go through the project the expectations of what is feasible and opinions on which tickets are the most worthwhile can change. Since the project is two weeks long, it might be worth having a short team discussion after standup on days 3 and 6 in which you agree on any changes in priority and update the board’s To Do Backlog columns.

Development process

The following is a suggested development process. As a team you can agree your own approach, but it’s wise to discuss any changes with your trainer.

When you pick up a ticket

  1. Come up with a technical design for how you’re going to implement the solution for the ticket
  2. Create a new branch in the team’s fork of the repo – give the branch a sensible name so it’s clear what it’s for
  3. Implement your solution and commit it to that branch locally (remember to commit small and often)
  4. Push the branch to the repo

When you’re finished implementation

  1. Create a Pull Request from the branch in GitHub
  2. Potentially have the code reviewed by another team member or your trainer – you won’t have time to review all of each other’s tickets, but it is good experience to do some reviewing of other team members’ code
  3. If there are any changes needed after review, push them to the branch
  4. Merge your PR into the main branch – you’ve learned how to resolve merge conflicts in an earlier exercise so watch for this

Useful integrations

If you explore the repository, you’ll see that there are some integrations that provide functionality that you will need to build on, including the following:

  • The overall application framework is Spring Boot.
  • Database migrations are managed by Flyway which is integrated with Spring Boot to be autowired and invoked on startup.
    • There are two SQL migrations (docs here) included in the repo under src/main/resources/db/migration – Flyway discovers migrations automatically.
  • Page templating is provided through Thymeleaf. The template files served by the controller responses are defined under src/main/resources/templates.