Going back in time to look at old rides is now a whole lot easier. Rather than having to endlessly scroll down and repeatedly click “show more”, there’s now a list of years and months that can be used for navigation.
Immediately underneath “Rides” on the left there’s now a list of years and months where rides exist. Clicking on the year collapses or uncollapses its list of months, while clicking on a month takes you to those rides. The number of rides in each month is shown when the mouse is over the month name. And, to make life easier, the list of years and months is always visible, regardless of whether you’re looking at the top, bottom, or middle of the ride list.
If you want to see this in action, take a look at my rides.
The way timezones are handled has changed. Previously, dates and times were shown according to the timezone set in profile settings. Now, dates and times are shown according to the timezone that the ride starts in.
There were a few problems with the old approach, with the main one being that the date of a ride when it is shown may not be the same as the date that it was considered to have when the power profile was generated. Why? The best-for-the-month and best-for-the-year power profiles are calculated ahead of time, and since it doesn’t know what timezone to use (the user can change their timezone), it uses the UTC date, but it’s possible for this to be in the wrong month or even year. For example, if you went for a ride at 7AM on January 1, 2013 in Melbourne (and your timezone is set to Australia/Melbourne, which — including daylight savings — is 11 hours ahead of UTC), the UTC date will be used when adding it to power profiles, and that date is 8PM on December 31, 2012.
The new approach completely avoids this problem by always using the local date. There are a couple of potential problems. Firstly, the wrong timezone might be chosen. This shouldn’t happen, but get in contact if it does. Secondly, this doesn’t work when there is no GPS data for a ride. If this is the case, the user’s timezone (at the time the ride was uploaded) is used.
That’s all for now. Oh, for any software developers reading this, I’ll probably be releasing an open source latitude/longitude to timezone lookup library and a web API in the near future.
Sometimes the data you get from your bike computer isn’t quite right. Sometimes you’ll see massive power spikes, and — if you’re like me — occasionally you’ll forget to stop the device at the end of a ride or forget to reset it before the next ride. Therefore, you can now chop off the start or end of a ride, and also edit the raw data. The controls are located in the menu next to the date.
Choosing Crop ride brings up something like the following, for a ride where I forgot to turn my bike computer off.
When you’re riding on an indoor trainer, seeing a map of your ride probably isn’t very useful. Therefore, it isn’t shown any more.
It works by detecting that the rider hasn’t gone far, so it might be confused if you ride to your next door neighbour’s house or if you do Fat Cyclist’s 100 Miles of Nowhere around the end of a cul de sac (or if your GPS drifts far more than I’ve ever seen), but it seems to work fine in practice. You’ll notice that the titles of these rides are more appropriate for rides done on a trainer.
Since the last post, many other things have changed:
There are now two more charts on ride pages to go with the power curve.
The first of these shows the relationship between the force on the pedals and cadence (and I think it’s the prettiest chart on the site). Each dot represents one second’s worth of data. This chart is divided by the grey lines into four areas (or quadrants):
This chart is useful to visualise the neuromuscular demands of a ride. Here’s a more thorough article about the interpretation of this chart.
The grey lines are drawn so that the vertical line is at a cadence of 80 RPM (by convention) and the horizontal line is at the force required to generate FTP (functional threshold power) at 80 RPM. The yellow line indicates FTP (which is why this line and the grey lines all meet… continue reading
The ride list used to be just that — a list of rides. That seemed a little boring, so now there is a summary of each month’s riding interspersed amongst the rides.
There is quite a lot in this summary, and most of it is based on power data. Take a look at this in practice on my profile.
The bit on the left is fairly self explanatory, with the number of rides, the distance travelled, and the elevation climbed. You don’t need a power meter to get this, and this is all you’ll see if you don’t have one.
The middle part is focused on the best power outputs produced in the month. There is a little power curve showing the best power for the month (in orange) and year (yellow). Purple highlights indicate that the best power for this month for this part of the power curve are also the best for the year. Next to that are the best average powers produced in the month for a few select time periods (which happen to roughly correspond with important physiological concepts like neuromuscular power (five seconds), anaerobic capacity (one minute), VO2 max (five minutes) and lactate threshold (twenty minutes)).
On the right is a miniature version of the training load chart. The blue line… continue reading
The training load page used to have a big table full of numbers. It’s now a lot prettier:
This chart shows what riding one has been doing over time in a way that can indicate one’s ability to perform. The following ideas are key to understanding this chart:
Therefore, in preparation for an important race, it is ideal to have a high LTS (after lots of training in the previous months), but a low STS (after tapering) and consequently, a positive SB. The exact numbers that work best in practice varies from athlete to athlete, so experimentation is required, but this chart makes it possible to quantify them.
For the mathematically inclined, the long-term stress and… continue reading
Cycling Analytics can now post your rides to Facebook when you upload them. It doesn’t spam your wall with links to this site; rather, once activated, it leaves a box like the following at the top of your Timeline:
To get this you just need to connect your Facebook account to your Cycling Analytics account. Go to the Linked accounts page under Account and click Connect in the Facebook box. A Facebook page will then appear asking for your permission for Cycling Analytics to post to your Timeline. Once connected, rides will be automatically posted to Facebook as you upload them. You should also click the button to post to Facebook all your rides that you have already uploaded. This ensures that the historical aggregations that Facebook shows are complete.
The box that is shown on your Facebook Timeline is an aggregate (well, two aggregates) of the data you have posted to Facebook for the current time period. It normally shows your last ride and how many kilometers you have ridden this month, although it seems to require multiple rides in the current time period before it shows the last ride. I haven’t quite worked out how Facebook chooses to display what it does.
Next up on the list of things to do related to sharing rides is… continue reading
It’s now possible to see your power as watts per a kilogram on the power curve.
You’ll first want to add your weight, and then you can click on the W/kg button at the top right of the graph and the values are shown as watts per a kilogram. This doesn’t yet support different weights over time, so old powers won’t be shown accurately if your weight has changed much.
Note: If you’re looking for a lot more information about what power outputs are typical or what counts as good, check out “How does your cycling power output compare?”.
With the recent hacks of LinkedIn, Last.fm and eHarmony that resulted in millions of passwords being stolen, now seems like a good time to say something about password security. I’m going to spend the rest of this blog post saying that passwords stored here are about as secure as they can be.
When you log into this website you provide an email address and a password to the server. The server then looks up the user with that email address, and then checks to see if the password is correct. This is where it gets tricky. The simplest way of doing this is by storing the password in the database, which makes checking the password when logging in trivial, except this means that all the passwords are sitting there in the database, and if anybody gets access to the database they can steal everybody’s passwords. Hopefully no unauthorised people get access to the database, but it can happen (just ask LinkedIn). The worst thing about having a password stolen is that people are lazy and reuse the same passwords, so once you have their LinkedIn password, you might also have their Facebook, email and online banking password.
Therefore, instead of storing the password itself in the database, the password is normally put through what’s called a cryptographic hash function which takes some input and always produces the same output given the same input, but it’s impossible to look at the output and work out what the input is. It turns a password like “bubbles” into “fe75bd065ff48b91c35fe8ff842f986c”, and that hash is stored in the database. Then, when somebody tries to log in, the password they entered is hashed and the two hashes are compared.
Using a hash function is all well and good, except it’s still possible to work out what somebody’s password is by putting lots of potential passwords through the hash function and seeing if any give the hash we’re looking for. This is a problem because computers are fast. It depends on which hash function is being used, but you can often test hundreds of millions of passwords per a second on a modern computer. And since a lot of people tend to use the same patterns when creating passwords, it’s possible to cut down the number of passwords you have to check dramatically by being smart — start with… continue reading