yet another hungarian nobel prize winner who managed to get it while left hungary long ago. yet hungarians going to be proud of her. this country such a shame.
You are correct on the watt, weight computes but I think the aerodynamic saving is worthless on a gravel race. People are not going that fast on gravel to gain anything from aerodynamical optimisations. You need to keep going at least 40 km/h to have any advancement without up-down movement which is obviously not something that you can achieve on gravel.
It is quite easy to check out actually on a road bike. Ride at a steady pace without pushing hard, hands on top, then put your hands in the hoods of the brake lever, elbows at 90° without pushing more, you will gain easily 1kph just by changing position. More if it is windy.
You have just proved you haven't rode a cyclocross bike. Since those bikes' center of mass is higher than the road bikes it is really "nervous" on high speeds for example long descents.
But crit races are not like coming down from Stelvio kind of speed where nervousness counts. Crit races are exactly like cx races but on asphalt or at least where I'm in Europe ;)
I rode my cyclocross bike in the Swiss alps for months while waiting for my custom road bike. It was perfectly fine descending mountain passes.
As I said, that so called nervousness is overstated because people overthink it. BB height matter but for the most part we intuitively and inconsciously accounts for it and adapt. Also the difference is minute, from a 5 mm to 15mm. It is not like we switch from a road to a tall bike either. And guess what? A tall bike is pretty easily rideable, there are even people doing offroad on them.
A lot of people do not size their cross bike right - they ride a top tube length that is too short. Maybe this also helps with tight turning radius (which could be an advantage during a cross race).
not true - the "nervous" feel is because people also tend to ride cyclocross bikes that are shorter (top tube length). There is no reason a cyclocross bike cannot be designed with the higher bottom bracket AND a longer top tube - I never understood why the frames were designed like this in the first place (maybe for weight savings?)
We have a data integrations feature that allows you to connect external data sources (e.g. S3) with your sandbox.
You can basically combine this with "Scheduled Training", and it'll retrain your model on a schedule - pulling in the new data. This is V1 and does not yet handle more complex, event based retraining. This is something we know is crucial for tons of use cases and we're planning on adding it in the coming months.
Happy to chat and get your feedback on what kind of event sources you might want to trigger the model to retrain on new data.
You use the standard datetime libraries so you don't have to deal with all that complexity. Only, they automagically muck with the data, including irrelevant precision, such as time and timezone and daylight savings time for a calendar date.
And for the sake of completeness, your application allows the customer to specify a default timezone (usually that of their headquarters or something) and individual users to specify their own (useful if they work remote or in another office or something).
So now you have your database's timezone (and datetime handling), your server's timezone, your application's timezone (and datetime library handling), the customer's configured timezone, the user's configured timezone, their client's own timezone handling (which may be different if they're on a business trip in a different location), all screwing with the date of something that shouldn't even have a time, timezone, or daylight savings in the first place.
That's an endless whack-a-mole of bugs. And trying to just use UTC everywhere possible only gets you so far.
I can only imagine needing to toss in standard/daylight timezone switch in there. Billing code really is the pinnacle of developer pain. It mixes the arbitrariness of special case business and customer rules with the absolute horror of time and date math.
Yes exactly. When I look at the settings in the app it says "PINS keep information stored with Signal encrypted only you can access it."
However the page that you linked does not mention encryption. I can't see anywhere explain exactly what the PIN does. Does it encrypt your data or not?
This would only be true as long as whatever the decryption algorithm is, it is not possible to run it off of the device, or otherwise interrupt the process of resetting the counter used to decide to rate-limit or self-destruct.
Famously older iPhones were susceptible to resetting the 'Invalid Attempts to Unlock' counter that the iPhone stored in the Secure Element to workaround the PIN rate-limit, by halting the CPU before it had a chance to increment the value, but right after it returned the pass/fail result.
So Signal could be entangling this PIN with a key from the Secure Enclave, and then trying to securely increment a counter inside the Secure Enclave to implement exponential rate-limiting and self-destruct, but it would be tricky to implement correctly.
