A digital photo frame web application, mainly targeted to run on a first generation iPad. Built on top of Trello.
- Running version Available at gallo.app, although no promises on uptime guarantee. Can easily be self-hosted.
- Changelog
The application is a plain old website, served by a backend written in Go and sprinkled with a dash of vanilla Javascript.
The Javascript dialect is intentionally older due to targeting Safari on iOS 5.1.1
Stylesheets are scss.
- API communication with Trello via adlio/trello.
- Responsive image polyfill, picturefill, and javascript-state-machine on the Javascript side of things.
- Pure.css for styling primitives.
The application is dockerized and includes files to run via docker compose:
$ docker-compose up appApart from the main application service, redis is included for caching HTML template renderings and API responses from Trello.
The included stubbed .env file lists a number of required and optional environment variables.
APP_VERSIONis automatically updated in the file, everytime theupdate_app_versionmake target is run. Will contain the sha of the latest commit. The value of this ends up in the version attribute of the<html>tag.HOSTis used to infer thereturn_urifor the Trello authentication flow.REDIS_ADDRis the ip or hostname of the accompanying Redis server.SESSION_AUTH_KEYandSESSION_ENC_KEYare both 32 character key strings, used for session encryption. A tiny Go program for generating these at random are available in keygen.go. Run with:go run scripts/keygen.go.TRELLO_KEYis a Trello Developer API key. Get one here.
These are specifically related to the way the application is running on gallo.app and are only relevant if the application is deployed in a similar setup.
APP_ENVandAPP_PATHare set in the relevant compose files.
For differences in local development, see docker-compose.override.yml and development.Dockerfile.
Notably, two additional services are run with a live file watcher, which handles conversion of sass to proper css.
Since Gallo has mainly been developed with the intention of running in Safari on a 1st generation iPad, spurious crashes and other odd error cases sometimes do happen. It's not the most reliable version of Safari and it has some limitations when it comes to graphics memory. E.g. here is a piece of the UIWebView documentation noting a the 10 mb limit:
https://web.archive.org/web/20130424092111/http://developer.apple.com/library/ios/navigation/
Here's others experiencing the browser crashing, due to out of memory errors:
Due to this, when showing images in presentation mode for a specific card, a limit exists for the number of images able to be displayed. This means that not all images will be shown at all times, but since they appear in random order, an image omitted in one showing, will probably be included in the next and vice versa.
Assuming you've got the app container running:
$ docker-compose up -d appRun the Go test suite like so:
$ docker-compose exec app go test -v ./...The included Makefile has a deploy target included, which should make a rudimentary deployment easy:
$ make deployThis make target will take care of building the application and static assets, creating the final docker image, pushing it and running the container on your DOCKER_HOST.
For a simple single host setup, using Docker Machine with the Generic driver is probably the easiest way to go.
Comments in Javascript sources has been written in JSDoc format and can be generated with:
$ npm run jsdocGenerated docs will be output in ./jsdoc.