Comments 24
Я не понял этот комментарий… отказа от чего?
Простота решения зависит от конкретных задач, которые ставит перед собой компания… Если мы говорим о массовом распространении шрифтов и типов линий- то вполне можно обойтись общими папками. А если речь идёт о шаблонах и конфигурациях инструментальных панелей, которые должны работать для отдельных сотрудников в случае если они трудятся над конкретными проектами… И сотрудников этих больше ста человек… А проектов в разработке- десятки. То тут очень пригодится специальный инструмент. Который никак не должен "глючить" в самый не подходящий момент, поэтому проходит многоэтапное тестирование при разработке.
Который никак не должен «глючить» в самый не подходящий момент, поэтому проходит многоэтапное тестирование при разработке.
про AutoCAD тоже самое говорят… но мы то знаем
Вопрос, конечно, философский. ЧП случаются. Но если страшно полагаться на код, то на алгоритмы, выполняемые вручную надеяться еще опаснее (человеческий фактор- дело такое). Остаётся только предпринимать всевозможные меры, для того чтобы минимализировать риск появления ошибок. К чему мы все, несомненно, стремимся. Все-таки норма- это стабильная работа, а не наоборот!
Мы постарались сделать наш модуль управления максимально прозрачным в сценариях работы и гибким для пользовательских настроек. Более того, есть мнение, что продукт этот больше внедренческий, чем коробочный. Скажем так, универсальная платформа для организации управления настройками САПР. Но и элементы «черного ящика» в нем тоже присутствуют. Так что, насколько это удобно — решать конечно заказчику!
Когда в AutoCAD появилось цетральное управление настройками, исправления которые делались за 5 пять минут — начали делатся за пол или целый день, потомучто пришлось писать заявки САПР'вцам в центральном офисе, в другом городе. А ещё выяснилось, что для Civil'а нужны другие настройки — это вообще затянулось на несколько дней…
Ps. Еще бы ворд так обуздать…
"отечественный разработчик хорош в том числе и тем, что находится в постоянном контакте с пользователями и готов" — не соглашусь с этим утверждением. Конкретно в случае с нанокад, на форуме разработчиков — очень редко отвечают. Почти такая же ситуация на форуме для пользователей линейки продуктов нанокад. Создается впечатление что форум забросили несколько нет назад. Справедливости ради можно отметить что и число форумчан не велико, но все же это ни как не оправдывает долгие ответы или вовсе их отсутствие.
выделить папку, доступ к которой осуществляется по FTP-протоколу. Этот способ организации хранилища позволит скрыть структуру файлов, а значит заблокирует утечку интеллектуальной собственности организации, даже теоретически устранив возможность скопировать «Стандарт предприятия» вовне.
1) а что мешает «сохранить как..» хоть шаблон, хоть полупустой файл с настроенными стилями/слоями/…?
2) что будет с чертежами полученными от субчиков? при открытии автоматом все шрифты и стили поменяются в соответствии с СТП?
2. Автоматом нет. Но DWS при каждом сохранении будет говорить, что в них нарушены такие-то такие-то пункты СТП на DWG. Субчиков имеет смысл строить с помощью договоров и требований к сдаваемым материалам.
Иными словами, инструмент достаточно гибкий, чтобы в зависимости от ситуации получать от САПР желаемый результат. Главный вопрос — какой результат является желаемым при работе с файлами, пришедшими от субподрядчиков?
У субчиков своё ПО(возможно отличное от заказчика), своё СТП…
В одной конторе все размеры/выноски вынесены на один слой, а в другой организации слоёв с размерами может быть множество (речь про ПГС)
Считаю, что автор затронул очень больную тему многих КБ. Видно, что есть понимание проблемы стандартизации выпуска КД. По моему опыту, очень часто так бывает, что КБ существует уже более 5 лет, и формально даже СТП уже есть, и все конструкторы с ними ознакомлены, но продолжают лепить чертежи так, как каждый конструктор считает нужным.
Стандартизация при работе в САПР. Зачем это нужно и как ее контролировать?