nicksardo

Thanks for the feedback!

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.

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.

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.

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.

First, your statistics are moot.

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.

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.