If a photo is deleted from the camera after the pusher generates its ID but before the pusher uploads it, the pusher will try forever to get the file from the camera. This will never succeed because it doesn't exist on the camera. We should remove IDs of photos that aren't on the camera anymore.

We added a Dockerfile in #29. We should have Travis make sure we can actually build it and run it.

This would be nice so that browsers can automatically orient the thumbnails... As of currently, thumbs don't retain their full image's EXIF data, so orientation can't be determined on its own.

Create pagination functionality in both, storm supports this using skip and limit

#11 (comment)
#11 (comment)
#11 (comment)
#11 (comment)
#11 (comment)

Also consider creating post quick and create job system, as image processing times is upwards of 500ms

As a photo editor, I want to be able to group incoming photos into shoots so that I can quickly tell them apart.

As a photographer, I want to take photos and have them automatically show up on the server without my having to do anything.

Acceptance

• Photos are uploaded from camera to server
• Photos that have already been uploaded are not uploaded again

Notes

• This is reliant on getting the photos POST endpoint working (#3)
• We need to be able to determine which photos have already been uploaded (#2)

Logs are spewing out useless information when testing (due to all the errors created from edge cases). We need a way to change the logging level depending upon if it's testing or not.

SetLevel exists, but that needs to be called in each function (which isn't really fun).

We could do a setup function in testing but that seems like a lot of overhead for what is essentially a toggle

As a photo editor, I should be able to reorder photos as I please so that I can put the most important photos first.

Points: 5

Acceptance

• Photos can be moved into arbitrary orders
• The orders are persistent

Notes

• I'm not sure where the orders should be persisted. Client side or server side? We can discuss.
• Is this even necessary? Do people actually want this?

As a photo editor, I can see all the photos currently stored by the server so that I can share the good ones.

Photos: 8

Acceptance

• There's a webpage with all of the photos visible

Notes

• This relies on the photos GET endpoint to work (#3)

Wi-Fi is slow. This timeout needs to be increased.

As a photo editor, I can download photos so that I can edit them in Photoshop or another local program.

Photos: 8

Acceptance

• There's a download button associated with each photo
• Multiple photos can be selected and downloaded

There are a lot of options:

• SQLite
• Postgres
• Storm/Bolt
• homebrew serialization format
• Word documents
• Google Drive

Initial thoughts:

• /photos
  • GET: list of uploaded photo identifier
  • POST: upload a new photo
• /photos/<id>
  • GET: download a photo by its identifier

Do we care about unit tests?

Do we care about acceptance tests?

Why or why not?

What do we need to do as a result of that decision?

Pushers need to be able to know what photos haven't yet been uploaded to the server. One possible scheme:

• Concatenate photo metadata (time captured, camera model, exposure settings, filename, etc.) and hash it. This becomes the photo's identifier.

As a photo editor, I should be able to access photos in a sorted manner so that I can quickly see the most recent ones.

Points: 5

Acceptance

• Organize by capture time, filename, and in reverse order

We need to add a travis build file, setup the build in travis, and have it hook on all changes. This will give us results of building/formatting. We should fail on go fmt formatting anything, and build failing