ljvmiranda921 / burnout-barometer Goto Github PK

• Add a GIF on what it looks like on Slack (#51)
• Make the docker images public
• Proofread README

I think it's better if you put all the setup instructions from your Github README into an external documentation page.

For the GIF I think you just need to update your output message to ensure that it looks good during demo

I think setting the values can be done via viper, so that you can set them as flags right away (no need to run init inside the docker image). Explore this idea further

TODO

on mobile so i can't PR, but this typo is in the readme

Values should only be 1 to 5. If value is different, then give an error.

Another way to generate coverage reports: https://medium.com/@tsuyoshiushio/azure-devops-yaml-pipeline-with-coverage-report-for-go-lang-fd2163b3d254

• Have a flag that either forces flag creation, or just throw an error if it does not exist.
• Update interface to require Create() method

It should generate a config.json file. In addition, it should be able to accept environment variables as default values so that we can run this inside the Docker image

Structure

Just use Just the Docs

• Home: show badges, GIF demo, features, 1-paragraph discussion
• Setup: assume that people know how to setup Slack apps, talk about cloning and building, downloading the binaries in Releases, talk about container option
• Deploy: talk about different deployment options: Cloud Functions, Cloud Run
• Contributing: talk about dev environment setup, how to make a PR

Todo

Major

• Add Homepage
• Add Usage
• Add Installation
• Add Downloads
• Add Contributing

Minor

• Create a GIF on how it's being used within the Slack App (#51)
• Upload the latest version of the app in Azure Container Registry (make a new alpha release)

We're not using it, remove it.

Todo

Features

• Add Twitter Handling Logic based on credentials
• Add Message Reply Logic
• Update Dockerfile and Deployment Options

Deployment and Testing

• Test locally via Postman
• Test Cloud Run after merging to master
• Test Cloud Function after merging to master

Docs

• Update documentation on Installation

Unfortunately, they're closing. Let's just remove that for now

You can check this to see how it's being done: https://github.com/GoogleCloudPlatform/golang-samples/blob/master/functions/slack/slack_test.go

Todo

In no particular order

• Test barometer.go
• Test config.go
• Test server.go

Right now, we're require the user to configure the Locale so that we get the correct timestamp. I think we should just return whatever the time is rather than setting this properly.

• Refactor how Tables are being created and used
• Implement PostgreSQL using this newly-refactored API

• Instead of pushing to GCR, we push to ACR
• We also store some stuff in Azure Storage: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-file-copy?view=azure-devops

This is a small passion-project that I want to do this year. After the success of Pyswarms, I want to dedicate the next few years in maintaining another major project. This one hits closer to home, I tend to burnout and get tired easily, so being attuned to my mood has become an important in my mindfulness practice.

Vision

An open-source logger that can be used by individuals or teams to track their mental health.

Roadmap

In order to tag something into the next stage of the SDLC (e.g. from alpha going beta), the stated features or tasks should already be present:

• Release Candidate: fix all bugs that appeared in beta release. Release blog post on personal use. Add documentation on different ways to deploy.
• Beta: minimum lovable product, add support for Postgres so that it's suitable for open-source use, extensive unit and integration tests. Proper documentation in its own page. Complete CI/CD
• Alpha: proof-of-concept (PoC), support for BigQuery, can easily do a Slack connection

So if I'm currently in v1.0.0-alpha, I should be building towards a minimum lovable product, adding Postgres support and etc. before I tag it as beta.

When to share

• I'm planning to dogfood this for atleast 2-3 months and make some EDAs. I can definitely use this from February to April, make an EDA, then a blogpost, and then share.

https://golangci.com/r/github.com/ljvmiranda921/burnout-barometer

You can just wrap them later on for Cloud Function if you want