​Сегодня в нескольких каналах обнаружил постмортемы о предыдущих местах работы :) Один из них от моего старого комрада Олега про 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/

​Штош....

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


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

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


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

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

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

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

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

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