HACKING.md (3280B)
1 # Development and Design notes 2 3 4 ## WIP, Puzzles and TODO 5 6 * rename Track to Gpx, it deals only with parsing. 7 * can we lose this "if isJust lat && isJust lon && isJust ts" wart? 8 * probably we should store points in a more efficient form than 9 a singly-linked list 10 11 * boring stuff like auth[zn] 12 * need a web server in haskell that 13 * [done] accepts file upload and parses the gpx file 14 * [done] serves the data points in some format elm can digest easily 15 * [done] need a database of some kind so the data can be saved 16 * [done] frontend can get data from backend 17 * [done] for DX, backend can serve the js files needed by frontend 18 * [ad hoc] we only have yesod-core, may need other parts as well 19 * [done] detect and refuse uploads which overlap an existing time frame (http 409) so that we can script upload-all-the-tracks. 20 * could we converge the Point and Trkpt to make sql better? 21 * [done] move Store into Point 22 23 * on timeline, show power, cadence, speed, height, ascent (checkboxes) 24 * done some 25 * need speed and ascent 26 * need checkboxes 27 * zoom gesture on graphs causes map to adjust 28 * zooming map causes graphs to adjust 29 * threshold display: adjust vertical slider to show time spent at 30 or above a particular intensity. Indicate somehow the length of 31 each continuous stretch at that intensity 32 33 ## Multiuser 34 35 I am minded to avoid writing any of that user registration/authn stuff 36 and just use a third-party SSO thing like Authelia to cover password 37 resets etc. Installation instructions will include "set up a reverse 38 proxy for this app which sends Remote-User and other Remote-* info as HTTP 39 headers". 40 41 42 However, we do still need some changes 43 44 1) trackpoints are no longer unique by time 45 2) also sessions 46 3) we want a `users` table with id and name/fullname/email to tie them back to 47 4) if there is no userid for the current Remote-User header, make one 48 49 50 51 52 ## Sessions 53 54 55 The calendar (TBD) displays sessions. a session is a sequence of 56 measurements describing a ride or a race or a trip. we can extract 57 potential sessions from the data by looking for series of points not 58 more than x (10?) minutes apart, but the rider may override 59 that. Consider: I ride solo to the start point of a group ride, join a 60 tandem partner to do the group ride, then ride solo home. There is not 61 necessarily ten minutes between them. 62 63 After a new track is uploaded, we look at all the points covered by 64 draft sessions, and rearrange them to cover the new points. Draft 65 sessions are then presented to the rider who may approve them as-is - 66 perhaps involving other data collection as well ("perceived effort" or 67 "which bike setup was this" or ...) - or chop them up using 68 information they have but that the computer doesn't 69 70 Aside: in theory we don't even need draft sessions and we could have 71 the rider create sessions from the calendar page. However, that's a 72 GET and might be slow if it has to figure out what all the sessions 73 would be every time someone looks at it. So the draft session is just 74 to precompute that and make the view easier 75 76 The summary of a session is for display on the calendar and might 77 change depending on the nature of the training effort. e.g. for a 78 long slow ride we show total distance, for interval training we show 79 time spent in HR zones ... 80 81 -