dan/souplesse
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

separate the grisly internals from the user-facing README

Browse Source
This commit is contained in:
Daniel Barlow 2024-11-29 18:17:12 +00:00
parent 0cb79fb54d
commit d41426f4cf
2 changed files with 62 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
HACKING.md Normal file
View File

@ -0,0 +1,62 @@
# Development and Design notes
## WIP, Puzzles and TODO
* rename Track to Gpx, it deals only with parsing.
* can we lose this "if isJust lat && isJust lon && isJust ts" wart?
* probably we should store points in a more efficient form than
a singly-linked list
* boring stuff like auth[zn]
* need a web server in haskell that
* [done] accepts file upload and parses the gpx file
* [done] serves the data points in some format elm can digest easily
* [done] need a database of some kind so the data can be saved
* [done] frontend can get data from backend
* [done] for DX, backend can serve the js files needed by frontend
* [ad hoc] we only have yesod-core, may need other parts as well
* [done] detect and refuse uploads which overlap an existing time frame (http 409) so that we can script upload-all-the-tracks.
* could we converge the Point and Trkpt to make sql better?
* [done] move Store into Point
* on timeline, show power, cadence, speed, height, ascent (checkboxes)
* done some
* need speed and ascent
* need checkboxes
* zoom gesture on graphs causes map to adjust
* zooming map causes graphs to adjust
* threshold display: adjust vertical slider to show time spent at
or above a particular intensity. Indicate somehow the length of
each continuous stretch at that intensity
## Sessions
The calendar (TBD) displays sessions. a session is a sequence of
measurements describing a ride or a race or a trip. we can extract
potential sessions from the data by looking for series of points not
more than x (10?) minutes apart, but the rider may override
that. Consider: I ride solo to the start point of a group ride, join a
tandem partner to do the group ride, then ride solo home. There is not
necessarily ten minutes between them.
After a new track is uploaded, we look at all the points covered by
draft sessions, and rearrange them to cover the new points. Draft
sessions are then presented to the rider who may approve them as-is -
perhaps involving other data collection as well ("perceived effort" or
"which bike setup was this" or ...) - or chop them up using
information they have but that the computer doesn't
Aside: in theory we don't even need draft sessions and we could have
the rider create sessions from the calendar page. However, that's a
GET and might be slow if it has to figure out what all the sessions
would be every time someone looks at it. So the draft session is just
to precompute that and make the view easier
The summary of a session is for display on the calendar and might
change depending on the nature of the training effort. e.g. for a
long slow ride we show total distance, for interval training we show
time spent in HR zones ...
-

62
README.md
View File

@ -71,65 +71,3 @@ that you can chuck a bunch of GPX files at it using curl
This should be safe to do repeatedly because it will refuse upload of
tracks where the database already contains any points in the time
range of the uploaded track
----
_Do not look below this line_
## WIP, Puzzles and TODO
* rename Track to Gpx, it deals only with parsing.
* can we lose this "if isJust lat && isJust lon && isJust ts" wart?
* probably we should store points in a more efficient form than
a singly-linked list
* boring stuff like auth[zn]
* need a web server in haskell that
* [done] accepts file upload and parses the gpx file
* [done] serves the data points in some format elm can digest easily
* [done] need a database of some kind so the data can be saved
* [done] frontend can get data from backend
* [done] for DX, backend can serve the js files needed by frontend
* [ad hoc] we only have yesod-core, may need other parts as well
* [done] detect and refuse uploads which overlap an existing time frame (http 409) so that we can script upload-all-the-tracks.
* could we converge the Point and Trkpt to make sql better?
* [done] move Store into Point
* on timeline, show power, cadence, speed, height, ascent (checkboxes)
* done some
* need speed and ascent
* need checkboxes
* zoom gesture on graphs causes map to adjust
* zooming map causes graphs to adjust
* threshold display: adjust vertical slider to show time spent at
or above a particular intensity. Indicate somehow the length of
each continuous stretch at that intensity
* calendar displays sessions. a session is a sequence of measurements
describing a ride or a race or a trip. we can extract potential
sessions from the data by looking for series of points not more than
x (10?) minutes apart, but the rider may override that. Consider: I
ride solo to the start point of a group ride, join a tandem partner
to do the group ride, then ride solo home. There is not necessarily
ten minutes between them.
after a new track is uploaded, we look at all the points covered by
draft sessions, and rearrange them to cover the new points. Draft
sessions are then presented to the rider who may approve them
as-is - perhaps involving other data collection as well ("perceived
effort" or "which bike setup was this" or ...) - or chop them up
using information they have but that the computer doesn't
in theory we don't even need draft sessions and we could have the
rider create sessions from the calendar page. However, that's a GET
and might be slow if it has to figure out what all the sessions would
be every time someone looks at it. So the draft session is just to
precompute that and make the view easier
the summary of a session is for display on the calendar and might
change depending on the nature of the training effort. e.g.
for a long slow ride we show total distance, for interval training
we show time spent in HR zones ...
----