maxkferg/garage-pipeline repository overview

⁠Garage.js

⁠Install dependencies

Make sure you have dep installed (instructions at https://github.com/golang/dep⁠)

make deps

⁠Build

make build

⁠Authenticate

Create a file in top level directory called secrets.txt that contains webcam password

⁠Motion Detection Service

make run

⁠Face Detection Service

docker run -p 8000:8000 -it maxkferg/face-recognition

As a Daemon on the GarageJS server:

sudo docker run -d --gpus all -p 8000:8000 maxkferg/face-recognition:gpu

⁠Docker Support

Building the image

docker build -t maxkferg/garage-pipeline .
docker push maxkferg/garage-pipeline

Running the image

export WEBCAM=0
export FR_ENDPOINT="127.0.0.1:8000"  # Localhost
export FR_ENDPOINT="10.0.0.181:8000" # Garage Server 
docker run -e WEBCAM=$WEBCAM -e FR_ENDPOINT=$FR_ENDPOINT -it maxkferg/garage-pipeline

⁠Standard Go Project Layout

This project layout is intentionally generic and it doesn't try to impose a specific Go package structure.

⁠Go Directories

⁠/cmd

Main applications for this project.

The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).

Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the /pkg directory. If the code is not reusable or if you don't want others to reuse it, put that code in the /internal directory. You'll be surprised what others will do, so be explicit about your intentions!

It's common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.

See the /cmd⁠ directory for examples.

⁠/internal

Private application and library code. This is the code you don't want others importing in their applications or libraries.

Put your actual application code in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).

⁠/pkg

Library code that's ok to use by external applications (e.g., /pkg/mypubliclib). Other projects will import these libraries expecting them to work, so think twice before you put something here :-)

It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in the Best Practices for Industrial Programming⁠ from GopherCon EU 2018).

See the /pkg⁠ directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it.

⁠/vendor

Application dependencies (managed manually or by your favorite dependency management tool like dep⁠).

Don't commit your application dependencies if you are building a library.

⁠Service Application Directories

⁠/api

OpenAPI/Swagger specs, JSON schema files, protocol definition files.

See the /api⁠ directory for examples.

⁠Web Application Directories

⁠/web

Web application specific components: static web assets, server side templates and SPAs.

⁠Common Application Directories

⁠/configs

Configuration file templates or default configs.

Put your confd or consul-template template files here.

⁠/init

System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs.

⁠/scripts

Scripts to perform various build, install, analysis, etc operations.

These scripts keep the root level Makefile small and simple (e.g., https://github.com/hashicorp/terraform/blob/master/Makefile).

See the /scripts⁠ directory for examples.

⁠/build

Packaging and Continuous Integration.

Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the /build/package directory.

Put your CI (travis, circle, drone) configurations and scripts in the /build/ci directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the /build/ci directory linking them to the location where the CI tools expect them (when possible).

⁠/deployments

IaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes/helm, mesos, terraform, bosh).

⁠Other Directories

⁠/docs

Design and user documents (in addition to your godoc generated documentation).

See the /docs⁠ directory for examples.

⁠/tools

Supporting tools for this project. Note that these tools can import code from the /pkg and /internal directories.

See the /tools⁠ directory for examples.

⁠/examples

Examples for your applications and/or public libraries.

See the /examples⁠ directory for examples.

⁠/assets

Other assets to go along with your repository (images, logos, etc).

⁠/website

This is the place to put your project's website data if you are not using Github pages.

See the /website⁠ directory for examples.

⁠Directories You Shouldn't Have

⁠/src

Some Go projects do have a src folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-)

Don't confuse the project level /src directory with the /src directory Go uses for its workspaces as described in How to Write Go Code⁠. The $GOPATH environment variable points to your (current) workspace (by default it points to $HOME/go on non-windows systems). This workspace includes the top level /pkg, /bin and /src directories. Your actual project ends up being a sub-directory under /src, so if you have the /src directory in your project the project path will look like this: /some/path/to/workspace/src/your_project/src/your_code.go. Note that with Go 1.11 it's possible to have your project outside of your GOPATH, but it still doesn't mean it's a good idea to use this layout pattern.

⁠Badges

• Go Report Card⁠ - It will scan your code with gofmt, go vet, gocyclo, golint, ineffassign, license and misspell. Replace github.com/golang-standards/project-layout with your project reference.

• GoDoc⁠ - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.

• Release - It will show the latest release number for your project. Change the github link to point to your project.

⁠Notes

A more opinionated project template with sample/reusable configs, scripts and code is a WIP.