kulti / task-list Goto Github PK

• split tests by files
• rename files to separate tests and helper

Blocked by #28.

After adding regular DB backups it's needed to try to restore DB from backup.

Makefile becomes too big and ugly. It does a lot of stuff. Other tools can probably do it better.

Things to research:

• docker images build
• deploy
• project structure to generalize makefile targets

Finally, things to be done:

• Reorganize project source tree to simplify docker build - #34.
• Move all dockerfile to separate directory - #39.
• Add some configuration to docker-compose by env files - #35.
• Push docker images to hub - #32.
• Add a new target(st) to pull docker images and deploy them without building - #36.

After #72 sprint/new will pass begin and end sprint dates. They should be stored in DB.

Also, it should be validated - sprint dates cannot be overlapped. (it doesn't cost effort)

It needs the following sections:

• Description (what is it)
• How to use
• How to build
• How to deploy
• Requirements (go, docker, npx)

It helps to write generated makefile targets:

1. Move all backend sources to the server folder.
2. Rename frontend to front.
3. Rename db to migrate.
4. Create live-reload.

I'm not sure that logs are stored anywhere. Also, I have different format logs for backend and proxy-access logs.

Logs should contain link and/or span id to link all log's chain.

pgx driver allows set up a custom logger.

I have a new sprint template for tasks. But it's not simple to edit (only through db).

It will be great to add simple editor to manage new sprint tasks. Especially for projects of the month.

Locally unit tests should be always cached. So it makes sense to run unit tests in a pre-commit hook.

The problem is pre-commit also run in CI.

Sometimes tasks cannot be done at this sprint. It's a good idea to write it into backlog to get it into one of the following sprints.

New code should be tested as good as possible.

I think handlers must be as simple as possible and free from business logic.

Try to make a service in DDD paradigm to one action and look how it be.

At now templated tasks just created after creation of new sprint.

Tasks should be created one by one with direct confirmation.

It's not useful. So I decide to remove then.

At now todo task become bold and on top of list.

At now tasks are deleted only from the table with task-list mapping. These should be deleted from tasks table too.

A bunch of typescript code must be tested.

Probably it need some refactoring before writing tests.

Useful article - https://medium.com/@RupaniChirag/writing-unit-tests-in-typescript-d4719b8a0a40.

When a new sprint created it has begin and end dates. It should be passed through sprint/new API.

Add env files to configure general docker-compose file for prod and dev.

E.g. it needed to choose a docker image tag.

After #74 it doesn't matter to pass sprint title, because backend will have all required info to build sprint title.

During analyzing #55 I found that separate API for getting a template is unnecessary. It's simple and enough to return it from sprint/new.

The command ./scripts/deploy.sh prod restart looks useful.

At now integration tests call api backend directly. It will be better to do it through a proxy to increase integration.

It's not simple and is not cost to effort. But it can be interesting and good for research and learning.

Monorepo is useful for the following:

1. All common stuff in one place: api.yaml and generated cli, db migrations, makefiles and scripts.
2. Simple to run integration tests.
3. Simple version management.

But it is bad for the following:

1. Not all parts need to increase their versions. E.g. proxy and migrate are stable in common.
2. Not need to run frontend linter and tests when updates server and vice versa.
3. It's not possible to calculate coverage for front and server separately.

Splitting can be done step by step:

1. Uses submodules to save the current structure but separate source code.
2. Uses submodules and go packages to share common parts (api.yaml and apitest).
3. Make it possible to run services with different versions.
4. Creates artifacts (docker images) for PR and trigger separate integration tests for them.
5. Migrate workflows to separate repos. Monorepo contains only submodules and single version for everyone.

It also needs to research deploy tools to simplify updates and version management.

It's simple to run simple go tools like a script with go run.

At now it possible to deploy only locally built images. After #32 images will have tags. It will be great to have a tool to deploy the task list app only with docker.

At now task id is serial in db and string in api. It ways to convert number to string and vice versa.

How about to use string id in db?

Looks similar to #62. It's needed to check all possible state switches.

The idea: extract allowed state switches to method or type and use that inside storages.

To plan a new sprint I get tasks from different sources. Two of them are placed on the monthly page of my calendar in bujo:

• actions planned to a specific date
• projects of month

Probable solutions:

• add a separate list for calendar planned tasks
• migrate go calendar app and use it in Task List
• add projects of the month to new sprint template

I need to store backups separately, e.g. at Yandex disk.

After #9 it will be simpler to test handlers when DB returns errors.

I have looked at google calendar API and decided to use it for planned events.

• Try simple example (https://developers.google.com/calendar/quickstart/go).
• Support google calendar as a source for planned events. (at the first do #71, #72).
• What to do with events added during an active sprint? (write them manually to a task list).

I think it's possible to use selenium to write some integration tests.

https://code.visualstudio.com/api/advanced-topics/tslint-eslint-migration

https://github.com/pre-commit/mirrors-eslint

It looks like that:

But should be:

Task List uses bootstrap. It should be simple to add mobile version to us it on phone or tablet.

When I try to update done task from 6/6 to 7/7 I get the error "failed to update task".

The logs have the reason:

{"level":"warn","ts":1593423706.1302848,"caller":"router/responses.go:34","msg":"failed to update task in db","error":"cannot switch state from done to done"}

Some tasks need to be done to a specific deadline. For example, I need to pay bills to the end of month.

These tasks should be added to a new sprint template at a specific time, not every week.

In a production environment that can be happened after redeploy. So, the simplest way is setting up WebSocket with a static file server and reload bundle.js if the socket would be closed.

The plan:

• Write static file server with WebSocket support (only ping messages) - https://hub.docker.com/repository/docker/kulti/static-file-server.
• Fix Nginx config to proxy WebSocket.
• Fix frontend to reload a page on WebSocket closing.

Some tests use fake tasks and sprint's title. They should be different to increase chance of bug found.

If task already done it can not be canceled.

For symver it's ok to point v1 and v1.7 to v1.7.3.

https://github.com/kulti/task-list/runs/782080523