TypeScript: худший лучший язык программирования

во втором примере (который не компилируется) по ошибке остался лишний `as const`

TypeScript: худший лучший язык программирования

Да, тайпчекер ещё не научился проверять, что переменная нигде больше в
функции не меняется, не смотря на то, что объявлена изменяемой

Все-таки дело не в этом, а в чем-то другом. Выглядит как баг компиляторе. В общем случае TS отлично видит, что переменная больше нигде не меняется.

Упрощенный пример:

function rand(): "bar" | "foo" {
    const BAR = "bar" as const
    let result = BAR;
    return result;
}

result тут все еще let - но все компилируется.

А вот это уже не компилируется - хотя у константы BAR выведенный тип остался без изменения

function rand(): "bar" | "foo" {
    const BAR = "bar" as const
    let result = BAR;
    return result;
}

Зачем использовать materialize и dematerialize операторы и что такое Notification в RxJS?

Да, вы правы, а я был невнимателен. С race будет то же самое только в случае, если оба источника одноразовые (к примеру, запросы к серверу).

Пожалуй да, вариант с materialize самый простой. Даже удивительно, что в rxjs из коробки нет какого-то оператора для такого поведения.

Зачем использовать materialize и dematerialize операторы и что такое Notification в RxJS?

Первый случай с задержкой можно проще:

timer(3000).pipe(mapTo(throwError(...))

Второй - еще проще

race(this.first$, this.second$)

Я использовал materialize чуть ли не один раз в жизни. И вот тоже сейчас смотрю - пожалуй, мой случай можно было реализовать через defaultIfEmpty, и было бы чуть проще.

Памяти Владислава Крапивина

Как-то у него сочетались сказки с жестокостью. Даже сейчас какие-то слегка жутковатые вечатления от прочитанного. Белый шарик матроса Вилсона, Синий город на садовой. Не все книги, конечно - были и просто светлые детские книги (те же Алые перья стрел). Но первые ассоциации, что приходят на ум при упоминании Крапивина - именно вот те, жестокие.

Фасилитация на практике, или Как команде принять одно решение для всех

Мы используем подобный подход для приоритезации тех долга в команде. Только первая фаза - генерация идей - у нас асинхронная (и порой довольно растянутая во времени): перед митингом все могут добавить свои идеи в общий список.

Фасилитация на практике, или Как команде принять одно решение для всех

Для руководителей, которые по любому поводу хотят собраться и хорошенечко потрындеть.

Как раз наоборот. Это для команд, которые принимают решение совместно, а не полагаются на руководителя, который скажет, что сделать.

После «фасилитации/фасилитатора» полностью читать статью перехотелось

Да, стремноватая калька. Но смысл ясен - кто-то, кто ведет обсуждение. Председатель? На суть статьи это не влияет - там все по делу.

Закон Кёрли: Делай что-то одно

SRP и DRY вообще несвязанные друг с другом принципы. Легко можно представить себ код, удовлетворяющий SRP, в котором при этом много повторения. Равно как и наоборот.

Атака «Браузер внутри браузера». Как защититься

Hello.js - достаточно популярная библиотека для входа через соцсети. По умолчанию открывает именно попап. У них на главном сайте вверху ряд кнопок - сами попробуйте.

Пишем чистый код при помощи деструктуризации объектов в JavaScript

Понял. Все же дополнительные операции не в деструктуризации как таковой, а именно в rest. Но если кто-то делает rest с деструктуризацией, то предполагается, что ему таки нужно это значение.

Кстати, ваш антипаттерн - он про spread syntax, тут вообще нет деструктуризации.

Пишем чистый код при помощи деструктуризации объектов в JavaScript

А что именно в деструктурировании тормозное?

const {name} = object
const name2 = object.name

у этих двух вызовов будет разница в скорости?

Brave: эфемерные куки для правильной приватности

А у Chrome есть Cookies Having Independent Partitioned State (CHIPS)

(кстати, это еще и игра слов: chocolate chips cookies - популярный вид печенек с кусочками шоколада)

Как и с случае с Firefox, печеньки тут только секционированные, но не эфемерные - то есть не очищаются автоматически при закрытии браузера

Калькулятор на типах TypeScript

Возможно, минусующие среагировали на $mol_ в названии типов? Я с ходу подумал было, что вы выкатили реализацию на чем-то отличном от TS. Но перешел по ссылке - и там, конечно, чистый TS, так что сравнение вполне честное

Калькулятор на типах TypeScript

Заминусовали, может, и зря.

Но с "куда проще" не согласен. У автора в статье кода раза в 2 меньше. Может, конечно, из-за разного форматирование / разбивки по строкам. Но и существенного выигрыша в сложности тоже не вижу в вашем варианте.

Из плюсов - финальный тип вызывается напрямую

type result = $mol_type_int_calc< '7+5-2*2+1' >

тогда как в статье обертка из двух типов (

CalcByExpression<StringToCalcExpression<'7+5-2*2+1'>>;

Калькулятор на типах TypeScript

Тайпскрипт клевый!

Тут на волне Wordle-хайпа недавно проскакивала реализация Wordle на типах Тайпскрипта.

https://github.com/johanneslumpe/typescriptle

JSON Web Token и Secure Sockets Layer

Ну то есть, конечно, да. Сессии наше все. Просто и надежно. Несколько миллисекунд на чтение сессии из кэша, скорее всего, приемлемая цена за меньшую сложность кода.

JSON Web Token и Secure Sockets Layer

Проблема обычной сессии в том, что каждый запрос создает нагрузку на ваш сервис аутентикации. Решении - в куку с сессией записать дополнительные данные (например, айди пользователя, список прав). И чтобы защищиться от подделки, дополнительно подписываем. И еще нам надо знать, как давно мы эти доп. данные записали (они имеют обыкновение устаревать). В итоге мы изобрели свой формат для того, что уже стандартизировано в JWT.

JSON Web Token и Secure Sockets Layer

ведь после обновления страницы он будет утерян

редирект на сайт auth-провайдера выглядит примерно так:

request: GET /login?redirect=https://my-site.com | Host auth.com

response: 302 | Location: https://my-site.com/?refresh-token=AABBCC

То есть при условии, что на домене auth.com у нас есть кука с сессией, редирект туда-обратно осуществялется без участия пользователя.

любой сторонний js код на сайте сможет это прочесть

• сторонний код его другими способами может прочитать (пропатчить window.fetch, прочитать из location.query после редиректа, etc).

• сторонний код так просто не прочитает переменную, если она в глобальный скоуп не экспортируется прямо или косвенно.

JSON Web Token и Secure Sockets Layer

Получается когда токен будет скомпрометирован, мы сможем бесконечно им пользоваться?

Так же, как и утекшей сессией (в типичном случае с session id в кукиз). Можно предусмотреть разные механизмы защиты - например, периодически инвалидировать сессию и заставлять юзера перелогиниться, делать лимит на число одновременных сессий у юзера.

"просто держим в памяти" - Тоесть при каждой перезагрузке станицы мы делаем refresh?

Да. Это один апи-запрос к auth-провайдеру

> Refresh-токен держим в памяти, никуда не записываем для безопасности.

вы наверное имели в виду Access - токен ?

Access- токен - это само собой, как описано в предыдушем варианте. Я как раз про refresh-токен, чтобы минимизировать риск его компрометации. Именно поэтому в данном сценарии при обновлении страницы придется делать редирект на страницу auth-провайдера, для получения нового refresh-токена.

хранить Access в памяти мне искажаться вполне приемлемой, Спасибо) но это тоже уязвимость, так как данные можно получить

Каким образом их можно получить?

JSON Web Token и Secure Sockets Layer

В ответе может быть несколько заголовков Set-Cookie, каждый выставляет одну куку.