dan/souplesse
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
main
souplesse/HACKING.md

3.2 KiB
Raw Permalink Blame History

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

Multiuser

I am minded to avoid writing any of that user registration/authn stuff and just use a third-party SSO thing like Authelia to cover password resets etc. Installation instructions will include "set up a reverse proxy for this app which sends Remote-User and other Remote-* info as HTTP headers".

However, we do still need some changes

  1. trackpoints are no longer unique by time
  2. also sessions
  3. we want a users table with id and name/fullname/email to tie them back to
  4. if there is no userid for the current Remote-User header, make one

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 ...