nicksardo
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
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
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.
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.
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.
As I just said, a statistic is still a risk. A risk I will not take when it comes to family. You play it your way; I'll play it mine.
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.
"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.
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.