There will be no singularity
前往频道在 Telegram
1 959
订阅者
+124 小时
+27 天
+130 天
帖子存档
Не секрет, что лучшие вакансии в айти расходятся задолго до попадания на hh и linkedin. Одно из мест где можно ловить такие варианты это канал Профунктора: NVIDIA, Revolut, Bolt, Мосбиржа и другие лучшие карьерные варианты для разработчиков появляются там регулярно. Стоит подписаться, чтобы быть в курсе того сколько нынче платят «по рынку», и не гнуть спину за полцены из-за того что неудачно прособеседовался год назад.
@profunctor_jobs
Ребята из @profunctor_io большие молодцы и я всегда готов поддержать их призывы рассказать про профунктор-джоб, поэтому вот:
В этом довольно специфичном тесте PostgreSQL выносит MSSQL и MySQL вперед ногами:
https://www.mssqltips.com/sqlservertip/6607/delete-sql-performance-for-sql-server-mysql-and-postgresql/
Все выпуски SQL-TIL:
1) https://t.me/nosingularity/535
2) https://t.me/nosingularity/541
3) https://t.me/nosingularity/548
4) https://t.me/nosingularity/572
5) (snowflake) https://t.me/nosingularity/582
Пятничный SQL-WTF
Понедельничный SQL-TIL
Пару недель я занимаюсь описанием грамматики SQL-синтексиса базы snowflake. Это такая cloud-only база, которую пилят 8 лет, 1500 человек сотрудников, вышли месяц назад на IPO с оценкой $70B...
Как-то давно в твитерах молодежь жаловалась на непонятную документацию постгреса:
https://t.me/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_POLICY3) Определения повторяются. Описание параметров 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. Такая убогая и тормозная админка ставит их на одну ступень со всеми серьезными игроками - гугл и амазон :) И это не считая того, что там визуально не обозначено и половины тех функций, которые описаны в документации.
А пока идет перепись тех, у кого есть бесплатная столовка в офисе и тех, кому приходится наливать воду в куллере, аки холопам, вот еще один наброс в тему канала:
чуваки заморочились и посчитали сколько ресурсов тратит одна и та же программа, написанная на разных языках.
Бенчмарк (как и все бенчмарки) барахло (и переписывать все на сях я не буду), но в конце списка оказались именно те, кого мы там ждали: руби и питон :)
https://thenewstack.io/which-programming-languages-use-the-least-electricity/
Теперь мы знаем, кто виноват в глобальном потеплении...
Вроде бы и смешно, но я знаю несколько человек, которые тянут язычок у куллера на себя. У всех офисных куллеров, что я видел, язычок в таком положении фиксируется и можно не держать чашку в ожидании наполнения.
https://twitter.com/towernter/status/1317479702349647873
На заметку всем, кто рекомендует мне выложить все в опенсорс:
https://twitter.com/tim_nolet/status/1317061818574082050
каждый раз видя такие графики вспоминаю историю как рубисты положили постгрес, который крутился на 70 cpu...
https://www.2ndquadrant.com/en/blog/oltp-performance-since-postgresql-8-3/
Наверное, все уже слышали, как в одном европейском королевстве пролюбили статистику по ковиду из-за того, что в екселе, куда они все записывали, закончились колонки.
Отдельных ответов заслуживают вопросы: как можно было этого не заметить и какой мудак решил использовать для этой цели колонки вместо строк.
Вывода тут можно сделать два:
- не связывайтесь в .gov, у них все через жопу. В любой стране.
- не используйте в качестве систем управления базами данных те инструменты, которые таковыми не являются (привет любителям sqlite)
Больше дедов богу дедов!
Мой старый друг запилил канал про фронтенд и будет в лучших традициях старых Перунов (зачеркнуто) пердунов ныть о том, что «нынче не то, что давича» и что «я-то в советские времена ооо!».
Может даже узнаете что-то полезное :)
https://t.me/angry_front_end
Пятничный 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://t.me/nosingularity/535 https://t.me/nosingularity/541 https://t.me/nosingularity/548
#AR
На видео происходит инверсия записанного трехмерного и временного пространства, при помощи AR.
Все уже посмотрели Довод?
https://twitter.com/thorikawa/status/1309066544924766210?s=20
现已上线!2025 年 Telegram 研究 — 年度关键洞察 
