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.
Many years ago I created a site that similarly syncs time between server and clients for the purpose of sharing stopwatches & timers. I found that using a websocket connection yielded a higher precision.
Indeed, it's frustrating when you're reading flat files of code. When reading foreign F#, I pull the code into Visual Studio so I can hover over the variables. It'd be quite convenient for GitHub to provide the type information on hover...
If a developer is frequently ignoring returned errors, then they have larger problems and it's their fault. Panic was not added to assist lazy programmers. Even though some API has solidified, an author could later add different return errors. Heck, if that function was calling other functions with returned errors, then the list of possible unique errors increases greatly. You should never ignore an err because you think you know the possible reasons.
The package author should modify the phrasing of that comment.
The package author means the error will be nil when the secret is 32 characters long; he doesn't mean you can completely ignore checking it.
Regarding when to use panic:
"The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values." http://blog.golang.org/defer-panic-and-recover
Panics should only be used in cases of programmer error or when the process is in an unrecoverable state.
Guns don't make me feel safe. Being properly trained on how to use defensive force makes me feel safe.
The error in your logic is that you're imagining yourself with a weapon, which indeed, is laughable and provably unsafe.
Edit: not going to bother replying and further make this thread a gun debate. Just want to state that YouTube videos of comedic skits and accidents doesn't nullify any argument. Humans will make mistakes; that's a fact of life.
When a stranger is in my home at 3am while my spouse and two kids are upstairs sleeping, I won't risk judging what he/she will or will not do. Even if I were alone, I wouldn't take that chance. My intention is not to preserve "human life" but the lives of my family and myself.
The use of `append` is absolutely clear. It always returns a new slice; the compiler forces you to take the value returned.
What scares you is the possibility that the underlying array may be copied to a newer, larger array giving enough space for the appended items. If there exists enough space, why bother with a new allocation? I want `append` to handle this for me. If you want different behavior, you can easily setup your own design with `copy`
Regarding this blog post, if you have multiple slices to the same array and are arbitrarily appending to any of those slices, then your design is wrong to begin with.
This isn't an edge-case but a lack of slice understanding.
Used to use PasswordBox but then switched to 1Password - I'm much happier. Unlike my experience with PasswordBox, I can keep my data on my cloud and can export any/all my passwords. However, my 1password trial has expired and I rather not pay $50.
I care about these things specifically because the IRS doesn't tax it. I save about 6k per year because my startup feeds me 5 lunches/3 dinners per week and pays for my public transportation. That's probably ~8k pre-tax dollars.
"exception oriented" programming is dirty. It's especially filthy when your expecting exceptions from a database for these reasons
a) Returning errors to the user is asking for a slipup handling the different exceptions, thus returning more info than desired. Cue the injection hacks!
b) Depending on the DBMS and its configuration, an upsert destined to fail may block reads and other writes from executing!
I had a feeling somebody would gripe about duplicated validation rules; it's a problem that needs an elogant solution on your own stack.
SQL constraints are a given; always use them. However, it's best practice to also validate your data before it gets to the database for several reasons.
A) Depending on a database check constraint failure is analogous to using a try/catch when a pre-emptive check would work; it's dirty.
B) You're putting unnecessary load on the hardest system to scale.
C) Users/systems will get instant feedback with a client-side validation. Depending on the data, this could be an enormous bandwidth savings.
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