Ценность терраформа в том, что он сделал IaC мейнстримом. Но в конце 23 года утверждать, будто он лучше конкурентов - странно. Доказательством тому служит то, что в чистом виде сам терраформ теперь используется редко, гораздо чаще с генераторами вроде terragrunt или terraspace.
Поэтому сейчас лучше посмотреть в сторону того же Pulumi, который позволяет писать код на полноценных императивных языках, с настоящими условиями и циклами, с полноценной модульностью и типизацией, если нужно.
Некоторые из них выполнены на устаревшем стеке — к ним относятся Олимпиады. В этом продукте мы перешли с единого бэкенда с фронтендом — ruby и slim — на раздельный бэк— ruby — и фронт — next.js.
Что вы подразумеваете под словом "устаревшем"? И рельсы, и slim живы-здоровы, постоянно обновляются. Есть разные причины перейти на указанный стек: желание поменять архитектуру с монолита на API+SPA, или упрощение найма (рынок JS гораздо больше рынка Ruby), но где тут устаревание?
алгоритм подписи проприетарный и зависит от версии rails
Проприетарный? В опенсурс? Это как?
Из-за этого приходится делать дополнительные запросы на проверку состояния сессии и ее дешифровки при каждом обращении к серверу, даже если это статика с интерфейс-приложением.
Что может быть секретного в статике с интерфейс-приложением, что для её отдачи нужно авторизовать пользователя? Вы же не хардкодите никаких чувствительных данных в своём SPA, правда?
Технические навыки выучить легко. В разных проектах вы будете осваивать разные языки программирования. Вы можете изучить их синтаксис, сильные и слабые стороны. Это лишь вопрос практики.
В последнее время это много где повторяют, будто мантру. Однако вот в чём дело: я видел студентов, из которых получаются хорошие программисты. Видел тестировщиков, из которых получаются хорошие программисты. Видел программистов, из которых получаются хорошие менеджеры. Но никогда не видел менеджера, из которого получился бы хороший программист.
Возможно, харды - это не так просто, а софты - это не так важно?
Разделение суток на часы вошло в употребление со времени появления в Риме солнечных часов (лат. horologium solarium) в 291 году до н. э.; в 164 году до н. э. в Риме ввели водяные часы (лат. solarium ex aqua). День, как и ночь, был разделён на 12 часов. В разное время года продолжительность одного часа дня и одного часа ночи менялась. День — это время от восхода до захода солнца, ночь — от захода до восхода солнца. В равноденствие день считался с 6 часов утра до 6 часов вечера, ночь — с 6 часов вечера до 6 часов утра.
enum? С какой стати? enum - это тип данных, допускающий установку одного из нескольких предопределённых значений. Например, [active, inactive]. Или [cart, address, deliver, payment]. Или [monday, tuesday, ..., sunday]. А записей в таблице может быть столько, сколько поддерживает СУБД. И у вас будут сотни миллионов active и миллиарды inactive. Ничто тут ничего уникально не идентифицирует.
Не улавливаю связи. Речь шла об использовании уникальных значений. Автору не нравятся строки, он предлагает использовать инты. Также, с разной эффективностью, можно было бы использовать float, decimal, uuid, да хоть битовые маски. То, что инты также могут использоваться в качестве первичных ключей - просто совпадение.
Следите за контекстом. Тред начался с формулировки
Например для колонки Пол (мужской, женский, не выбран).
И указанный код опубликован в этом треде. В этом контексте нет "другого", а в этом коде не указано, что поле с этим енамом может быть NULL. Из чего очевидный вывод: в этом коде other используется ВМЕСТО NULL.
Только тред начался с колонки "пол". Не социальный "гендер". Не грамматический "род". Обычный биологический "пол". Их у человеков всего два. И NULL для "неизвестно".
Есть списки неизменные, например, биологический пол: есть всего два варианта. А если изменяющиеся, например, гендер. И enum'ы, конечно, нужно использовать только для неизменных.
Vim использует одни и те же клавиши для управления и (очевидно) для ввода текста. Значит, между этими режимами нужно как минимум переключаться. Я вот пока набирал это сообщение, много раз попадал не туда пальцем, пользовался стрелками, удалял и вводил заново. Это же сколько раз нужно было бы переключаться туда-сюда... а если учесть что я и в командном режиме мог много раз опечатываться, то в итоге я вообще бы ничего не ввел. Стрелки прекрасны тем что они стоят отдельно, по ним очень сложно промазать, в отличие от буквенных клавиш.
Ваша ключевая ошибка в слове "нужно", из этого и неверные выводы. Не "нужно", а "можно". Вы можете перейти в режим ввода один раз и пользоваться только им, со стрелками и delete/backspace'ами. Даже ctrl-c/ctrl-v для этого режима можно настроить.
А разделение режимов в виме нужно для удобства. Он даёт больше, чем просто ввод. То есть им необязательно пользоваться, но если начать, то втягиваешься.
целочисленный PK не стоит использовать для сортировки
Сортировка по первичному ключу - занятие бессмысленное, абсолютно согласен, но какое это имеет отношение к обсуждаемым enum'ам?
Даже если отставить PK в сторону, то дело не в сортировке. В предложенном варианте с последовательными интами в базе невозможно добавить новое значение в середину списка, ибо оно должно будет переиспользовать существующий индекс, а значит, нужна миграция, которая сдвинет все индексы ниже. Это бесполезная, никому не нужная работа.
В реальном мире проблемы сквозной нумерации могут решаться увеличением порядка, пример: аудитории в учебных заведениях, типа 1xx на первом этаже, 2xx на втором и т.д. Т.е. сознательное создание дырок. Здесь можно применить тот же подход, но зачем, если можно просто не использовать инты?
Может возникнуть "для чего вставлять новое значение именно в середину". Ответ: потому что это требуется для решения задачи.
Конечно, не надо. Я бы и сам использовал енам. Но мой комментарий был не о поле, а о значении "не выбрано". Которое как раз и означает отсутствие значение, т.е. то, для чего в соседнем треде сделан костыль:
-- before
gender ENUM('man', 'woman')
-- after
gender ENUM('man', 'woman', 'other')
Вот этот other избыточен, если мы следуем формулировке "мужской/женский/не выбран". Причём "не выбран" - это вовсе не то же самое, что "предпочитаю не говорить" или "другой", ибо первое - это отсутствие значения, а второе - сознательный выбор пользователя.
Статья называется "Почему тип поля enum на уровне базы — зло", а на самом деле она о "Почему тип поля enum на уровне базы (*в Mysql* при использовании *PHP*) — зло"
Таким образом, тип полей enum в базе - это лютое зло.
Это инструмент. Как и любым инструментом, им нужно уметь пользоваться.
Также можно ответить на вопрос "почему integer, а не string": дело в том, что поля типа string подвержены грамматическим ошибкам и всё что они дают - лишь удобство чтения таких данных в одной конкретной таблице без использования SQL запросов. Но если в слове будет допущена ошибка или
Вообще непонятно. Как можно читать данные в таблице *без использования SQL запросов*? SELECT - это не SQL?
слово нужно будет заменить на другое - придётся отправлять запрос в базу, чего не нужно делать при использовании целочисленных значений.
Ценность терраформа в том, что он сделал IaC мейнстримом. Но в конце 23 года утверждать, будто он лучше конкурентов - странно. Доказательством тому служит то, что в чистом виде сам терраформ теперь используется редко, гораздо чаще с генераторами вроде terragrunt или terraspace.
Поэтому сейчас лучше посмотреть в сторону того же Pulumi, который позволяет писать код на полноценных императивных языках, с настоящими условиями и циклами, с полноценной модульностью и типизацией, если нужно.
Что вы подразумеваете под словом "устаревшем"? И рельсы, и slim живы-здоровы, постоянно обновляются. Есть разные причины перейти на указанный стек: желание поменять архитектуру с монолита на API+SPA, или упрощение найма (рынок JS гораздо больше рынка Ruby), но где тут устаревание?
Проприетарный? В опенсурс? Это как?
Что может быть секретного в статике с интерфейс-приложением, что для её отдачи нужно авторизовать пользователя? Вы же не хардкодите никаких чувствительных данных в своём SPA, правда?
В последнее время это много где повторяют, будто мантру. Однако вот в чём дело: я видел студентов, из которых получаются хорошие программисты. Видел тестировщиков, из которых получаются хорошие программисты. Видел программистов, из которых получаются хорошие менеджеры. Но никогда не видел менеджера, из которого получился бы хороший программист.
Возможно, харды - это не так просто, а софты - это не так важно?
Идея гораздо древнее японцев:
enum? С какой стати? enum - это тип данных, допускающий установку одного из нескольких предопределённых значений. Например, [active, inactive]. Или [cart, address, deliver, payment]. Или [monday, tuesday, ..., sunday]. А записей в таблице может быть столько, сколько поддерживает СУБД. И у вас будут сотни миллионов active и миллиарды inactive. Ничто тут ничего уникально не идентифицирует.
Не улавливаю связи. Речь шла об использовании уникальных значений. Автору не нравятся строки, он предлагает использовать инты. Также, с разной эффективностью, можно было бы использовать float, decimal, uuid, да хоть битовые маски. То, что инты также могут использоваться в качестве первичных ключей - просто совпадение.
Это очень хороший вопрос, но лучше задать его автору. Лично я догадался по обратным кавычкам в примерах запросов.
Следите за контекстом. Тред начался с формулировки
И указанный код опубликован в этом треде. В этом контексте нет "другого", а в этом коде не указано, что поле с этим енамом может быть NULL. Из чего очевидный вывод: в этом коде other используется ВМЕСТО NULL.
Используете postgres, а у автора mysql.
Только тред начался с колонки "пол". Не социальный "гендер". Не грамматический "род". Обычный биологический "пол". Их у человеков всего два. И NULL для "неизвестно".
Трудно представить ситуацию, в которой у вас найдётся 800 неизменяемых списков.
Да, в atlassian тоже так думают. А потом смотришь на список таблиц jira, а там
Но откуда вообще взялся PK? О нём в посте речи не шло.
Есть списки неизменные, например, биологический пол: есть всего два варианта. А если изменяющиеся, например, гендер. И enum'ы, конечно, нужно использовать только для неизменных.
Ваша ключевая ошибка в слове "нужно", из этого и неверные выводы. Не "нужно", а "можно". Вы можете перейти в режим ввода один раз и пользоваться только им, со стрелками и delete/backspace'ами. Даже ctrl-c/ctrl-v для этого режима можно настроить.
А разделение режимов в виме нужно для удобства. Он даёт больше, чем просто ввод. То есть им необязательно пользоваться, но если начать, то втягиваешься.
Сортировка по первичному ключу - занятие бессмысленное, абсолютно согласен, но какое это имеет отношение к обсуждаемым enum'ам?
Даже если отставить PK в сторону, то дело не в сортировке. В предложенном варианте с последовательными интами в базе невозможно добавить новое значение в середину списка, ибо оно должно будет переиспользовать существующий индекс, а значит, нужна миграция, которая сдвинет все индексы ниже. Это бесполезная, никому не нужная работа.
В реальном мире проблемы сквозной нумерации могут решаться увеличением порядка, пример: аудитории в учебных заведениях, типа 1xx на первом этаже, 2xx на втором и т.д. Т.е. сознательное создание дырок. Здесь можно применить тот же подход, но зачем, если можно просто не использовать инты?
Может возникнуть "для чего вставлять новое значение именно в середину". Ответ: потому что это требуется для решения задачи.
Конечно, не надо. Я бы и сам использовал енам. Но мой комментарий был не о поле, а о значении "не выбрано". Которое как раз и означает отсутствие значение, т.е. то, для чего в соседнем треде сделан костыль:
Вот этот
otherизбыточен, если мы следуем формулировке "мужской/женский/не выбран". Причём "не выбран" - это вовсе не то же самое, что "предпочитаю не говорить" или "другой", ибо первое - это отсутствие значения, а второе - сознательный выбор пользователя.Статья называется "Почему тип поля enum на уровне базы — зло", а на самом деле она о "Почему тип поля enum на уровне базы (*в Mysql* при использовании *PHP*) — зло"
Это инструмент. Как и любым инструментом, им нужно уметь пользоваться.
Вообще непонятно. Как можно читать данные в таблице *без использования SQL запросов*? SELECT - это не SQL?
Удачи в изменении порядка значений.
true, false, NULL. Или false, true, NULL, кому как больше нравится.
awk - это не текстовый редактор. `man gawk` говорит нам, что это `pattern scanning and processing language`.
А текстовый редактор - это vim или emacs (или даже vim+emacs, как в doom emacs). И их пользователи редактируют через них очень часто.