1) Click on the stopwatch timer title; you can edit it in place. Indeed, discovery of this is not great. My UX designs tends to be quite minimal. I'll try to make this more obvious.
2) I'm considering building use-case specific sites with the same backend to more adequately support each. I despise how many generic sites overload UI with junk aimed at certain power users for a use-case I don't have.
3) Splits are already supported for stopwatches.
4) This touches an occasionally requested feature of making sequential "entities" - most often in the context of circuit training. 5 minutes of bench pressing followed by 5 minutes of jumping jacks, etc. Allowing the addition of a stopwatch at the end of the sequence makes sense. Thanks
I'll do that, thanks. I've never had feedback that's indicated people wanted to know.
It uses NTP's clock synchronization algorithm to get the servers' time. This is done over a websocket as it's twice as fast as a typical ajax request/response. Then all changes are made using the browser's idea of server time.
At the bottom of the page, you can see your computer/phone's time offset and precision.
I created https://chronograph.io back in 2014 so people can share accurate, live stopwatches and timers. Other sites "share" by putting the start epoch & duration in a url querystring; Chronograph is one of the first to actually share a session with concurrent edits.
Of the years, it's found a variety of use cases:
- Online scrum meetings.
- Recording starts & stops of races when they're geographically separated.
- Coordination of breaks between language interpreters.
- Syncing of podcast recording with multiple guests.
- Video game twitchers to broadcast when they'll play
Former Google engineer here. My team used the open source Go B-Tree implementation but I replaced it with a non-interface version over a year ago because of performance issues. The lack of generics at the time wasn't a problem because code generation is quite easy via Google's build system.
Replacing interfaces is only part of the performance improvement. When it comes to the B-Tree, you want to improve data locality as much as possible. My implementation also replaced slices with arrays (again using code gen to specify the tree degree). This means each node on the heap literally contained all the keys and, and in some cases, the values themselves. It also helped to split the key/values into separate arrays so all the values didn't interlace the keys.
The insert/retrieval benchmark times compared to the open source version were significantly faster. Since this version relied on codegen, I never bothered to push it publicly. Though, there are tons of B-tree implementations on github, each touting themselves as fastest.
1) Click on the stopwatch timer title; you can edit it in place. Indeed, discovery of this is not great. My UX designs tends to be quite minimal. I'll try to make this more obvious.
2) I'm considering building use-case specific sites with the same backend to more adequately support each. I despise how many generic sites overload UI with junk aimed at certain power users for a use-case I don't have.
3) Splits are already supported for stopwatches.
4) This touches an occasionally requested feature of making sequential "entities" - most often in the context of circuit training. 5 minutes of bench pressing followed by 5 minutes of jumping jacks, etc. Allowing the addition of a stopwatch at the end of the sequence makes sense. Thanks