​А вот вам на выходные один фильм и один сериал про историю консольного геймдева.

Хотя я никогда не понимал прикола обновляемого раз в 10 лет игрового компьютера, лядских джойстиков и игр по 100500 баксов и всегда был пекабоярином, эти фильмы показались мне интересными.
Фильм повторяет большую часть сериала, но есть смысл посмотреть их оба.

1) High Score - https://www.netflix.com/ru/noscript/81019087
2) Console Wars - imdb.com/noscript/tt3561990/

Еще рекомендую Indie Game: The Movie про разработку игр (я как-то уже про него писал - https://news.1rj.ru/str/nosingularity/469)

#AR
На видео происходит инверсия записанного трехмерного и временного пространства, при помощи AR.

Все уже посмотрели Довод?
https://twitter.com/thorikawa/status/1309066544924766210?s=20

​Пятничный SQL-WTF
Понедельничный SQL-TIL #4

Динамить вас третью неделю подряд было как-то по-свински, по этому встречайте ;)

Disclamer: скорее всего вы никогда не столкнетесь с таким синтаксисом и архитектурой в реальной жизни. Но зато сможете блеснуть эрудицией перед своими коллегами :)


1 wtf из 5 - алиасы типов
Разных названий одних и тех же сущностей в PostgreSQL не очень много - всего 24 пары.

int2 -> smallint
int4 -> integer

и так далее.
Я не буду перечислять их все, и запоминать эти соответствия не нужно. Для этого будет правило в holistic.dev


2 wtf из 5 - тип float
Тип FLOAT (он же single-precision floating-point, он же IEEE 754, оно же число одинарной точности) в PostgreSQL отсутствует. Но т.к. в SQL он описан, то для совместимости его реализовали через хитрые алиасы.

- float(p), где p от 1 до 24 или float4 - эквивалент real
- float(p), где p от 25 до 53 или float или float8 - эквивалент double precision
- Значения p вне допустимого диапазона вызывают ошибку

Как это запомнить? Да никак! Не используйте тип float. holistic.dev вам напомнит :)


3 wtf из 5 - self join
Это пункт не совсем про wtf, больше про bad/good practice.
Self join используют обычно в 3 случаях: когда у вас EAV, когда вы храните в таблице дерево или когда нужно pivot'нуть аналитический запрос.
EAV мы обсуждать не будем (надеюсь, что никто из вас таким не занимается), деревья в таблице обрабатывать лучше через RECURSIVE CTE, а вот про пивот и аналитику стоит поговорить. Есть статья на modern-sql.com с примерами, но я расскажу коротенько.

Если вам нужно несколько агрегатов из одной таблицы с разными условиями, то отличным вариантом для этого в PostgreSQL является конструкция FILTER (WHERE ...).
Например, вы хотите посчитать количество чего-то с разными статусами для каждого юзера:

SELECT
  user_id, 
  COUNT(*) FILTER (WHERE status = 'new') AS count_new,
  COUNT(*) FILTER (WHERE status = 'canceled') AS count_canceled,
  ...
GROUP BY user_id

Или статистику по месяцам, где каждый месяц должен быть отдельным столбцом.
Проблема в том, что этот функционал реализован только в PostgreSQL :(
В других базах предлагается использовать CASE.

SELECT
  user_id, 
  SUM(CASE WHEN status = 'new' THEN 1 END) AS count_new,
  ...

В holistic.dev будет правило, находящее места, где можно использовать FILTER (WHERE ...) вместо CASE или self join.


5 wtf из 5 - 0.1 + 0.2

SELECT 0.1 + 0.2;
-- 0.3

SELECT 0.1::float + 0.2::float;
-- 0.30000000000000004

ЭЭЭ?
Спокойно, это фича.
Причем практически во всех языках программирования.

Поэтому желательно избегать тип double precision в тех случаях, когда с этими числами предполагается производить математические операции (в том числе и агрегаты).
Да, у нас в holistic.dev есть правило double-prescision-instead-numeric, которое срабатывает на определенные размерности NUMERIC. Для двукратного увеличения производительности арифметических операций с полями этого типа можно заменить NUMERIC на DOUBLE PRECISION. Но взамен мы получим проблемы, описанные выше.

Именно из-за этой проблемы не рекомендуется хранить деньги в типах с плавающей точкой. Храните числа в центах, сатоши, wei или любой другой не квантуемой единице.
И никогда, слышите, НИКОГДА не занимайтесь математикой с деньгами на фронте. Все получайте только с бэкенда и желательно в целых числах!


Первые три выпуска:
https://news.1rj.ru/str/nosingularity/535
https://news.1rj.ru/str/nosingularity/541
https://news.1rj.ru/str/nosingularity/548

​Больше дедов богу дедов!

Мой старый друг запилил канал про фронтенд и будет в лучших традициях старых Перунов (зачеркнуто) пердунов ныть о том, что «нынче не то, что давича» и что «я-то в советские времена ооо!».

Может даже узнаете что-то полезное :)

https://news.1rj.ru/str/angry_front_end

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

Отдельных ответов заслуживают вопросы: как можно было этого не заметить и какой мудак решил использовать для этой цели колонки вместо строк.

Вывода тут можно сделать два:
- не связывайтесь в .gov, у них все через жопу. В любой стране.
- не используйте в качестве систем управления базами данных те инструменты, которые таковыми не являются (привет любителям sqlite)

каждый раз видя такие графики вспоминаю историю как рубисты положили постгрес, который крутился на 70 cpu...


https://www.2ndquadrant.com/en/blog/oltp-performance-since-postgresql-8-3/

​Штош....

На заметку всем, кто рекомендует мне выложить все в опенсорс:


https://twitter.com/tim_nolet/status/1317061818574082050

Вроде бы и смешно, но я знаю несколько человек, которые тянут язычок у куллера на себя. У всех офисных куллеров, что я видел, язычок в таком положении фиксируется и можно не держать чашку в ожидании наполнения.


https://twitter.com/towernter/status/1317479702349647873

А пока идет перепись тех, у кого есть бесплатная столовка в офисе и тех, кому приходится наливать воду в куллере, аки холопам, вот еще один наброс в тему канала:

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

Бенчмарк (как и все бенчмарки) барахло (и переписывать все на сях я не буду), но в конце списка оказались именно те, кого мы там ждали: руби и питон :)

https://thenewstack.io/which-programming-languages-use-the-least-electricity/

Теперь мы знаем, кто виноват в глобальном потеплении...

​Пятничный SQL-WTF
Понедельничный SQL-TIL

Пару недель я занимаюсь описанием грамматики SQL-синтексиса базы snowflake. Это такая cloud-only база, которую пилят 8 лет, 1500 человек сотрудников, вышли месяц назад на IPO с оценкой $70B...

Как-то давно в твитерах молодежь жаловалась на непонятную документацию постгреса:
https://news.1rj.ru/str/nosingularity/165

Как же выглядит синтаксис snowflake?
Выглядит он как письмо дяди Федора родителям (олды тут?).


1) Нет нормальной структуры.
Часть команд очевидно где-то есть, но найти их не получается. Например, есть описание ALTER ACCOUNT, а CREATE ACCOUNT нет.
Оно, наверное, логично - аккаунт, это сущность, получаемая в результате регистрации. Но если выполнить "несуществующую" команду

CREATE ACCOUNT user

то получим не syntax error, а SQL access control error: Insufficient privileges to operate on account 'USER'


2) Одни и те же сущности описываются разными ключевыми словами:

SOURCE_COMPRESSION = AUTO_DETECT | GZIP | ... | NONE
COMPRESSION = AUTO | GZIP | ... | NONE

еще:

FILE FORMAT, FILE_FORMAT, STAGE_FILE_FORMAT

и еще:

NETWORK POLICY, NETWORK_POLICY

3) Определения повторяются.
Описание параметров FILE FORMAT занимает несколько страниц и копируется из раздела в раздел, везде, где это свойство используется. Видимо, зарплата привязана к количеству строк :)


4) У команд есть алиасы, но про них ничего не сказано.
Случайно узнаешь об этом из примеров. Есть команда REMOVE, во всех примерах - RM.


5) Содержимое строк является частью синтаксиса.

SCHEDULE = '{num MINUTE | USING CRON expr time_zone }'

или вот:

externalStageParams (for Amazon S3) ::= URL = 's3://_bucket_[/_path_/]' ...
externalStageParams (for Google Cloud Storage) ::= URL = 'gcs://_bucket_[/_path_/]' ...
externalStageParams (for Microsoft Azure) ::= URL = 'azure://_account_.blob.core.windows.net/_container[/_path_/]'

Видимо, есть некоторые сомнения в когнитивных способностях пользователей azure, т.к. одного протокола оказалось недостаточно...


6) В некоторых командах строки можно НЕ БРАТЬ в кавычки.
В документации:

PUT file:///tmp/data/mydata.csv @my_int_stage;

А можно брать. Но узнаешь, только если попробуешь...


7) Ключевые слова иногда можно использовать в кавычках:

... COMPRESSION = AUTO ...
... COMPRESSION = 'AUTO' ...

8) Свойства описаны как обязательные, но на самом деле таковыми не являются.
И даже в примерах об этом ничего не нет. Например, в FILE FORMAT можно пропустить описание type и тогда будет считаться, что за основу взят CSV.


9) Порядок некоторых свойств может быть произвольный.
Узнать какие именно свойства не зависят от порядка можно только императивно. Например, о том, что CLUSTER BY можно воткнуть перед описанием колонок я нашел в примере на гитхабе у какого-то левого чувака:

create or replace TABLE "tablecluster" cluster by LINEAR(DATE, ID)(
  DATE TIMESTAMP_NTZ(9),
  ID NUMBER(38,0),
  ...
);

10) Описанный ограничения синтаксиса некоторых свойств в реальности не существуют.
В примере выше CLUSTER BY описан как

CLUSTER BY ( expr1 [ , expr2 ... ] )

То, что параметром может выступать функция, не сказано нигде.


11) Описание аналогичных команд имеет разный формат.

PUT file://_path_to_file_/_filename_ internalStage
GET internalStage file://_path_to_file_/_filename

Видимо, это связанно с возможностью использования свойств в произвольном порядке, но блин!


Опустим подробности, что зарегистрироваться жителям РФ они не дают. Просто "ой, не работает" на этапе регистрации, а в каких-то формах страны просто нет.
Но когда вы прорветесь в админку, можно будет порадоваться - они вернули мне мой 2007. Такая убогая и тормозная админка ставит их на одну ступень со всеми серьезными игроками - гугл и амазон :)
И это не считая того, что там визуально не обозначено и половины тех функций, которые описаны в документации.

Все выпуски SQL-TIL:

1) https://news.1rj.ru/str/nosingularity/535
2) https://news.1rj.ru/str/nosingularity/541
3) https://news.1rj.ru/str/nosingularity/548
4) https://news.1rj.ru/str/nosingularity/572
5) (snowflake) https://news.1rj.ru/str/nosingularity/582

​В этом довольно специфичном тесте PostgreSQL выносит MSSQL и MySQL вперед ногами:


https://www.mssqltips.com/sqlservertip/6607/delete-sql-performance-for-sql-server-mysql-and-postgresql/

Ребята из @profunctor_io большие молодцы и я всегда готов поддержать их призывы рассказать про профунктор-джоб, поэтому вот:

Не секрет, что лучшие вакансии в айти расходятся задолго до попадания на hh и linkedin. Одно из мест где можно ловить такие варианты это канал Профунктора: NVIDIA, Revolut, Bolt, Мосбиржа и другие лучшие карьерные варианты для разработчиков появляются там регулярно. Стоит подписаться, чтобы быть в курсе того сколько нынче платят «по рынку», и не гнуть спину за полцены из-за того что неудачно прособеседовался год назад.

@profunctor_jobs

Андрюха, у нас пхп, возможно битрикс, по коням!