Merge pull request #11 from vibrato/cleanup

Cleanup

.gitignore

@@ -3,6 +3,7 @@
 *.dll
 *.so
 *.dylib
+.DS_Store
 
 # Test binary, build with `go test -c`
 *.test

ASSESSMENT.md

@@ -0,0 +1,100 @@
+# Assessment
+
+Candidates should assume that the solution will be deployed to an empty cloud subscription with no existing infrastructure in place.
+
+There *should not* be a requirement for Vibrato to access a candidate's cloud services account to deploy this solution.
+
+Demonstrate regular commits and good git workflow practices.
+
+There is no time limit for this test.
+
+Candidates should provide documentation on their solution, including:
+
+- Pre requisites for your deployment solution.
+- High level architectural overview of your deployment.
+- Process instructions for provisioning your solution.
+
+## Assessment Grading Criteria
+
+### Key Criteria
+
+Candidates should take care to ensure that thier submission meets the following criteria:
+
+- Must be able to start from a cloned git repo.
+- Must document any pre-requisites clearly.
+- Must be contained within a GitHub repository.
+- Must deploy via an automated process.
+
+### Grading
+
+Candidates will be assessed across the following categories:
+
+#### Coding Style
+
+- Clarity of code
+- Comments where relevant
+- Consistency of Coding
+
+#### Security
+
+- Network segmentation (if applicable to the implementation)
+- Secret storage
+- Platform security features
+
+#### Simplicity
+
+- No superfluous dependencies
+- Do not over engineer the solution
+
+#### Resiliency
+
+- Auto scaling and highly available frontend
+- Highly available Database
+
+## Tech Test Application
+
+Single page application designed to be ran inside a container or on a vm (IaaS) with a postgres database to store data.
+
+It is completely self contained, and should not require any additional dependencies to run.
+
+## Install
+
+1. Download latest binary from release
+2. unzip into desired location
+3. and you should be good to go
+
+## Start server
+
+update `conf.toml` with database settings
+
+`./TechTestApp updatedb` to create a database and seed it with test data
+
+`./TechTestApp serve` will start serving requests
+
+## Interesting endpoints
+
+`/` - root endpoint that will load the SPA
+
+`/api/tasks/` - api endpoint to create, read, update, and delete tasks
+
+`/healthcheck/` - Used to validate the health of the application
+
+## Compile from source
+
+### Requires
+
+#### dep
+
+`curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh`
+
+### Process
+
+`go get -d github.com/vibrato/VibratoTechTest`
+
+run `build.sh`
+
+the `dist` folder contains the compiled web package
+
+### Docker build
+
+`docker build . -t techtestapp:latest`

CONTRIBUTING.md

@@ -0,0 +1,58 @@
+# Contributing
+
+When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
+
+Please note we have a code of conduct, please follow it in all your interactions with the project.
+
+## Pull Request Process
+
+1. Ensure there is an issue linked to the Pull Request that explains what the change is and why it is needed.
+2. Update the documentation with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and parameters.
+3. You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.
+
+## Code of Conduct
+
+### Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+### Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+### Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+### Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+### Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [email protected]. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+### Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

cmd/version.go

@@ -32,7 +32,7 @@ var versionCmd = &cobra.Command{
 	Short: "Displays the current version",
 	Long:  `Displays the current version of the application`,
 	Run: func(cmd *cobra.Command, args []string) {
-		fmt.Println("Version: 0.2.3-pre-release")
+		fmt.Println("Version: 0.2.4")
 	},
 }
 

doc/adr/0001-record-architecture-decisions.md

@@ -0,0 +1,19 @@
+# 1. Record architecture decisions
+
+Date: 2018-08-08
+
+## Status
+
+Accepted
+
+## Context
+
+We need to record the architectural decisions made on this project.
+
+## Decision
+
+We will use Architecture Decision Records, as described by Michael Nygard in this article: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
+
+## Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's _adr-tools_ at https://github.com/npryce/adr-tools.

doc/adr/0002-use-viper-for-config.md

@@ -0,0 +1,19 @@
+# 2. Use viper for config
+
+Date: 2018-08-08
+
+## Status
+
+Accepted
+
+## Context
+
+The solution was built using a custom toml configuration solution, should we standardise on a library for less maintnance overhead?
+
+## Decision
+
+Decided to use viper as the configuration library, as it tightly integrates with cobra which we already use for helping with command line integration.
+
+## Consequences
+
+A few known issues around managing missing files with viper, but our process is set up to always have a file available so it shouldn't be a bit issue for us.

doc/adr/0003-removed-scaffolding.md

@@ -0,0 +1,19 @@
+# 3. removed scaffolding
+
+Date: 2018-08-09
+
+## Status
+
+Accepted
+
+## Context
+
+Should we provide scaffolding for the test takers, or should we expect them to be able to set that up themselves?
+
+## Decision
+
+We decided to remove the scaffolding and rather suggest that the test taker uses the default VPC to deploy their application.
+
+## Consequences
+
+Some people will spend exta time to deploy the network infrastructure, which might make the test seem a lot bigger than it is.

doc/readme.md

@@ -0,0 +1,125 @@
+# TechTestApp
+
+[![Build Status][circleci-badge]][circleci]
+[![Release][release-badge]][release]
+[![GoReportCard][report-badge]][report]
+[![License][license-badge]][license]
+
+[circleci-badge]: https://circleci.com/gh/vibrato/TechTestApp.svg?style=shield&circle-token=8dfd03c6c2a5dc5555e2f1a84c36e33bc58ad0aa
+[circleci]: https://circleci.com/gh/vibrato/TechTestApp
+[release-badge]: http://img.shields.io/github/release/vibrato/TechTestApp/all.svg?style=flat
+[release]:https://github.com/vibrato/TechTestApp/releases
+[report-badge]: https://goreportcard.com/badge/github.com/vibrato/TechTestApp
+[report]: https://goreportcard.com/report/github.com/vibrato/TechTestApp
+[license-badge]: https://img.shields.io/github/license/vibrato/TechTestApp.svg?style=flat
+[license]: https://github.com/vibrato/TechTestApp/license
+
+The Vibrato techtest app is a golang application used for testing candidates applying to work with Vibrato.
+
+## Tech Test Application
+
+Single page application designed to be ran inside a container or on a vm (IaaS) with a postgres database to store data.
+
+It is completely self contained, and should not require any additional dependencies to run.
+
+## Install
+
+1. Download latest binary from release
+2. unzip into desired location
+3. and you should be good to go
+
+## Start server
+
+update `conf.toml` with database settings
+
+`./TechTestApp updatedb` to create a database and seed it with test data
+
+`./TechTestApp serve` will start serving requests
+
+## Interesting endpoints
+
+`/` - root endpoint that will load the SPA
+
+`/api/tasks/` - api endpoint to create, read, update, and delete tasks
+
+`/healthcheck/` - Used to validate the health of the application
+
+## Repository structure
+
+``` sh
+.
+├── assets      # Asset directory for the application
+│   ├── css     # Contains all the css files for the web site
+│   ├── images  # Contains all the images for teh web site
+│   └── js      # Contains all the react javascript files
+├── cmd         # Command line UI logic is managed in this location
+├── config      # Contains the configuration logic for he application
+├── daemon      # Contains the logic of the daemon that runs and controll the app
+├── db          # Contains the data layet and db connectivity logic
+├── doc         # Documentation folder
+├── model       # Data model for the application
+├── scaffolds   # Scaffolds for deplying the application onto the cloud
+└── ui          # Web UI, routing, connectivity
+```
+
+## Application Architecture
+
+![architecture](images/architecture.png)
+
+The application itself is a React based single page application (SPA) with an API backend and a postgres database used for data persistence. It's been designed to be completely stateless and will deploy into most types of environments, be it container based or VM based.
+
+## Build from source
+
+### Reqirements
+
+#### Golang
+
+Application is build using golang, this can be installed in many ways, go to [golang](https://golang.org/) to download the version that suits you.
+
+#### dep
+
+dep is used for dependency management in golang, please download and install dep from the [official source](https://github.com/golang/dep).
+
+Linux / MacOS: `curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh`
+
+#### Docker
+
+If building using docker you need to have docker installed on your local machine. Download from the [docker website](https://www.docker.com/get-started)
+
+### Compiling the application locally
+
+Download the application using go get:
+
+`go get -d github.com/vibrato/VibratoTechTest`
+
+run `build.sh` to download all the dependencies and compile the application
+
+the `dist` folder contains the compiled web package
+
+### Docker build using docker
+
+To build a docker image with the application installed on it
+
+`docker build . -t techtestapp:latest`
+
+## Continuous Integration
+
+Continuous integration is managed through circleci and the build on the master branch will create a new release when a new version is defined.
+
+## Creating a new release
+
+Releases are deployed and managed through github, it's an automated process that is executed through the CI solution
+
+To create a new release, update `../cmd/version.go` with the new version and merge that into the master branch.
+
+The commit message on the merge, will be the release message, so make sure it contains the release notes.
+
+A tag will be created on the master branch if the build and release is successful.
+
+We use semver for versioning, `major.minor.patch[-pre-release]` and the CI solution has been configured to take note of the `-pre-release` tag of the version and upload it as a pre-release in git if it's included. So to release a new full release, make sure to not include `-pre-release` and vice versa.
+
+Builds will be produced for:
+
+* MacOS (amd64)
+* Linux (x86/amd64)
+* Windows (x86/amd64)