фп, монады и борщ:

https://habr.com/ru/post/505928/

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

В вебе бесплатно, приложухи за деньги.

https://www.solarsystemscope.com

OpenAI выпустили свой первый коммерческий продукт: The API. Это набор инструментов, для работы с текстом. Там и переводы и написание (новостных) текстов, и все что можно вырастить из их умения с текстом работать - не зря они недавно подняли шумих вокруг GPT3. Кстати, интересно, ждать ли теперь предобученную модель для gpt3 не ясно, может и нет, зачем им конкурировать с собой https://www.bloomberg.com/news/articles/2020-06-11/trillions-of-words-analyzed-openai-sets-loose-ai-language-colossus

​Не все знают, но SQL можно использовать не только для работы с данными в БД.
Есть возможность манипулировать данными из командной строки.
Зачем такое может понадобиться?

1) Парсинг JSON-логов
https://github.com/avz/jl-sql
Можно придумать много хороших usecases. Я писал про эту тулзу в статье про тестирование логов - https://news.1rj.ru/str/nosingularity/198

> cat data.json | jl-sql 'SELECT key, SUM(value) AS sum, COUNT(*) AS count GROUP BY key'

2) Работа с параметрами операционной системы
https://osquery.io/
Совершенно безумная и красивая идея. 257 источников данных!

> osqueryi --json "SELECT * FROM mounts m, disk_encryption d WHERE m.device_alias = d.name AND d.encrypted = 0;"

3) Работа с изображениями
https://github.com/escherize/img_sql/

> ./img_sql.py -i samples/matrix.jpg -o samples/matrix_out.jpg -s 'update pixels set r = g, b = r, g = b where x > 700'

Осталось написать транспайлер в GLSL и будет win :)

4) SQL для MongoDB, DynamoDB, Kafka, S3
Если не хочется работать с монгой, но очень нужно, то можно выкрутиться так
https://rockset.com/solutions/mongodb/

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

5) SQL для запросов по git репозиториям
https://github.com/augmentable-dev/gitqlite (переименовали в askgit)

> -- how many commits have been authored by user@email.com?
> SELECT count(*) FROM commits WHERE author_email = 'user@email.com'

Вот это UX, который делает деньги.

«Очень интересный опыт - я купил новую Теслу не поговорив и не увидевшись ни с одним человеком.
Пока страховая разбиралась с выплатой за прошлую машину, я решил полазить по сайту Теслы и посмотреть что нового. Увидел, что модель 3 теперь можно взять в lease (мне кажется так большинство американцев получают машины - ты ей не владеешь, просто платишь ежемесячные платежи, по сути покрывающие ее износ, и через 2 или 3 года сдаёшь обратно). С лизом трёшка стоила очень привлекательно, поэтому я быстро собрал свою конфигурацию, и нажал check out. С карты списалось $100 за бронь и пришло сообщение, что со мной свяжутся.

На следующий день пришла смс, что машина будет готова всего через 2 дня и мне нужно подписать документы и добавить ее в страховку. Я зашёл на сайт Тесла, залогинился в свой кабинет и электронно подписал там договора и документы на Лиз, скопировал и отправил VIN машины в страховую, откуда мне через пару часов пришёл скан новой страховки, которую я загрузил обратно в сайт Tesla.

Сегодня пришла смс с адресом, где стоит машина, а сама она появилась у меня в приложении. Я приехал, нашёл ее на парковке, отметил на сайте, что принимаю ее и в приложении разблокировались опции ее открыть. Открыл, внутри конверт с документами на регистрацию, в них помечено где подписать, на конверте уже есть штампы и адрес, его осталось только закрыть и бросить в почтовый ящик. В обмен через какое-то время придут по почте номера.

Если бы я был автодилером, я бы уже даже наверное и не напрягался, уже поздно.»

~
https://www.facebook.com/photo.php?fbid=10159753713530410&set=p.10159753713530410&type=3

​Музыкальная пауза.

На глаза стали попадаться средневековые ремиксы популярных песен. Этим занимаются люди с канала Hildegard von Blingin' и там на удивление всего 5 треков.
Например, Radiohead - Creep


Похожий канал с Algal the Bard
Например, Nothing Else Matters

Для фанатов лютневой музыки XVI—XVII веков (хехе) есть еще одна внезапная рекомендация - Patty Gurdy.
Девушка играет на вундервафле, которая называется Hurdy Gurdy или колесная лира. И поет.


У меня практически никогда не получалось слушать музыку и работать одновременно. И т.к. большая часть времени проходит за компом, и нет возможности сесть и, например, осознанно посмотреть Radiohead in Rainbows - From the Basement или вдумчиво послушать Филипа Гласса, на первый план выходит jazz radio и каналы с различными каверами.

Вот несколько каналов и подборок, которые мне заходят даже во время работы:

- металл-каверы от Leo Moracchioli и его Frog Leap Studios
- мэшапы от Pomplamoose
- фанк-каверы от Scary Pockets
- мэшапы и каверы от Elise Trouw (например, Radiohead Meets The Police)
- а капелла от Anne Reburn https://www.youtube.com/channel/UChyNJxSsIXh2KyY3VvLnI2g
- а капелла и битбокс от Pentatonix (например, Bohemian Rhapsody)
- джаз от PostmodernJukebox
- джаз от Sugarpie and The Candymen
- для детей - подборка Jazz Loves Disney

На ютубе есть еще несколько отличных каналов с разными исполнителями, которые записывают живые треки специально для них:
- NPR Music (например, live Sting'а)
- KEXP (например, live Auror'ы)

Все, утренняя почта закончилась, шуруйте работать :)

«Прежде всего, дзен Python говорит, что любое решение должно быть единственное. Поэтому в Python всего минимум по три.»

​​Пока ты учишь хаскель, гуманитарии прикидываются программистами...

«​... Поэтому мы запускаем маркетплейс заказов по No-code, где клиенты могут разместить запрос на разработку проекта, а ноукодеры и агентства откликнуться и получить поток заказов.»

https://news.1rj.ru/str/Ogurzy/496

​Пока космические корабли бороздят (зачеркнуто) postgresql становится быстрее с каждым новым релизом, монга становится медленнее:


https://www.percona.com/blog/2020/06/24/evaluating-mongodb-under-python-tpcc-1000w-workload/

Пора признаться, что мы запустили в режиме раннего тестирования holistic.dev - инструмент для автоматического поиска проблем в SQL-запросах и архитектуре баз данных!

Что это такое?
Holistic.dev - это статический анализатор в виде SaaS. Скорее всего вы уже используете статические анализаторы в классических языках программирования. Но для SQL таких инструментов нет.
Мы нашли способ извлечения знаний о структуре связей между данными во всем вашем проекте на основе схемы базы данных и наборе SQL-запросов. Эти знания позволяют нам автоматически следить за согласованностью существующих связей и предоставлять инструменты для автоматического поиска проблем.


Кому это нужно?
Всем, кто думает о производительности и архитектуре своей базы данных. Обычно, больше всего это заботит DBA :) Но DBA есть не во всех компаниях, и довольно часто вопросами производительности приходится заниматься разработчикам.

Если для работы с базой из приложения вы используете ORM, то, как правило, вы узнаете о всех проблемах, когда все уже стало совсем плохо на продакшене под нагрузкой.
Чтобы узнавать о проблемах заранее, можно автоматически отправлять все запросы, которые попадают в базу на анализ и получать отчеты о возможных проблемах еще до того, как вы с ними столкнётесь.

Если вам повезло и вы пишите на чистом SQL, то, во-первых, вы можете отправлять запросы на анализ не дожидаясь проблем в продакшене еще на этапе разработки и/или в CI, а во-вторых, кроме проблем с производительностью запросов вам так же пригодятся подсказки по улучшению архитектуры базы и упрощению запросов. Это позитивно влияет на скорость онбординга новых сотрудников, повышение общего уровня SQL-разработчков, и уменьшение time-to-market.


Что умеет наш инструмент?
Умеет анализировать схему базы данных и запросы. НЕ ТРЕБУЕТ ПРЯМОГО ПОДКЛЮЧЕНИЯ К БАЗЕ И НЕ ИМЕЕТ ДОСТУПА К ДАННЫМ!
Работает только на исходных текстах запросов, которые пользователь присылает самостоятельно.

Расскажет о том, что можно улучшить в схеме базы данных (DDL) и в каждом из запросов (DML). На данный момент реализовано 70 правил, которые включают, например, рекомендации из Don't Do This. Умеет находить колонки в условиях в WHERE, которые не встречаются в индексах.

Знает какие типы у полей будут в результате выполнения и могут ли там появиться NULL-значения, даже если эти поля являются результатом вычислений или сложных JOIN.
Знает, сколько строк вернет запрос (!!!) :) Нет, конечно не в точных цифрах, а в категориях none, one, one or none, many or none.
Для тех, кто пишет на чистом SQL, это поможет сравнить типы и ожидаемое количество строк в приложении с типами результатов выполнения запросов без тестов, код ревью и дебага :)

На данный момент поддерживается синтаксис Postgresql до 13 версии включительно.
Понимает схемы, таблицы, вьюхи, все core функции и операторы, пользовательские функции и операторы, знает про много разных расширений (extension).

В пару простых операций можно автоматизировать экспорт запросов непосредственно из боевой базы, и получать извещения о найденых проблемах при их появлении.
Это возможно сделать как на on-premise установках, так и в managed базах (AWS RDS, Yandex.Cloud, Digital Ocean и тд). В ближайшее время мы подготовим FaaS для основных cloud-провайдеров.

Чего наш инструмент не умеет?
Т.к. мы не имеем доступ к вашей базе, мы ничего не знаем о ее настройке, не можем выполнить EXPLAIN или помочь с настройкой репликации.
Мы не касаемся ничего, что относится к операционной деятельности. Для анализа метрик базы уже существует много инструментов, и они довольно неплохи.

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


Ближайшие планы
- Больше правил. На данный момент в продакшене 70 правил из 1300+, которые лежат в беклоге.
- Удобный интерфейс просмотра и расширенного поиска истории метрик из pg_stat_statements (если вы настроите автоматическую отправку ваших метрик)
- Автоматическое обновление DDL. Даст возможность автоматически поддерживать состояние схемы базы данных в нашем сервисе в актуальном состоянии.
- Экспорт типов результатов запросов. Можно использовать для генерации кода ваших приложений или для проверки соответствия типов между приложением и запросами в CI
- Список run-time исключений, которые может выбросить запрос. Например, из-за нарушений уникальности индекса или ошибочного приведения типов.
- Экспорт объекта, отражающего состояние схемы базы. Можно использовать для документации или, например, миграциий.
- Больше поддерживаемых расширений (extension)
- доставка уведомлений о найденных проблемах на email/slack


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


Что взамен?
Мы ищем компании для бесплатных пилотных внедрений.
Внедрение автоматической доставки запросов со стороны базы занимает не больше часа. После этого сразу станет возможным просматривать найденные проблемы в личном кабинете.


Как подключиться?
На holistic.dev вы можете попробовать инструмент в playground на заранее подготовленных демо базах или на любых своих запросах.
Зарегистрировавшись, вы получаете возможность создать несколько проектов, загрузить схемы баз и автоматизировать доставку запросов из базы через API.

На все вопросы, предложения и ругань с удовольствием отвечу в телеграме @antonrevyako или с почты info@holistic.dev


Ваш анализатор ничего не нашел!
Да, такое возможно. Вы молодец!
Но это не точно :) На данный момент реализовано 5% от описанных правил, и довольно вероятно, что позже мы что-то сможем обнаружить. Оставайтесь с нами и мы автоматически пришлем отчет, если новые правила все же найдут проблемы в ваших запросах.

Лол, чувак завёл блог, в который постил выдачу нейросети GPT-3. За две недели этот блог набрал 26 тысяч посетителей и почти никто не заметил подвоха. Те же, кто предположил в комментариях, что текст синтетический — были заминусованы другими читателями. Киберпанк, который мы заслужили.
Подробнее тут (на языке вероятного противника)

Спешу дополнить пост про необычные места, в которые догадались засунуть SQL (https://news.1rj.ru/str/nosingularity/493) еще одним пунктом:

5) gitqlite is a tool for running SQL queries on git repositories
https://github.com/augmentable-dev/gitqlite

-- how many commits have been authored by user@email.com?
SELECT count(*) FROM commits WHERE author_email = 'user@email.com'

​Если вы имеете привычку смотреть сериалы, но по какой-то причине еще не видели The Umbrella Academy, то предлагаю потратить эти выходные на сабж.
Особенно прекрасно, что недавно Netflix выложил второй сезон.
А пока до выходных остаются сутки, можно послушать OST из второго сезона
Или OST из первого

https://news.1rj.ru/str/oleg_log/3454

Про отсутствие централизованного репозитория сломано много копий.

Захотелось мне как-то собрать cockroachdb . И я не смог собрать :(

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

Я бы прям подписался на канал с видосами - «собираем известные golang проекты из ветки master»

Сколько времени занимает создание правила для статического анализатора?

В holistic.dev есть 3 группы правил - performance, architect, security.

Часть из этих правил имеют простую природу и срабатывают на основании структуры абстрактного синтаксического дерева.
Подобным образом работают линтеры. Например, eslint для javanoscript.

Такие правила писать легко и быстро и за день можно сделать пяток. Но, писать их скучно :)
Например, правило, рекомендующее избегать конструкций WHERE TRUE или JOIN ON TRUE

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

Сегодня я расскажу вам про правило, на которое я собирался потратить не более 30 минут, но потратил гораздо больше...

Я не очень люблю писать performance-правила. Приходится гонять много тестов в разных окружениях и подбирать ссылки на материалы, которые потом попадут в детальное описание правила. Туда же должны попасть пруфы - запросы, которые вы можете выполнить сами, чтобы убедиться в том, что рекомендация дана по делу.

Есть крайне противоположные мнения относительно рекомендаций по улучшению производительности. Одно - "Анализатор расскажет мне про отсутствующие индексы и я их сразу сделаю". Второе - "Когда начнет тормозить, мы это заметим и поправим. Преждевременная оптимизация — зло!".
Но правда, как обычно, где-то посередине.

Действующие лица: я, функция count, stackoverflow.

Скорее всего вы знаете, что функция count - опасная штука. Она перебирает все поля в таблице (seq scan), чтобы выдать точное количество строк. И это может занимать неприличное время на больших таблицах. Ускорить count можно несколькими способами, которые больше зависят от бизнес-процессов, чем от конкретного запроса.

К слову, сейчас про count описано почти 2 десятка правил и часть из них уже в проде.

Функция count имеет 2 основных применения:
- count(*) или count(любая константа) считает общее количество строк. Кстати, в postgresql count(*) работает быстрее, чем count(1)
- count (колонка или выражение) считает количество значений, отличных от NULL

Но иногда хочется посчитать не просто количество не-NULL значений, а количество уникальных значений.
Для этого можно не задумываясь использовать count(DISTINCT a). Но есть нюанс...
Такой запрос запросто будет МИНИМУМ в 10 раз медленнее.

Оно и понятно. Нужно взять все строки, найти уникальные, и только потом сосчитать их.
Что тут можно сделать? Как минимум, предупредить разработчика о таком неприятном факте, т.к. проблему с запросом он заметит скорее всего не скоро.

А можно ускорить? Вообще-то да. DISTINCT всегда работает медленнее, чем GROUP BY, поэтому, возможны ситуации, где можно сначала сгруппировать данные, а потом посчитать их количество.
Будет как-то так:

SELECT count (*) FROM (SELECT a FROM t GROUP BY a) t1

Даже можно уникальные по нескольким полям считать, не то что с DISTINCT.
Нормально, Григорий! Отлично, Константин!

Так... надо подготовить ссылки и пруфы. Окей, гугл, postgresql select disctinct...

https://stackoverflow.com/questions/11250253/postgresql-countdistinct-very-slow

Ну! А я о чем говорил?! Только тут ребята про GROUP BY не подумали... Ну да ладно, все кейсы в документации распишу. Потом...

Так, пруфы...
Делаем таблицу, заполняем, камера, мотор...

Запрос c count(DISTINCT a) - 243.630 ms
Запрос c count(*) FROM (SELECT) - 509.572 ms

ЭЭЭЭ.... wat?
А с индексом?
247.845 ms / 291.898 ms

Это как? SO не может врать! 317 votes, "holy queries batman! This sped up my PostgreSQL count distinct from 190s to 4.5 whoa!"

... пропустим пару часов экспериментов с разными версиями базы, таблицами с индексами и без ...

​А теперь результаты.

SELECT count(*) FROM (SELECT DISTINCT a ...)

заметно ускоряет запросы, если:
- "a" является строковым полем (VARCHAR/TEXT)
- в качестве параметра count() выступает ROW только из строковых полей -

SELECT COUNT(DISTINCT (a,b))

Если на текстовое поле, по которому делается DISTINCT нет индекса, то

SELECT count(*) FROM (SELECT DISTINCT a ...)

будет МЕДЛЕННЕЕ, чем

SELECT count(DISTINCT a)

, но

SELECT COUNT(*) FROM (SELECT a FROM t GROUP BY a)

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

Если в качестве параметра count() выступает ROW из полей не только строковых типов, то результат также будет аналогичен запросу по текстовому полю без индекса.

Как было озвучено ранее, GROUP BY всегда быстрее DISTINCT. Поэтому, если есть выбор что использовать - используйте GROUP BY.

Для полей других типов (числовые, дата и время) такая "оптимизация" даст отрицательный эффект.

Стоит сгенерировать пруфы для разных типов, collation и прочего, но это все потом...

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


Какие выводы мы можем сделать из этой истории?
- мы знаем намного меньше, чем нам кажется
- когда копируешь что-то с SO - проверяй на своих кейсах
- не все можно сказать только по самому запросу, многое зависит от типов
- используй статический анализ везде, где сможешь
- линтеры тоже используй, но четко осознавай границы применимости

Итак, сколько времени занимает создание правила для статического анализатора?
Одно правило можно писать несколько дней. Может так выйти, что данных, которые выдает наш парсер недостаточно для реализации некоторых правил. Тогда дорабатывается анализатор. Последний раз такая доработка заняла несколько месяцев.

Я как-нибудь вам обязательно расскажу как понять какие индексы PostgreSQL сможет использовать при выполнении запроса. Это очень интересно....

когда человек говорит, что он фулстек

​В посте выше я приводил в пример мнение некоторых менеджеров и разработчиков относительно оптимизации запросов: «Когда начнет тормозить, мы это заметим и поправим. Преждевременная оптимизация — зло!»

Вот история про таких, только уже в виде постмортема :)

https://news.1rj.ru/str/neverendingit/205

2020 набирает обороты.
Все ждали киберпанк 2077 с Киану, а получим... zx spectrum! next! с вайфаем!

Z-80 легендарный процессор. На таких процессорах работал даже коммутатор сотовой компании, в которой я работал 20 лет назад (и где грохнул базу абонентов)

PS: Тот смешной проект по запихиванию андурины в корпус кассеты для загрузки спектрумов уже не выглядит таким смешным...