mathbunny / strava-wind-analysis Goto Github PK

User suggested that the calculated wind impact calculation is not properly taking into account relative wind direction.

KOM rider has W wind howling out of the W at 24.29 and for the two below him the wind, while lower velocity 16.38, is directly out of the South (blowing them due North)

Perhaps an issue with the weightage of vectors' magnitudes.

Expected behaviour: AJAX call to backend to get segment recommendations, then populate Google Maps instances with segment polylines.

Actual behaviour: No Google Maps appear.

Do the AJAX requests from within the front-end to the backend to speed up performance

There is some incorrect leaderboard positioning in this segment (observe the bottom few rows). This is likely caused by the Strava API Data Handler not being up to date.

Received user report that the segment and rides search pages were down, and forwarded the user to the Strava OAuth page. Restarting the Node.js seemed to work and resolve the issue, but this may occur again.

In the future, basic QC checks are appropriate to ensure basic functionality during run-time.

By looking at the logs:

  exports.active = process.domain = this;
                                  ^

RangeError: Maximum call stack size exceeded
    at Domain.enter (domain.js:167:35)
    at bound (domain.js:299:8)
    at Domain.runBound (domain.js:314:12)
    at emitOne (events.js:115:13)
    at Domain.emit (events.js:210:7)
    at Domain._errorHandler (domain.js:118:23)
    at process._fatalException (bootstrap_node.js:326:33)
    at Domain._errorHandler (domain.js:145:26)
    at process._fatalException (bootstrap_node.js:326:33)
    at Domain._errorHandler (domain.js:145:26)
npm ERR! code ELIFECYCLE
npm ERR! errno 7
npm ERR! [email protected] start: `node ./bin/www`
npm ERR! Exit status 7
npm ERR! 
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ubuntu/.npm/_logs/2018-04-26T23_34_53_425Z-debug.log

For example, in /segments/details, if an error occurs, the user would just be left handing in the promise. Do a .error(requestError => {}); handler.

Received several user complaints about virtual rides polluting the segment selection screen.

This should already be filtered in the rides section, which is supported by an option in settings stored in MongoDB, however the filter doesn't apply in the segments page.

The solution is to filter the JSON returned from stravadatahandler, for this field:

"activity_type" : "Ride"

User requests feature to switch between metric and imperial units - mostly emphasizing speed on the wind impact details page.

As of precisely 9:59pm PDT, the site stopped responding, as per Uptime-Robot. The issue was resolved by making more space by deleting a prior backup of a repository, however this is only a temporary solution was resorting to EBS or other storage solutions is more optimal for the long term.

The outage was resolved by 9:31am PDT.

Issue occurs in segment template preprocessing:

            if (effort.wind_speed_str === '0.00') {
              console.log(effort.wind_speed);
              console.log(effort.wind_speed_str);
              console.log(windData.hourly.data);
              console.log(date.getHours());
              console.log(windData.hourly.data[date.getHours()].windSpeed);
            }

Ink Framework JavaScript feature.

Results in issues with rides and segment page

An attacker can use the format parameter to inject arbitrary commands in the npm package morgan < 1.9.1 -- vulnerability mentioned here.

MLab was acquired by MongoDB Inc and will require migration to a different hosting service (MongoDB Atlas) within the next four months. According to the newsletter sent, it will be required to migrate within the next twelve months.

All user data metadata and API usage throttling is handled through MongoDB.

The Vector class should export the class:

module.export = Vector;

Instead of:

exports.Vector = Vector;

Hi,

This seems like an issue: after initial authorisation and loading list of my segments, when trying to select one of them, the app jumps again to Strava authorisation screen.

Tried on Mac OS, in Chrome and Safari - same behaviour. If important - I'm logging to Strava using email/password.

You can see this problem in this recording.

Best regards,
Jarek

This is a proposal to add search capabilities on rides and segments.

Index the segment/ride data, and then allow for searching on fields using elasticsearch. Then user can do faceted search and range queries, while allowing for the regular filters on the segments/rides page. This will greatly improve performance than doing another search query using lambda expressions. However, recent rides will need to be reindexed upon the user logging in. This metadata can be stored in another database (MongoDB, MySQL).

Migrating the session data from the application layer to an in-memory store like Redis-cluster would provide the following benefits:

• Ability to easily scale, eliminating the need of sticky load balancers
• Should any Node.js instance crash, the user doesn't lose their session

An alternative would also be to store them in cookies.

Back in #73, the EC2 issue resulted in StackOverFlow in the Node.js resulted in the server restarting via PM2, further propagating into users losing their sessions. If the session data was instead stored in Redis, it wouldn't have been lost.

The recent Strava API update removed the ability to view other athlete specific data... breaking functionality including the modals, and the leaderboard performance analysis screen.

The features could either be removed, or warning message in case the functionality gets added back.

• Include ability to view rides as well as segments

User reported issue that seems related to #86. The effect is that users are periodically logged off, as redis-server appears unable to allocate sufficient memory to store key/value pairs (call to malloc fails).

For the future, proper implementation of a more fault tolerant version of #81 should prevent this from happening. Additionally, Redis should not be in the critical path and simply used for caching only.

User reported issue where segments detail page hangs, and just keeps loading indefinitely. Perhaps related to #83

Right now, the segment correlation coefficient is computed within the segments details page route, which makes it extremely difficult to unit test. This critical piece of code should be:

• Separated into smaller components
• Refactored to fetch from existing data handlers (Strava, MongoDB)
• Contain improved error handling

User requested for ride time duration to be moving time, not total elapsed time.

It is slow while fetching data for 50,000+ segment efforts

The hyperlink is broken, it points to non-existent identifier #passions.

Redis cannot exceed ~25,000 keys as the EC2 instance only has 1GB of RAM and then runs into other issues as it tries to page and commit to memory.

Related to #89.

The recent Google Maps API change requires the use of an API key. This breaks all existing functionality with noKey.js, including segments, rides and the scrolling feed.

While maps still show, they show as development use only.

Expected behavior: Time/speed is parsed normally, resulting in sensible results.
Actual behavior: All numbers become invalidated (NaN), resulting in invalid returns.