DEV Community: Amnon Sadeh

Slack Netiquette and Best Practices

Amnon Sadeh — Sun, 29 May 2022 14:50:24 +0000

No Hello 👋

Slack is foremost async (as opposed to a phone call or a face to face meeting).
So greeting "Hi!" and waiting for someone to respond before actually asking your question is counterproductive for both of you.
We're definitely not against politeness - just string both parts together, for example: "Hola! Are we compliant with WCAG level A?"
Learn more: https://nohello.net/, https://nohello.club/, https://no-hello.com/...

Less Messages ↩️

When writing more than one paragraph, don't send them as separate messages.

Why?

In a teeming chat, fragmented messages might get scattered around other members' messages, therefore harder to follow
Someone might not notice you're still typing and ask you a question regarding your first paragraph which you're already about to answer in the second one
Fragmented messages cause unnecessary notifications (and some of us would rather not mute certain channels)

You can:

Either press shift-Enter to start a new line within the same message
Or better yet, change your preferences so plain Enter always starts a new line (and use ⌘-Enter (Mac) or ctrl-Enter (Windows) to send)

Always* Reply in Thread 💬

👎 Replying in a 'main' message triggers a notification for all channel members.

👍 Replying in a thread triggers a notification only for members who also replied to it.

This not only reduces noise, but also allows for better organized discussions.

(* it's less of an issue in a direct chat with someone)

Channels Privacy 🔒

When creating a new channel:

If sensitive information will be discussed in it (anything that relates to customers, investors, prospect employees, etc.) - set it to private. If in doubt - set it to private.
Only if no such information will be discussed (book club, basketball team, lan party, etc.) - it's probably okay to leave it as public.

While we're on this subject: don't discuss sensitive information via WhatsApp.

#general 🆚 #random

The #general channel is meant for company-wide announcements (e.g. "There's an electricity maintenance at the office at 19:00", "Next month we're hosting a meetup - save the date!", and so on).

#general is the only channel you cannot leave. Once the company gets big enough, we might restrict who can post to it.

On the other hand, the #random channel is the digital equivalent of a water cooler conversation - meant for casual stuff, non-work related, nerdy humor, etc.

Be Generous with Emoji Reactions 🙂

In 2014 Slack added 'read receipts' (arguably their most requested feature) to their backlog:

Slack

@slackhq

@hermansje @svencharleer Planning on something like read receipts. 🎉 Thank you for the kind words! (And welcome @svencharleer)

23:20 PM - 26 Aug 2014

Year after year, they kept postponing it. Until 2018 when they actively decided against it:

Slack

@slackhq

@godismyjudge95 We decided against adding read receipts, but many people use emoji reactions on messages as a sort of voluntary (and, dare we say, more fun) version of a read receipt. 🐝

22:55 PM - 09 Oct 2018

So if you read a message like "Today's all-hands meeting will be held 30 minutes earlier", nobody can tell whether you read it or not, so it's a good citizenship to react with an emoji (👍, 👌, etc.) to signal you actually did.

Add a Profile Photo 🧑‍🎤

Slack’s default avatars are... uninspiring:

An actual photo is great, but any picture can add a personal touch and will help everyone with the #1 general netiquette rule: remember the human.

How does Math.random() work?

Amnon Sadeh — Mon, 13 Jan 2020 21:30:32 +0000

Prolonged Prologue

Recently I worked on a stateless server. In other words, if and when it sends a second response to a client, it has no context of the first one.

Such backend code is pretty great – simple, clean, and easily testable.

Auditing or debugging? Not so great. Within a certain timeframe the backend may serve many clients and though there's enough information to reconstruct which response originated from which client, we're lazy and just wanted to "color" them for quick identification.

We decided to make the frontend generate a (pseudo-)random string when starting-up and send it with each request. No need for a convoluted UUID or something similar. Just plain ol' Math.random().toString(36).slice(2).

Fat Chance

During code review I explained to my colleague that 99.9% of the time it will make our lives easier and the 0.1% chance of 2 clients generating the same string is no big deal, because as explained, we can still distinguish between them like we did before.

She approved by change, got up, and as she walked away she pondered aloud But it's not really 0.1%, is it? Would be nice to figure out the actual chance of collision.

Down the Rabbit Hole

I knew Math.random returns numbers between 0 (inclusive) and 1 (exclusive) with roughly equal probabilities across that range, I wasn't sure however how it does that.

First stop – MDN of course! Their documentation for Math.random informed me that numbers in JavaScript are IEEE 754 floating point numbers. IEEE 754? What's that about exactly?
Second stop – ECMAScript Spec. The Number type section revealed that IEEE 754 is just a fancy way of saying double-precision 64-bit floating-point number. Frankly, this is still too fancy, so I headed elsewhere.
Third stop – Wikipedia. The double-precision article threw me back to my CS degree with terms such as endianness and more importantly significand (AKA mantissa).
- The last two sources taught me that even though this format has 2⁶⁴ possible values (duh!), reserving 3 of them to represent -0 (which is different from 0, mind you), infinity, and -infinity, is pocket change relative to the 2⁵³ NaN values. Yep, you read that right: given arbitrary sets of 64 bits, if you ask what number does this represent?, 1 out of 2048 times the answer will be it's not a number. 🤯 #MindBlown
- Speaking of possible values, every non-zero number can take the shape of ± 2ⁿ × 1.something. For example 2020, the current year, is 2¹⁰ × 1.97265625. The benefit here is that the "1." part can be assumed and doesn't need to be stored. Thus the significand has an extra bit – making the number a bit more precise. 😂 #DadJokes

At this stage I stopped reading in order to experiment what numbers can JavaScript store. The smallest one below 1 turns out to be 0.9999999999999999. i.e. if you enter 0.99999999999999994 in the console, JS will omit the last digit, and if you enter 0.99999999999999995 it will just round up to 1.
The next numbers are:
0.9999999999999998
0.9999999999999997
0.9999999999999996
0.9999999999999994
0.9999999999999993
0.9999999999999992
0.9999999999999991
0.999999999999999

0.9999999999999995 is not absent by mistake. Remember these numbers are displayed as decimals, but are binary under the hood. Expect rounding errors when "translating" back and forth.

Naïvely I thought, Well, if I continue with these small decrements, after about 10 quadrillion times, it will go down to 0.0000000000000001. I immediately realized this misses the whole point of floating-point! 😂 #DadJokes

It's not the end. From there, we can again decrement 10 quadrillion times
0.00000000000000009999999999999999
0.00000000000000009999999999999997
down to
0.00000000000000000000000000000001
and so on.

This revelation – the density increases towards 0 – is in fact tied to the subnormal numbers (that "1.something" from before? for them it's actually "0.something").

I'm dwelling on this because Math.random is supposed to return values with approximately uniform distribution. This means the set of its possible results is smaller than the general set of numbers JS can represent in the range [0,1). Or looking at it the other way around: there are fractions that you can set yourself, but can never get from Math.random.

Back on Track

Penultimate stop – The V8 blog explained how about 4 years ago Math.random switched to use the xorshift128+ algorithm (noting other major browsers switched to it as well). This is almost what I was looking for – as this algorithm deals with generating integer numbers.
Final stop – The glorious V8 source code unveiled how it's done (I believe other engines behave similarly): ToDouble takes the latest generated integer, right-shifts it into what would shortly become the significand, sets the exponent to 0x3FF (which means +2⁰) and casts it to double. This yields 2⁰ × 1.random and the only thing left to do is subtract 1.

  static inline double ToDouble(uint64_t state0) {
    // Exponent for double values for [1.0 .. 2.0)
    static const uint64_t kExponentBits = uint64_t{0x3FF0000000000000};
    uint64_t random = (state0 >> 12) | kExponentBits;
    return bit_cast<double>(random) - 1;
  }

Answer to the Ultimate Question

There are 2⁵² (or 4,503,599,627,370,496) possible values for Math.random to return. It is a few quadrillions after all!

I plugged this value into the general equation for the birthday paradox and was relieved to learn that even with thousands of simultaneously connected clients, we have better chance of winning the lottery than have a collision.

Post Trauma

I obviously called my colleague to share these findings with her. She nodded understandingly, then paused for a moment before remarking Good, now we also know the chance of an empty identifier.

To which I replied, Say what now?.

Yeah, there's 1 in 2⁵² chance to get any specific value from calling Math.random() and one of those is 0. In that rare yet possible case slice(2) will leave you with an empty string. Not that it matters too much – you said you wanted to "color" the traffic with a string. I guess transparent is as good color as any.

I'm never asking for your code review again.

📟 Let me know if you ever use Math.random() and get 0.