Я, прочитав о RON по ссылке, понял так, что это некоторая платформа, язык для использования CRDT, то есть он предоставляет, кроме прочего, некоторые средства обеспечения бесконфликтности. Прошу прощения за вопрос, кажется, мне следует больше почитать о нём.
В отличие от git, CRDT структуры данных всегда можно помержить автоматически. В остальном же, git — очень хороший пример для объяснения свойств CRDT хранилищ
Насколько я понял, CRDT — это тип-полурешетка. Если рассматривать предмет версионирования, рабочую директорию, то она относительно мержа не является полурешеткой из-за конфликтов слияния. Можно ли рассматривать сам репозиторий (только не git, а какой-нибудь патчевой СКВ, где конфликтное состояние является возможным состоянием) как CRDT относительно операции pull/push?
Что можно почитать насчёт того, как избегается проблема конфликтов в RON?
всё-таки вариант ничего не делать имхо хуже.
Впрочем, прошу уточнить, какие есть варианты действий отдельного не слишком богатого пользователя, чтобы продукт не умер?
Мне очень нравится идея использовать пароль, функционально зависящий от открытых статичных параметров сервиса (домен, например) и скрытых параметров. Функция составляется и запоминается единожды и не меняется во времени. О скрытых параметрах скажу ниже. Сам таким пользуюсь в половине случаев.
Из преимуществ:
— легко «вспомнить» пароль к сервису, о существовании которого ты давно забыл
— независимость от сторонних сервисов, программ, баз данных
При этом можно функцию выбрать достаточно нетривиальную, чтоб визуально не была видна шаблонность паролей (как в предложенной в статье схеме), даже если злоумышленник узнает несколько паролей от нескольких сервисов, но при этом достаточно лёгкую в практическом использовании.
Из недостатков:
— разные сервисы выставляют разные ограничения на вид пароля, иногда эти ограничения взаимно исключают друг друга. Например, один сервис требует, чтобы в пароле была хотя бы одна цифра и непечатный небуквенный знак, другой требует, чтобы пароль состоял только из букв латинского алфавита, третий — только из цифр, четвёртый — максимум 8 символов, пятый — минимум 6. Поэтому предложенная в статье схема не универсальна. Единственное решение — скрытые параметры. Например, добавляем некоторое число внутрь пароля, когда условия на пароль допускают наличие цифр, и не добавляем в противном случае. Очевидная проблема — нужно запоминать скрытые параметры. Скрытые параметры — зло, потому что их легко забыть и трудно подобрать, если это что-то сложнее одного-двух булевых флага.
— иногда сервисы или соображения безопасности требуют поменять пароль. Тогда номер пароля или дата смены выступает в качестве скрытого параметра, что тоже очень неудобно. Впрочем, из соображений безопасности лучше использовать специализированное ПО.
— иногда сервисы меняют название, домен или другие параметры, которые считались статичными при создании пароля. Тогда надо вспомнить старые значения этих параметров и, по возможности, поменять пароль. Неудобно.
Нет, yaml разрабатывался как надмножество json, то есть любой корректный json является корректным yaml. но не наоборот.
YAML can therefore be viewed as a natural superset of JSON, offering improved human readability and a more complete information model. This is also the case in practice; every JSON file is also a valid YAML file. This makes it easy to migrate from JSON to YAML if/when the additional features are required.
Хотя, в документации к yaml написано, что это не совсем так. Например,
JSON's RFC4627 requires that mappings keys merely “SHOULD” be unique, while YAML insists they “MUST” be. Technically, YAML therefore complies with the JSON spec, choosing to treat duplicates as an error.
Поэтому исходный вопрос не лишен смысла. Для ответа на него нужно посмотреть, как отреагирует docker-compose, если ему подсунуть
который корректный как JSON и некорректный как YAML.
Спойлер
Запустит node:11-alpine. Даже если переименовать docker-compose.json в docker-compose.yaml.
Видимо, авторам было не лень проверять, что отступы блоковых элементов должны обязательно быть пробелами, а не табуляцией, а на уникальность ключей, которая точно так же требуется форматом, все забили.
добавлю. Это не так. Только если Вы не сохраните целевой докер-образ в репозитории и будете его хранить 2 года. Спустя 2 года собрать докер образ из исходного Dockerfile по вполне понятным причинам будет невозможно
Вы совершенно правы. Это важный момент, который следует упомянуть в разделе «цена». Иначе воспроизводимость превратиться в тыкву.
Подробных исследований про трудозатраты на внедрение/обучение/…, думаю, ещё просто не существует.
Это звучит странно. Описание любой технологии должно включать в себя описание решаемой проблемы и границу применимости (как принципиальную для данной технологии, так и относительно текущей среды). Иначе как компании определить, что ей нужны услуги условной Weaveworks?
какие задачи вы вообще хотите решить?
Это и есть мой вопрос. Какие задачи технология предлагает решить и какая цена предлагаемого решения?
Давайте в качестве примера возьмём pet-проекты.
Если есть хотя бы маленькая вероятность того, что код надо будет откатывать к предыдущему состоянию, или параллельно рассматривать несколько независимо разрабатываемых версий, или что будет несколько разработчиков, то надо использовать систему контроля версий. Цена — 10ч на обучение (разово), труд на составление коммитов и отведённая память под репозиторий.
Если нужно через 2+ лет восстановить точное окружение, в котором собиралась и исполнялась программа, то имеет смысл использовать докер. Цена (по крайней мере, в прошлом) — привязка к Linux, 10ч на базовое обучение (разово) и 1ч на составление Docker-файла (разово на проект), труд по управлению контейнерами и незначительные накладные расходы на запуск контейнера.
Можете продолжить в так же для k8s и gitops?
Что можно почитать полному новичку о GitOps и аналогах и ныне существующих технологиях, чтоб оценить трудозатраты на внедрение, построение процессов, включая обучение, и накладные расходы, и сопоставить их с потенциальной выгодой от внедрения?
Грубо говоря, если я решил начать писать пет-проект транслятора своего ЯП, нужен ли мне GitOps, Kubernetes и иже с ними?
Или если моя группа занимается числодробилкой на условном Фортране путём переписывания 20-летних сырцов под новую установку/модель?
Если вы упадете в черную дыру, оставшуюся после гибели звезды, вас разорвет на куски.
Меня всегда интересовал вопрос: если я обрету нестареющее тело и гипнотическое подчинение всех разумных тварей себе, через сколько лет (оценкой снизу) я смогу совершить самоубийство, спрыгнув в ЧД?
Идея в докладе предлагается интересная: разветвиться по поддерживаемым версиям, на каждую завести свой мастер.
Кажется, предлагается методология по работе с гитом (+ инструменты кросс-валидации git и jira), которая частично покроет проблемы, связанные с неумением гита в спонтанное ветвление.
Я не понимаю, почему master-first подход возможен на практике. При черри-пике любое изменение может (а по моему опыту — почти всегда) перенестись из ветку в ветку, полностью изменив смысл своих изменений в контексте другой версии кода. В лучшем случае код станет просто синтаксически некорректным, в худшем — появится трудноуловимая бага, специфичная именно для этой версии и, быть может, более ранних. Тогда, кмк, после каждого черри-пика надо проводить стабилизацию каждой ветки.
Например, при переходе между версиями 1.3 и 1.4 вместо одной зависимой библиотеки была использована другая (или другая версия этой же библиотеки) с похожим функционалом и похожим API. Фикс баги в мастере состоял в том, что некоторая библиотечная функция стала вызываться с другими аргументами/параметрами. При черри-пике мы можем получить
синтаксическую ошибку, если новая сигнатура функции не поддерживает новые параметры
рантайм-ошибку, если новые параметры функции не поддерживаются
баг, если новые параметры интерпретируются по-другому
багфикс, если повезло
Другой пример: при переходе между мажорными или минорными версиями меняется механизм или алгоритм работы с памятью/файлами/сетью/железом/данными/конфигами (или сам язык конфигов или DSL меняется). Черри-пик багфикса не обязан быть багфиксом в более ранней версии.
Вот, что говорит докладчик:
Я согласен. Но здесь мы решаем проблему 99 % случаев. И 1 %, когда мы дропнули performance каким-то bugfix’ом в 2 раза и нашли это во время тестирования, а bugfix уже везде промержен, то мы в ручном режиме примем какое-то решение. Может быть, мы сделаем откат, но, скорее всего, мы очень быстро будем фиксить это по всем веткам.
Фактически, он говорит, что багфиксы к черри-пикнутым багфиксам будут писаться вручную, но рассматривается это как внештатная ситуация. Не понимаю, как им удаётся избегать багов, созданных неправильным переносом багфиксов.
git позволяет версионировать pdf как бинарь. Этого достаточно, чтобы выявлять факт внесённых изменений хотя бы в одном месте. Если регламенты разбиты на несколько pdf, ситуация для пользователя упрощается.
Более того, если вам не нужно менять регламенты несколькими сотрудниками одновременно или поддерживать несколько версий регламентов одновременно, изменяющихся то зависимо, то независимо друг от друга, то распределённый git вам не нужен, достаточно svn или чего-то аналогичного.
Уточните, какие задачи по Вашему мнению должен решать статический анализ?
Кроме синтаксического анализа, проверки типов и проверки ограничений, вроде того, что импортируемые модули существуют, а переменные в окружении определены.
можно использовать какой-то CSS-in-JS, например styled components, <...>, что сразу избавляет от пропасти в статическом анализе и каких либо мега инструментов для удаления мертвого CSS
Можно поподробнее?
Почему переход от Тьюринг-неполного CSS к Тьюринг-полному JS избавляет от пропасти в статическом анализе?
Для тех, кто не в теме, что это за возможность такая? Как рассахариваются несколькострочные конструкции, если функция не удовлетворяет естественным квадратам? Или там единственное отличие состоит в отсутствии требования к наличию fmap?
Спасибо, логично.
Что можно почитать насчёт того, как избегается проблема конфликтов в RON?
Впрочем, прошу уточнить, какие есть варианты действий отдельного не слишком богатого пользователя, чтобы продукт не умер?
Из преимуществ:
— легко «вспомнить» пароль к сервису, о существовании которого ты давно забыл
— независимость от сторонних сервисов, программ, баз данных
При этом можно функцию выбрать достаточно нетривиальную, чтоб визуально не была видна шаблонность паролей (как в предложенной в статье схеме), даже если злоумышленник узнает несколько паролей от нескольких сервисов, но при этом достаточно лёгкую в практическом использовании.
Из недостатков:
— разные сервисы выставляют разные ограничения на вид пароля, иногда эти ограничения взаимно исключают друг друга. Например, один сервис требует, чтобы в пароле была хотя бы одна цифра и
непечатныйнебуквенный знак, другой требует, чтобы пароль состоял только из букв латинского алфавита, третий — только из цифр, четвёртый — максимум 8 символов, пятый — минимум 6. Поэтому предложенная в статье схема не универсальна. Единственное решение — скрытые параметры. Например, добавляем некоторое число внутрь пароля, когда условия на пароль допускают наличие цифр, и не добавляем в противном случае. Очевидная проблема — нужно запоминать скрытые параметры. Скрытые параметры — зло, потому что их легко забыть и трудно подобрать, если это что-то сложнее одного-двух булевых флага.— иногда сервисы или соображения безопасности требуют поменять пароль. Тогда номер пароля или дата смены выступает в качестве скрытого параметра, что тоже очень неудобно. Впрочем, из соображений безопасности лучше использовать специализированное ПО.
— иногда сервисы меняют название, домен или другие параметры, которые считались статичными при создании пароля. Тогда надо вспомнить старые значения этих параметров и, по возможности, поменять пароль. Неудобно.
Хотя, в документации к yaml написано, что это не совсем так. Например,
Поэтому исходный вопрос не лишен смысла. Для ответа на него нужно посмотреть, как отреагирует docker-compose, если ему подсунуть
который корректный как JSON и некорректный как YAML.
Видимо, авторам было не лень проверять, что отступы блоковых элементов должны обязательно быть пробелами, а не табуляцией, а на уникальность ключей, которая точно так же требуется форматом, все забили.
Это и есть мой вопрос. Какие задачи технология предлагает решить и какая цена предлагаемого решения?
Давайте в качестве примера возьмём pet-проекты.
Если есть хотя бы маленькая вероятность того, что код надо будет откатывать к предыдущему состоянию, или параллельно рассматривать несколько независимо разрабатываемых версий, или что будет несколько разработчиков, то надо использовать систему контроля версий. Цена — 10ч на обучение (разово), труд на составление коммитов и отведённая память под репозиторий.
Если нужно через 2+ лет восстановить точное окружение, в котором собиралась и исполнялась программа, то имеет смысл использовать докер. Цена (по крайней мере, в прошлом) — привязка к Linux, 10ч на базовое обучение (разово) и 1ч на составление Docker-файла (разово на проект), труд по управлению контейнерами и незначительные накладные расходы на запуск контейнера.
Можете продолжить в так же для k8s и gitops?
Грубо говоря, если я решил начать писать пет-проект транслятора своего ЯП, нужен ли мне GitOps, Kubernetes и иже с ними?
Или если моя группа занимается числодробилкой на условном Фортране путём переписывания 20-летних сырцов под новую установку/модель?
Идея в докладе предлагается интересная: разветвиться по поддерживаемым версиям, на каждую завести свой мастер.
Кажется, предлагается методология по работе с гитом (+ инструменты кросс-валидации git и jira), которая частично покроет проблемы, связанные с неумением гита в спонтанное ветвление.
Я не понимаю, почему master-first подход возможен на практике. При черри-пике любое изменение может (а по моему опыту — почти всегда) перенестись из ветку в ветку, полностью изменив смысл своих изменений в контексте другой версии кода. В лучшем случае код станет просто синтаксически некорректным, в худшем — появится трудноуловимая бага, специфичная именно для этой версии и, быть может, более ранних. Тогда, кмк, после каждого черри-пика надо проводить стабилизацию каждой ветки.
Например, при переходе между версиями 1.3 и 1.4 вместо одной зависимой библиотеки была использована другая (или другая версия этой же библиотеки) с похожим функционалом и похожим API. Фикс баги в мастере состоял в том, что некоторая библиотечная функция стала вызываться с другими аргументами/параметрами. При черри-пике мы можем получить
Другой пример: при переходе между мажорными или минорными версиями меняется механизм или алгоритм работы с памятью/файлами/сетью/железом/данными/конфигами (или сам язык конфигов или DSL меняется). Черри-пик багфикса не обязан быть багфиксом в более ранней версии.
Вот, что говорит докладчик:
Фактически, он говорит, что багфиксы к черри-пикнутым багфиксам будут писаться вручную, но рассматривается это как внештатная ситуация. Не понимаю, как им удаётся избегать багов, созданных неправильным переносом багфиксов.
Более того, если вам не нужно менять регламенты несколькими сотрудниками одновременно или поддерживать несколько версий регламентов одновременно, изменяющихся то зависимо, то независимо друг от друга, то распределённый git вам не нужен, достаточно svn или чего-то аналогичного.
В общем, грустно это.
Кроме синтаксического анализа, проверки типов и проверки ограничений, вроде того, что импортируемые модули существуют, а переменные в окружении определены.
Почему переход от Тьюринг-неполного CSS к Тьюринг-полному JS избавляет от пропасти в статическом анализе?