​​В прошлый понедельник SQL-TIL не зашел, поэтому я решил сделать перерыв :) Кип ин тач.

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

​Морской бой в постгре:

https://github.com/Firemoon777/sql-battleships

Так проходит совет директоров тесла (прямо сейчас)

#prog

Переписал по работе одну утилиту для анализа логов. Раньше для разбора строк использовались регулярные выражения, а я заменил на наколенный лексер. В результате утилита, которая почти 23 гигабайта перемалывает за чуть больше, чем за 5 минут, стала на тех же данных работать за чуть меньше, чем полторы минуты. Результат, разумеется, тот же самый.

​Чат, ай нид хелб!

Возможно, не все знают, но я занимаюсь разработкой статического анализатора для SQL - holistic.dev

И я решил написать ряд статей с разбором результатов анализа баз разных опенсорсных проектов.
Да, прям как PVS-Studio на хабре.

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

И кажется, GitLab идеальный кандидат. RoR, много у кого есть и часто используется локально.

Поэтому ИЩЕТСЯ ДОНОР С ON-PREMISE GITLAB’ом!
Внимание!
У меня не будет доступа к вашим данным.
У меня не будет доступа к вашему коду.
Я не буду знать переименовали ли вы master в main и используете ли вы gitflow.
У меня даже коннекта к базе GitLab'а не будет.

Мне будет доступен только список SQL-запросов, которые GitLab делает к PostgreSQL.
И то их вы пришлете мне сами.

Схема базы у GitLab лежит в репозитории в готовом виде, а запросы делаются из ORM.

Очень важно, чтобы GitLab активно использовали, т.к. хочется собрать как можно больше разных запросов.
Интеграция займет 10-15 минут времени вашего админа.

Мне сложно предложить что-то ценное взамен, т.к. сам сервис holistic.dev на данный момент предлагается бесплатно. Но вы пишите, мы что-нибудь придумаем :)

Лайк, шер, предложения в личку @antonrevyako

​Сегодня в нескольких каналах обнаружил постмортемы о предыдущих местах работы :) Один из них от моего старого комрада Олега про 1.5 года работы в AppFollow:

https://news.1rj.ru/str/ITmoonIT/235

Там PostgreSQL 13 зарелизили:

https://www.postgresql.org/about/press/presskit13/ru/


тут я выкладывал документ с подробностями
https://news.1rj.ru/str/nosingularity/483

​elsaland/elsa
Elsa is a minimal, fast and secure runtime for Javanoscript and Typenoscript written in Go.
Language: Go
Stars: 104 Issues: 4 Forks: 6
https://github.com/elsaland/elsa

#devops #monitoring
Чувак заморочился и написал простенький anomaly detection на sql. Будет интересно почитать в образовательных целях, если не очень в ладах даже с школьной статистикой. На проде, я все-таки советую логи и телеметрию в скуль не писать))

​Если вы пришли в офис, но уже прочитали все новости и выпили 3 чашки кофе, а работать по-прежнему не хочется, то вот вам одна древняя забава:


https://github.com/mame/quine-relay

Статический анализ *кродеться*

За время бета-тестирования сервиса в ходе сканироваиня около 12 тысяч репозиториев было выявлено более 20 тысяч проблем с безопасностью, среди которых были и серьёзные проблемы, приводящие к удалённому исполнению кода и подстановке SQL-запросов. 72% из найденных проблем были выявлены на стадии рассмотрения pull-запроса, до его принятия, и исправлены менее чем за 30 дней (для сравнения общая статистика по индустрии показывает, что лишь 30% уязвимостей устраняется менее чем за месяц после обнаружения).

GitHub ввёл в строй сервис для выявления уязвимостей в коде
https://www.opennet.ru/opennews/art.shtml?num=53814

В следующий раз, когда меня спросят почему бы в holistic.dev не начать поддерживать oracle, я буду показывать это:


https://docs.oracle.com/en/database/oracle/oracle-database/20/ftnew/managing-oracle-blockchain-tables-and-data.html

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

Хотя я никогда не понимал прикола обновляемого раз в 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