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

#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

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

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

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

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


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