Меня зовут Олеся Лазарева, я работаю старшим разработчиком в команде PIlot.

В этой статье мы рассмотрим создание плагина криптопровайдера для веб-редакции системы управления инженерными данными Pilot-ICE Enterprise. Веб-редакция Pilot-ICE Enterprise работает с плагинами, которые используют формат электронной подписи CADES-BES. Данные плагины поставляются в составе Ascon.Pilot.Web.SDK. Это покрывает потребности большинства российских организаций, работающих в соответствии с требованиями ГОСТ.

«Он меня игнорирует!», «Они не хотят брать ответственность!», «Все так делают!» — знакомые фразы? За ними часто скрывается не проблема коллег, а проекция. Как ее распознать в командной работе, почему это критически важно в IT‑среде и какие практические инструменты помогут минимизировать ее негативное влияние — ответим на все эти вопросы ниже. 

Привет, Хабр! Меня зовут Игорь Поляков, работаю веб-программистом технологических приложений ВЕРТИКАЛЬ. В данной статье расскажу о стратегии обнаружения изменений в Angular с учетом обновлений фреймворка версии 17 и выше. Если вас беспокоит вопрос производительности и вы желаете разрабатывать оптимизированные приложения, добро пожаловать! 🚀

Переезд с обжитого места всегда дается непросто: нужно перевозить накопленное годами, обустраивать заново и привыкать к новому месту. Примерно так же обстоят дела и при замене иностранного софта на отечественный. Когда речь идет о среде общих данных (СОД/CDE) строительных проектов, требуется перенести весь объем проектных данных из одной системы в другую, но так чтобы пользователи не заметили перемены. Об автоматизированной миграции данных, выполненной для московского девелопера Tekta Group, рассказывает Алена Владимирова, инженер по внедрению АСКОН-Центральная Россия.

Проектируете вы на работе или мастерите свой пет-проект (как @Doctor_IT, автор VR-жилета — с удовольствием прочитали и заплюсовали пост), настает момент, когда надо оптимизировать разрабатываемую конструкцию. Обычно, чтобы уменьшить ее массу или снизить расход материала. Оптимизацией сегодня и займемся, на связи Дмитрий Крекин из команды КОМПАС-3D. 

Привет, Хабр! Меня зовут Евгений Песков, я работаю аналитиком в команде разработки САПР техпроцессов ВЕРТИКАЛЬ. Рискну поднять тему, из‑за которой сломали уже не одну сотню копий, — идеальная аналитическая статья. Возможно ли сконструировать ее шаблон? Чтобы материал был удобен в использовании всем участникам команды разработки, а я, как автор, минимизировал трудоемкость по его написанию и сопровождению.

Привет, Хабр! Меня зовут Алексей Салтыков, я инженер-программист в команде КОМПАС-3D. Решил поделиться соображениями насчет оптимизаций в С++ глазами обычного разработчика. Хочется сразу предупредить, что статья никого ни к чему не призывает. Цель – наглядно показать, как незначительные трансформации кода могут помочь компилятору лучше оптимизировать код и насколько это вообще эффективно.

Снова привет, Хабр! Меня зовут Евгений Сергеев, я работаю инженером-программистом в АСКОН, а в свободное время увлекаюсь астрофотографией. В предыдущем посте я уже рассказывал о первых шагах в этом хобби и доступной аппаратуре, а теперь расскажу подробнее о недавней поездке и поделюсь советами с новичками.

Привет, Хабр! Меня зовут Евгений Сергеев, я работаю инженером-программистом в АСКОН, а в свободное время увлекаюсь астрофотографией. Именно ей будет посвящена статья. Я не буду затрагивать слишком много технических деталей, поскольку невозможно все охватить в рамках одного материала. Тем более, что на Хабре есть и другие статьи об астрофотографии. Я расскажу о своем опыте: как познакомился с этим увлекательным хобби и как можно начать самому без траты целого состояния.

Несмотря на то, что наши сегодняшние процессы выглядят достаточно устойчиво, хотелось бы, во-первых, иметь возможность вовремя увидеть возможные негативные тенденции и причины их возникновения, а во-вторых, оставаться открытыми к полезным инициативам.

Всё это сподвигло нас к анализу накопленного опыта и имеющихся материалов в области процессов разработки с акцентом на взаимоотношения в коллективах. Мы — это Евгений Филимонов и Андрей Клюйков, инженеры по тестированию КОМПАС-3D.

В ходе проработки содержания статьи мы решили сгруппировать попарно антипаттерны, являющиеся крайними проявлениями одной сущности, и придать им гротескную форму. Мы посчитали, что через призму таких антипаттернов будет проще обратить внимание на те области наших процессов, которые имеют потенциал к улучшениям и оптимизации. Особенно это актуально, когда масштабы задач непрерывно растут и наблюдаются достаточно высокие темпы роста штата сотрудников.

И наконец, чтобы приблизиться к пониманию актуальности темы антипаттернов, решили провести небольшой опрос среди коллег, результаты которого приведены в конце статьи.

Что для нас качественный бэклог? Под самим словом бэклог будем понимать список задач, в частности пользовательских историй, которые должна реализовать команда разработки в определенные сроки. Как правило, появляются они в результате декомпозиции функциональности. Что касается качества, то его основным критерием здесь будет результат выполнения этих задач. Другими словами, если мы достаточно точно, с учетом рисков и приоритетов, можем спрогнозировать сроки и результаты выполнения разрабатываемой функциональности, то бэклог можно назвать качественным. О нем и поговорим. На связи Владислав Филимонов, инженер-аналитик КОМПАС-3D.

В данной статье представлен небольшой обзор инструментов, которые я активно использую в своей работе. Меня зовут Андрей Канивец, я аналитик систем жизненного цикла изделий. 

Типы инструментов можно разделить на методологические инструменты и программные средства, которые в свою очередь подразделяются на программы для работы с аудио и видео, текстовые редакторы, инструменты для быстрой разработки и прототипирования, а также инструменты искусственного интеллекта для распознавания речи и обработки текста.

Привет, Хабр. Меня зовут Сергей Синяков, тимлид команды спецификации в разработке КОМПАС-3D, занимаюсь вопросами управления данными об изделии и формированием документа Спецификации. И сегодня мы поговорим про API.

Любой программный продукт не существует в вакууме и предназначен для взаимодействия с пользователем через пользовательский интерфейс (UI) и/или с внешним приложением через API. Учитывать будущий интерфейс приложения чрезвычайно важно еще на этапе проектирования, т.к. требования к UI и API  могут накладывать существенные ограничения на архитектуру продукта. Не зря классическая пользовательская история, поступающая в разработку, звучит так: "Я как пользователь, выполнив определенные действия с UI, ожидаю получить соответствующий результат".  Если же спроецировать пользовательские истории на API, получим сценарий для автотестов и разработку через тестирование - TDD, когда перед началом разработки структуры данных, функции API и их ожидаемое поведение фиксируются в тестах, а разработка фокусируется на обеспечении их корректного прохождения.