Ого, Майкрософт таки решил попробовать добавил в стандарт типы, правда предполагается что работать они всё равно будут только в момент компиляции, а рантайм будет считать их просто комментариями. И да, предполагается что эти типы так же будут совместимы с flow

https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/

цб не смог справится с трансляцией в тг(

Случайно открыл код Гришкиной соц сети. А там сразу видно что фронтенд джавист писал)
Впервые вижу чтоб в тайпскрипте кто-то использовал абстарктные классы
https://github.com/grishka/Smithereen

Всё больше появляется инфраструктурных утилит написанных на правильных языках. И это очень крутая тенденция. Ибо вечно тормозящие вебпаки и npm`мы уже достали.
Вот например пакетный менеджер на rust. Пока что он достаточно сырой и умеет всего в пару команд, зато работает существенно быстрее чем npm
https://github.com/dimensionhq/volt

Я кстати пытался перейти на pnpm, но там вечно беды с попыткой обновить его или поставить пакет глобально. И что удивительно, даже если все пакеты лежат в кеше, резолвинг зависимойстей занимает прям неприлично много времени, интересно будет посмотреть на volt

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

Клёвый видос про декораторы. Оч надеюсь что скоро их имплементируют в TS

https://youtu.be/-KszsBv4fbo

Да, иногда бывает полезным прежде чем что-то использовать, почитать доку)

Сегодня во второй раз я наступил на те же грабли.
Задача была интегрировать S2 кластера в продукт.

S2 это такие квадратики покрывающие нашу землю разных размеров. Их фича в том что каждый кластер имеет уникальный id из которого можно вычислить размер(level) квадратика и его координаты. Удобная штука

https://s2geometry.io/

Но есть у них один небольшой минус. Id слишком длинный. Id это число. Long. А js ни про какие лонги не знает. Тут есть либо число с плавающей точкой, либо большое число.
И вот id как раз хорошо влазит в большое число. Но есть небольшая пробелма. Встроенный JSON.parse ничего ни про какие большие числа не знает. Поэтому парсит он любые числа как с плавающей точкой

Как пофиксить? А хз. Правильного решения нет. Можно использовать строки вместо чисел. Но это бекенд надо переписывать. Можно использовать сторонние библиотеки для парсинга, но они попарсят за одно и другие числа. Можно написать свою json парсилку)

А большая часть операторов в рф так и не научились в ipv6. Грустная история(

Написал про интернет будущего, aka веб3, от лица человека, который просто хочет выполнить базовые действия, а не изучать протоколы.

Как сказал мой друг:
> Случился веб 3.0 момент
> Когда у всех куча говнопротоколов
> И никто не знает как их связать
> У меня коровы, у тебя козы, чтобы коровы начали отращивать шерсть, а козы давать коровье молоко нужно пойти в определенный сарай в который ходят все у кого есть животные и ждать 3 часа
> После того как твои коровы и мои козы станут совместимы мы сможем их переводить с комиссией в пол козы и пол коровы

На самом деле есть проекты которые пытаются связать другие блокчейны друг с другом. Например polkadot, но подозреваю что там нужно будет иметь еще одну валюту чтоб плотить комиссии)

В канале ещё две части крутого рассказа про время. Но я всё ещё считаю что время слишком сложная и кривая штука, с кучей легаси и её обязательно нужно отрефакторить

Работа со временем, часть 3/3

Тут уже будет про всякие курьезы. Во-первых, сильно не завидую составителям tz database, потому что им приходится иметь дело со сложностью человеческого мира и неточностью «обыденных» определений. Скажем, были города, в которых половина жила по одному времени, а половина — по другому. Какие-то города, например, Берлин, находились вообще в двух странах.

Другая штука — путешествие в прошлое. Как вы видели, Unix timestamp начинается с 1970-го, но можно ли продолжить его в прошлое? Немножко можно, насколько позволяет tz database, но там уже начинается неполнота данных о часовых поясах и прочий разброд. Если совсем сильно продолжать, то начинаются вопросы, скажем, переход между Юлианским календарем и Грегорианским был довольно долгим и хаотичным географически и зафиксирован не очень точно.

Сколько дней в феврале? 28-29, да? Часов в сутках? 23-25, как мы определили выше. А вот сколько секунд в часе? 3600, да? Не всегда 🙂 Про високосный год все знают, а как вам високосная секунда?

Но давайте по порядку. В 1972 запустили атомные часы, которые без остановки и прочего булшита отсчитывали по одной секунде каждую секунду 🙂 Их время называется International Atomic Time (TAI) и является, наверное, самой базовой величиной которая у нас есть (да, я говорил, что unix timestamp, но нет). С момента запуска они обогнали UTC на 37 секунд.

Далее есть UT1. Это время, основанное на вращении Земли, в предположении, что каждый новый год наступает ровно в 00:00:00 по UT1. Но! Штука в том, что вращение Земли, во-первых, замедляется, а во-вторых неравномерно и непредсказуемо (!! да, блин! Потому что по ней всякий хлам типа морей, магмы и материков болтается) и в итоге каждый год (по астрономическим наблюдениям вращения Земли) имеет слегка разную продолжительность в секундах.

UTC это компромисс для удобства обычных людей: это тот же TAI (т.е. атомные стабильные секунды), к которому иногда добавляют или отнимают по одной секунде в год, чтобы Новый год наступал как можно ближе к 00:00:00 по UT1 (астономическому).

Пока секунды только добавляли, обычно это делают как 23:59:60 31 декабря или 30 июня. Это происходит нерегулярно, основано на астрономических измерениях и никто заранее не может сказать, когда и сколько их в будущем будет добавлено. Последнюю добавляли в 2016-м.

Как это все переносится на Unix time? А никак 🙂 В Unix time такое понятие не заложено. Если число делится на 3600000, значит это граница часа. Удобно — но также и слегка неправда.

Что же делают компьютеры? Вариантов немного — можно либо повторить 23:59:59 два раза (перевести на секунду назад), либо заморозить часы, либо размазывать эту секунду тонким слоем на целые сутки (вроде Гугл этим хвастался, но не подскажу где).

Именно поэтому Unix time это очень удобная точка отсчета в практическом смысле, но немножко неправда до самого конца. Но на деле — скорее всего, о високосной секунде вам париться не придется. Правда в JVM был какой-то баг на эту тему (скорее всего, что-то про немонотонность часов), и я лично вроде как в 2012-м что-то там из-за этого у нас перезапускал.

Но это слишком редко, чтобы на самом деле имело смысл париться. А немонотонность часов — ну, из-за синхронизации времени они точно так же могут скакнуть назад, так что доверять нельзя никому.

Такие дела. Практически про работу со временем — как только понимашь, что происходит, сразу перестает быть сложно. Надеюсь, гайд вам чем-то поможет. Распространяйте, это может спасти чью-нибудь жизнь 🙂