А что, разрабатываемая система потом будет существовать в вакууме? Вот в примерах в статье у нас по два пользователя - конечный пользователь и пользователь-администратор. Когда пытаешься понять, как именно различные пользователи (особенно когда их > 3 категорий) будут участвовать в общем процессе, удобнее описывать это BPMN. Как отметил комментатор ниже, в виде Sequence Diagram такая схема будет нечитаема.
Вообще, странен переход от C4 к Sequence, т.к. последний вид диаграмм описывает процессы, (причём требует очень точного описания, иначе читать невозможно) тогда как C4, судя по его описанию, описывает систему в виде статичных её классов - просто в разном уровне детализации. Например, допустимую последовательность деплоя сервисов (контейнеров) из неё не почерпнуть.
Тогда как Sequence Diagram - это "микроописание" деталей поведения кусков системы. И в случае большого количества акторов, BPMN будет намного понятнее - это будет своего рода Sequence Diagram, "вид сверху" (лишённый, разумеется, визуализации хронологической одновременности параллельных процессов).
Правильно ли я понял, что итог двух лет - это собранная команда по поддержке и доработке запущенного проекта (которая дальше будет жить без участия автора)?
Т.е., в частности, - грейды нужны уже на этап после запуска?
По "текущему раскладу" - я так понял, что грейдапы в созданной команде приветствуются. А есть ли ограничения (в пределах какого-то общего бюджета проекта, по установленным заранее квотам, по готовности заказчика)? Могут ли потенциально при такой схеме получиться оверквалы? Если да, что с ними предполагается делать?
Главное, что бы физически блины не деградировали. Если не проткнули корпус чем-то острым, не сломали пополам, не выбросили рядом что-то очень магнитное и не подвергли агрессивным жидкостям (или, например, абразивным суспензиям), то велик шанс восстановления.
Не совсем ненужен. Все равно остаётся проблема курицы и яйца. Во-первых, для DoH/DoT все равно нужен сертификат. Во-вторых, пока DoT/DoH не описан для авторитативных серверов, начиная с корневых, выбор конкретного DoH/DoT провайдера является проявлением существенного доверия к одному.
В век наличия компактных одноплатников, в которых можно организовать по настоящему доверенное исполнение возиться с ненадёжной обфускацией? Ну и в консумерских ноутбуках и десктопах соответствующие фичи тоже уже есть...
А что там сложного, если у каждого есть свой сервер? git remote update и понеслось. Без сервера - только по e-mail или аналогичному каналу - сложновато, да..
Следовать стандартам безопасности. Там, собственно, большая часть правил - это не технические, а организационные требования, типа банальных: "уволился сотрудник - заблокируйте доступ/смените общие секреты (которых при этом надо максимально избегать)"...
Сами БД сейчас надёжные, если их вовремя обновлять. Основные риски - в неверной организации доступов к разным компонентам (сетям, серверам, сервисам). Если элементарно ревьюить код сайта с т.з. безопасности (в помощь "что искать" - сайт https://owasp.org/Top10/ ), и прежде всего смотреть, что он пишет в логи, то всё с большой вероятностью будет хорошо.
А что конкретно интересует? Использовать при работе шифрование, при интерактивном входе двухфакторку, не хранить креды на диске в открытом виде и т.д. и т.п. Словом, выполнять требования соответствующих стандартов.
Если что, тут имеется в виду при запущенном Обсидиане. Описанные механизмы не умеют вытягивать изменения на мобилку в фоне, для этого надо чуть больше костылить.
Так можно отловить только сравнительно частые недостатки. Недостаток, проявляющийся в среднем раз в миллион полётов или раз в тысячу лет найти не удастся.
Корпус с акриловой боковой стенкой, а не из энтерпрайзной стали. Значит, точно нет Chassis Intrusion Detection. :)
А что, разрабатываемая система потом будет существовать в вакууме? Вот в примерах в статье у нас по два пользователя - конечный пользователь и пользователь-администратор. Когда пытаешься понять, как именно различные пользователи (особенно когда их > 3 категорий) будут участвовать в общем процессе, удобнее описывать это BPMN. Как отметил комментатор ниже, в виде Sequence Diagram такая схема будет нечитаема.
Вообще, странен переход от C4 к Sequence, т.к. последний вид диаграмм описывает процессы, (причём требует очень точного описания, иначе читать невозможно) тогда как C4, судя по его описанию, описывает систему в виде статичных её классов - просто в разном уровне детализации. Например, допустимую последовательность деплоя сервисов (контейнеров) из неё не почерпнуть.
Тогда как Sequence Diagram - это "микроописание" деталей поведения кусков системы. И в случае большого количества акторов, BPMN будет намного понятнее - это будет своего рода Sequence Diagram, "вид сверху" (лишённый, разумеется, визуализации хронологической одновременности параллельных процессов).
Странно, что вы написали этот комментарий не на латыни, французском, английском или эсперанто, смотря какой идеальный мир вы для себя видите.
Спасибо, интересная статья.
Вопросы, для лучшего понимания:
Правильно ли я понял, что итог двух лет - это собранная команда по поддержке и доработке запущенного проекта (которая дальше будет жить без участия автора)?
Т.е., в частности, - грейды нужны уже на этап после запуска?
По "текущему раскладу" - я так понял, что грейдапы в созданной команде приветствуются. А есть ли ограничения (в пределах какого-то общего бюджета проекта, по установленным заранее квотам, по готовности заказчика)? Могут ли потенциально при такой схеме получиться оверквалы? Если да, что с ними предполагается делать?
Главное, что бы физически блины не деградировали. Если не проткнули корпус чем-то острым, не сломали пополам, не выбросили рядом что-то очень магнитное и не подвергли агрессивным жидкостям (или, например, абразивным суспензиям), то велик шанс восстановления.
А что делать, если вдруг набежало регуляторки?
По остальной статье - остался вопрос: "ОК, сроки не озвучиваем, а что делать?" :)
Только только получили информацию про перекрытие границ и т.д. :)
А это уже политическая проблема...
Не совсем ненужен. Все равно остаётся проблема курицы и яйца. Во-первых, для DoH/DoT все равно нужен сертификат. Во-вторых, пока DoT/DoH не описан для авторитативных серверов, начиная с корневых, выбор конкретного DoH/DoT провайдера является проявлением существенного доверия к одному.
В век наличия компактных одноплатников, в которых можно организовать по настоящему доверенное исполнение возиться с ненадёжной обфускацией? Ну и в консумерских ноутбуках и десктопах соответствующие фичи тоже уже есть...
А что там сложного, если у каждого есть свой сервер? git remote update и понеслось. Без сервера - только по e-mail или аналогичному каналу - сложновато, да..
Следовать стандартам безопасности. Там, собственно, большая часть правил - это не технические, а организационные требования, типа банальных: "уволился сотрудник - заблокируйте доступ/смените общие секреты (которых при этом надо максимально избегать)"...
Сами БД сейчас надёжные, если их вовремя обновлять. Основные риски - в неверной организации доступов к разным компонентам (сетям, серверам, сервисам). Если элементарно ревьюить код сайта с т.з. безопасности (в помощь "что искать" - сайт https://owasp.org/Top10/ ), и прежде всего смотреть, что он пишет в логи, то всё с большой вероятностью будет хорошо.
А что конкретно интересует? Использовать при работе шифрование, при интерактивном входе двухфакторку, не хранить креды на диске в открытом виде и т.д. и т.п. Словом, выполнять требования соответствующих стандартов.
Если что, тут имеется в виду при запущенном Обсидиане. Описанные механизмы не умеют вытягивать изменения на мобилку в фоне, для этого надо чуть больше костылить.
Помнится, в русификаторе Keyrus использовался растровый шрифт, где все кириллические символы отличались, т.е. можно было понять, что "у" - это не "y".
Я так понимаю, что среди векторных шрифтов такого не оказалось, особенно с развитием Юникода.
Что-то не понял, про "возрождение" - это было про 2020?
Что меня удивляет в SL - полное отсутствие развития вне концепции игры "одень свою аватарку". Тот же Roblox по сравнению с SL - как день и ночь...
Гениальная идея! Из разряда unrar.rar
Разумные рекомендации. Единственное при предложении звонка на 2 минуты имеет смысл уточнять что будете обсуждать и почему это важно, что это блочит.
А бордовый или розовый можно?
Так можно отловить только сравнительно частые недостатки. Недостаток, проявляющийся в среднем раз в миллион полётов или раз в тысячу лет найти не удастся.