крайне маловероятно что неудачный merge приведёт к замене килограммов на доллары
Легко, достаточно смело поменять порядок аргументов функции, в другой ветке сделать новый вызов функции, который соответственно не исправлен при смене.
Вот у меня в проекте объём Lua-кода 6,3Мб.
Причём написан многими людьми за пять лет.
Мне очень, очень хочется получить статическую типизацию для него, потому что сейчас каждое изменение кода это шаг в неизвестность. Я пристально гляжу на Haxe (у него есть целевая платформа lua), но пока не уверен, что переход себя оправдает.
Из википедии: Вектор (в генетике) — молекула нуклеиновой кислоты, чаще всего ДНК, используемая в генетической инженерии для передачи генетического материала внутрь клетки, в том числе в клетку живого многоклеточного организма in vivo.
В зависимости от защиты, много можно автоматизировать. Под DOS когда-то была программа autohack, которая для многих таких программ автоматически всё расшифровывала.
Чтобы не тянуть тысячи кабелей, где будет достаточно одного. Например, если датчики разнесены по большой территории, вполне естественно воспользоваться более мощной инфраструктурой, чем либо тянуть напрямую, либо городить локальные узлы агрегации.
А вот унификация промышленных датчиков и офисной сетки никому особо не нужна.
Это унификация сетей АСУТП предприятия, где можно использовать похожее оборудование для связи, контроля и ограничения доступа.
Обычно Ethernet сеть уже развёрнута, настроена и понимается безопасниками. Сейчас в местах стыков с оборудованием ставят переходники/агрегаторы, что дорого и неудобно.
Поэтому добавление ещё одного физического канала оправдано, так как позволяет использовать все существующие решения, которых в ethernet–мире накоплено множество.
Нет, не обязательно. Так же заранее раздаёшь MAC-адреса и посылаешь Ethernet-кадры выбранного формата. Остальные протоколы более верхнего уровня делаются по необходимости. Тот же Modbus можно использовать, даже не в TCP-варианте.
А почему не использовать map у option? В расте, как я вижу, такой метод есть. В функциональных языках обычно результат из option не вытаскивают, пока это возможно, а работают внутри него.
Или and_then.
Я ещё не понял насчёт автономности региональных операторов:
сейчас, например, оператор может спокойно выпустить SIM-карту без согласования с центральным сертификатором, а в eSIM, если я правильно понял, есть обязательный глобальный центр сертификации, который по своему желанию/под действием законов об санкциях, может запретить выдачу eSIM в избранных регионах, например, в том же Крыму.
Это так? Или у региональных операторов здесь руки развязаны?
Мне показалось, что главное преимущество Leo — ациклический граф блоков текста — автор не донёс.
Редактирование в Leo происходит в рамках проекта, где есть каноническое дерево узлов, которое связано с материализованными файлами. А рядышком есть деревья, составленные из этих же узлов, но в другом порядке, и для них нет материализованных файлов, но они предоставляют альтернативный вид на функциональность, путь выполнения или любой другой вариант.
Как редактор текста он ужасен, но возможность создания множества живых видов кода/данных/текста позволяет с этим смириться.
Мой опыт:
Я его использовал для написания проекта переделки самостийно сложившейся архитектуры, от которого требовалось повышенная детализация, так как планировалось полностью сохранить функциональность, но повысить наблюдательность системы и, соответственно, уменьшить количество неисправимых дефектов.
Как Leo мне помог?
Во-первых, с его помощью я смог более-менее подробно установить блоки функциональности и как они живут в системе, как они связаны.
Почему это была проблема: система состояла из разнородных подсистем, а функциональные блоки были рассредоточены в разных её частях.
Т. е. например для конкретного протокола для уровня CLI, который представлял из себя один набор программ, надо было смотреть XML–файлы, в которых описаны команды и их параметры, причём в зависимости от уровня доступа команды были в разных местах. Смотреть куски кода, которые формировали обращения/запись настроек в свою часть логики и конфигурации. А это уже отдельный набор программ. Смотреть, какие команды выдаваются адаптерам и почему.
Поэтому я загрузил в Leo файлы проектов целиком, в полном соответствии с горизонтальным слоением (это, наверное, ярус/tier), которое, в принципе, совпадало с иерархией проектов на диске.
Дальше для каждого функционального блока я создал отдельные иерархические узлы без привязки к результатирующим файлам. И начал их заполнять своими комментариями, ссылками на подблоки текста из соответствующих горизонтальных слоёв.
В Leo есть свои инструменты для выделения текста в подблок с автоматической сборкой, это оказалось очень удобно.
Например, я открывал большой XML–файл, в котором команды сгруппированы по уровню доступа и ожиданиям пользователя. Находил нужный кусок, выделял их в подблоки и вставлял ссылку в дерево функциональности.
После этой детективной работы у меня было множество видов на код:
оригинальное, как оно организовано на диске
по блокам функциональности, где я мог легко охватить взглядом места, где что сделано
по общим связям, где для разделяемых конфигураций и ресурсов было видно, где, кем и как они используются
Во-вторых, Leo помог мне написать документ и не запутаться в деталях.
Здесь я пошёл в обратном направлении, так как уже хорошо представлял какие функциональные блоки нужны и как их организовать.
У меня было дерево, соответствующее нужной структуре документа, которое также больше соответствовало горизонтальному слоению новой архитектуры.
А для функциональных блоков у меня были альтернативные виды на документ, в которых я в основном его и производил.
И здесь Leo реально показал свои преимущества над прочими средствами редактирования:
живые ссылки на блоки давали возможность редактировать текст в любом представлении, с автоматическим обновлением во всех остальных.
возможность добавления блоков–скриптов, которым доступна вся сеть узлов, сняла часть рутины
умение Leo восстанавливать структуру по меткам в файле дало мне возможность не мучаться со встроенным редактором, а редактировать текст извне, моим любимым редактором
Выводы:
Leo — мощное средство организации программирования, но в него надо вкладываться, так как под каждую задачу стоит добавлять автоматизацию действий, обучать людей.
Если команда стабильная, то выигрыш можно получить значительный.
Ещё я не упомянул варианты эфемерных представлений кода: например, исследуется какой-либо дефект, для него создаётся отдельное представление, туда складываются ссылки на встреченные фрагменты выполнения, т. е. реально можно составить аналог стека выполнения через все слои и абстракции с ссылками на данные.
Причём все модификации кода будут живыми: отразятся в материализованных кодах проекта, а также будут под рукой.
Из аналогов очень похожий подход в литературном программировании, но в Leo всё как-то наглядней.
Мне почему-то кажется, что программирование вообще станет лицензированным занятием и код можно будет запустить, только подписав корректным сертификатом программиста/организации.
Легко, достаточно смело поменять порядок аргументов функции, в другой ветке сделать новый вызов функции, который соответственно не исправлен при смене.
Причём написан многими людьми за пять лет.
Мне очень, очень хочется получить статическую типизацию для него, потому что сейчас каждое изменение кода это шаг в неизвестность. Я пристально гляжу на Haxe (у него есть целевая платформа lua), но пока не уверен, что переход себя оправдает.
Вектор (в генетике) — молекула нуклеиновой кислоты, чаще всего ДНК, используемая в генетической инженерии для передачи генетического материала внутрь клетки, в том числе в клетку живого многоклеточного организма in vivo.
Это унификация сетей АСУТП предприятия, где можно использовать похожее оборудование для связи, контроля и ограничения доступа.
Обычно Ethernet сеть уже развёрнута, настроена и понимается безопасниками. Сейчас в местах стыков с оборудованием ставят переходники/агрегаторы, что дорого и неудобно.
Поэтому добавление ещё одного физического канала оправдано, так как позволяет использовать все существующие решения, которых в ethernet–мире накоплено множество.
Или and_then.
сейчас, например, оператор может спокойно выпустить SIM-карту без согласования с центральным сертификатором, а в eSIM, если я правильно понял, есть обязательный глобальный центр сертификации, который по своему желанию/под действием законов об санкциях, может запретить выдачу eSIM в избранных регионах, например, в том же Крыму.
Это так? Или у региональных операторов здесь руки развязаны?
Мне показалось, что главное преимущество Leo — ациклический граф блоков текста — автор не донёс.
Редактирование в Leo происходит в рамках проекта, где есть каноническое дерево узлов, которое связано с материализованными файлами. А рядышком есть деревья, составленные из этих же узлов, но в другом порядке, и для них нет материализованных файлов, но они предоставляют альтернативный вид на функциональность, путь выполнения или любой другой вариант.
Как редактор текста он ужасен, но возможность создания множества живых видов кода/данных/текста позволяет с этим смириться.
Мой опыт:
Я его использовал для написания проекта переделки самостийно сложившейся архитектуры, от которого требовалось повышенная детализация, так как планировалось полностью сохранить функциональность, но повысить наблюдательность системы и, соответственно, уменьшить количество неисправимых дефектов.
Как Leo мне помог?
Во-первых, с его помощью я смог более-менее подробно установить блоки функциональности и как они живут в системе, как они связаны.
Почему это была проблема: система состояла из разнородных подсистем, а функциональные блоки были рассредоточены в разных её частях.
Т. е. например для конкретного протокола для уровня CLI, который представлял из себя один набор программ, надо было смотреть XML–файлы, в которых описаны команды и их параметры, причём в зависимости от уровня доступа команды были в разных местах. Смотреть куски кода, которые формировали обращения/запись настроек в свою часть логики и конфигурации. А это уже отдельный набор программ. Смотреть, какие команды выдаваются адаптерам и почему.
Поэтому я загрузил в Leo файлы проектов целиком, в полном соответствии с горизонтальным слоением (это, наверное, ярус/tier), которое, в принципе, совпадало с иерархией проектов на диске.
Дальше для каждого функционального блока я создал отдельные иерархические узлы без привязки к результатирующим файлам. И начал их заполнять своими комментариями, ссылками на подблоки текста из соответствующих горизонтальных слоёв.
В Leo есть свои инструменты для выделения текста в подблок с автоматической сборкой, это оказалось очень удобно.
Например, я открывал большой XML–файл, в котором команды сгруппированы по уровню доступа и ожиданиям пользователя. Находил нужный кусок, выделял их в подблоки и вставлял ссылку в дерево функциональности.
После этой детективной работы у меня было множество видов на код:
Во-вторых, Leo помог мне написать документ и не запутаться в деталях.
Здесь я пошёл в обратном направлении, так как уже хорошо представлял какие функциональные блоки нужны и как их организовать.
У меня было дерево, соответствующее нужной структуре документа, которое также больше соответствовало горизонтальному слоению новой архитектуры.
А для функциональных блоков у меня были альтернативные виды на документ, в которых я в основном его и производил.
И здесь Leo реально показал свои преимущества над прочими средствами редактирования:
Выводы:
Leo — мощное средство организации программирования, но в него надо вкладываться, так как под каждую задачу стоит добавлять автоматизацию действий, обучать людей.
Если команда стабильная, то выигрыш можно получить значительный.
Ещё я не упомянул варианты эфемерных представлений кода: например, исследуется какой-либо дефект, для него создаётся отдельное представление, туда складываются ссылки на встреченные фрагменты выполнения, т. е. реально можно составить аналог стека выполнения через все слои и абстракции с ссылками на данные.
Причём все модификации кода будут живыми: отразятся в материализованных кодах проекта, а также будут под рукой.
Из аналогов очень похожий подход в литературном программировании, но в Leo всё как-то наглядней.