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

В этой статье я, технический писатель Renga Software Анастасия Тян, расскажу, от чего мы отталкивались в начале разработки справки для BIM-системы Renga и к чему в итоге пришли.

Итак, пользователи наших продуктов ― архитекторы, проектировщики и конструкторы. Для них был разработан минималистичный интерфейс Renga, состоящий всего из нескольких панелей и рабочего пространства, ограниченного лишь размерами мониторов. Разумеется, хочется, чтобы документация не отставала от интерфейса в оформлении, а также предоставляла пользователям всю необходимую информацию.



С самого начала разработки Renga было понятно, что нам необходима современная онлайн-справка. Также было принято решение, что мы не будем отказываться от оффлайн-справки в формате CHM, чтобы пользователи могли к ней обращаться без подключения к интернету и не тонуть в ворохе html-файлов.

Что такое октодеревья? Если вам совершенно неизвестно это понятие, то рекомендую прочитать статью в Википедии (это займёт около пяти минут). Она даёт достаточное представление, но едва ли её будет достаточно, чтобы понять, для чего они используются и как их реализовать.

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

В предыдущих постах мы рассказывали о том, как разрабатывается и тестируется САПР КОМПАС-3D. Дополнительно запущен цикл статей по разработке приложений с использованием API КОМПАС-3D. Пришло время рассказать о «начинке», которая управляет всеми построениями в КОМПАСе – ядре геометрического моделирования C3D или просто геометрическом ядре C3D.


Автолестница пожарная АЛ-30 (изготовитель: ООО «Пожарные Системы»)

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

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



Будем откровенны: если ваш продукт ориентирован на широкую аудиторию, то английского языка явно недостаточно. Конечно, существуют узкоспециализированные проекты и сервисы вроде нашего, когда знание главного международного языка не прихоть – необходимость, однако ниша подобных разработок крайне узка. И вот, тысячи команд по всему миру рано или поздно упираются в потолок одного-двух языков: один английский, а второй – родной для команды (если она не англоговорящая). Дальше начинаются споры, ссоры, попытки локализации и последующие пляски с бубном.

В этой публикации мы собрали ряд популярных советов и рекомендаций как от частных разработчиков, так и от матерых команд уровня Mozilla, в которых более опытные товарищи делятся со своими коллегами опытом локализации проектов.

Перевод статьи Стивена Хубера.

Многие читают и ссылаются на статью 2013 года “How Do Users Really Hold Mobile Devices?”. Но с тех пор было проведено немало исследований и экспериментов по использованию разных методик в реальных продуктах, написано много других статей. За прошедшие годы стало больше известно о том, как люди удерживают свои смартфоны и планшеты, как они взаимодействуют с ними тактильно. И всех этих, зачастую неожиданных данных, нет в старой статье 2013 года. И это её главная проблема. В ней были сделаны предположения, основанные на наблюдениях за использованием десктопов, на стандартах для более старых способов взаимодействия, а также на казусных ситуациях и неверно интерпретированных данных. Но благодаря дальнейшим исследованиям и более качественному анализу удалось отвергнуть ошибочные предположения и докопаться до истины.

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

Всем привет! В этой статье хочу разобрать процесс подключения шлема виртуальной реальности к десктопному приложению под Windows. Речь пойдет об Oculus Rift.

Архитектурная визуализация — очень благодатная тема для различного рода экспериментов. Мы решили не отставать от тренда. В одной из следующих версий наших BIM-систем (напомню, что я работаю в компании Renga Software, совместном предприятии АСКОН и фирмы «1С»): Renga Architecture — для архитектурно-строительного проектирования и Renga Structure — для проектирования конструктивной части зданий и сооружений, появится возможность хождения по проектируемому зданию в шлеме виртуальной реальности. Это очень удобно для демонстрации проекта заказчику и оценки тех или иных проектных решений с точки зрения эргономики.

Всем привет! Я работаю в компании Renga Software (совместное предприятие АСКОН и фирмы «1С»), которая занимается разработкой BIM-систем: Renga Architecture — для архитектурно-строительного проектирования и Renga Structure — для проектирования конструктивной части зданий и сооружений.

В этой статье хочу поделиться опытом интеграции 3D-мыши в систему Renga.

В предыдущих уроках по API КОМПАС (Напоминаем, что в качестве среды используется C++ Builder) Основы и Оформление чертежа мы исходили из того, что КОМПАС не запущен, и запускали его сами методом CreateInstance. Но что если в момент вызова этого метода КОМПАС уже запущен? Тогда будет создан еще один экземпляр данной программы. В принципе ничего страшного, но неаккуратно. Зачем плодить копии программы, когда можно обойтись одним экземпляром?

Большинство крупных организаций сталкивается с трудностями в выполнении массового обслуживания ПО. Эти трудности носят как объективный, так и субъективный характер. Объективной трудностью является неоднородность ИТ-инфраструктуры, полностью преодолеть которую невозможно. Однако руководители ИТ-отделов и системные администраторы не всегда уделяют должное внимание этой проблеме. Главной субъективной трудностью является отношение к обслуживанию корпоративного ПО как к обслуживанию коробочного и, как следствие, вера в существование «магической зелёной кнопки»: нажал — и всё установилось (обновилось). На практике такой сценарий, увы, нереализуем.

Сейчас почти на всех сайтах есть регистрация. Реализована она чаще всего с помощью e-mail, реже с помощью смс. А что если сделать регистрацию через telegram бота? В качестве логина на сайте мы сможем использовать подтверждённый номер телефона, а сам бот будет посылать одноразовые коды для входа. В данной статье описан процесс создания такого бота на языке Golang.


Пример работы бота

Хотелось бы сразу отметить: в статье не будет описана реализация входа на сайт по одноразовым кодам.

И снова про API САПР КОМПАС. Новая статья Сергея Норсеева, инженера-программиста АО «ВНИИ «Сигнал», автора книги «Разработка приложений под КОМПАС в Delphi». Первую статью можно прочесть здесь.

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

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



Рассказывает Сергей Александрович Норсеев — инженер-программист, АО «ВНИИ «Сигнал», Ковров. Автор книги «Разработка приложений под КОМПАС в Delphi»

Может ли Pilot-ICE спасти данные от вирусов-шифровальщиков? Чтобы ответить на этот вопрос, мы провели экспериментальное заражение нашумевшим вирусом Wana Decrypt0r 2.0 изолированной тестовой системы, на которой запущен сервер Pilot-Server и клиент Pilot-ICE. Другие криптовирусы действуют по схожему принципу, отличается только способ заражения. Рассматриваем самый экстремальный случай, когда резервной копии нет.



Рассказывает Дмитрий Поскребышев — руководитель отдела разработки систем управления инженерными данными.

В этой статье я предлагаю краткий обзор библиотек геометрического моделирования с точки зрения разработчика специализированной CAD системы и делюсь опытом интеграции ядра C3D.

Если рынок «больших» программ проектирования давно поделен между несколькими крупными игроками вроде AutoCAD, SolidWorks, NX, Creo Elements и CATIA и т.п., то рынок специализированных программ проектирования всего и вся – окон и лестниц, корпусной и мягкой мебели, трубопроводов и корпусов весьма широк и динамичен. Причин для этого, на мой взгляд, две: во-первых, это высокая стоимость покупки крупной САПР и сотрудника, умеющего в ней эффективно работать. А, во-вторых, отсутствие адаптации для проектирования конкретных изделий в крупной САПР приводит к тому, что скорость проектирования специализированных изделий в них низкая.

Специализированные САПР являются ответом на указанные проблемы и перед программистом стоят два пути их создания. Первый – доработка крупной САПР с использованием предоставляемых API, плагинов и всевозможных скриптов. Этот подход не всегда оправдан, т.к. в результате стоимость САПР возрастает для пользователя (нужно платить как за большую САПР, так и за адаптацию), а требуемая квалификация инженера (а, следовательно, и затраты на его обучение и содержание) для работы с таким комбайном достаточно высоки. Второй путь – создание системы «с нуля». Этот путь, несомненно, значительно сложнее, т.к. огромный функционал нужно разработать с самого начала. Но несмотря на это он может оказаться значительно дешевле и удобнее в использовании для конечного пользователя, который и определяет успех продукта.

Не секрет что для успешного внедрения любой системы документооборота необходимо произвести несколько логичных шагов, в данном посте я опущу этапы исследования, начну с пилотного проекта. И постараюсь описать проблемы и способы решения оных, которые с уверенностью в 90% существуют на любом пост-советском «кондовом» предприятии.

Работая в конструкторском отделе, я столкнулся с задачей — рассчитать трудоёмкость разработки конструкторской документации. Если брать за основу документ: «Типовые нормативы времени на разработку конструкторской документации. ШИФР 13.01.01" (утв. Минтрудом России 07.03.2014 N 003)», то для расчета трудоёмкости чертежа детали нам необходимы следующие данные:

• Формат чертежа и количество листов
• Масштаб
• Количество размеров на чертеже (включая знаки шероховатости и выносные линии)
• Количество технических требований

Из имеющихся инструментов на предприятии имеем: Kompas 3D v14 и Python 3.5.

В интернете не так много статей о написании программ с использованием API Kompas 3D, и ещё меньше информации о том, как это сделать на Python. Попробую рассказать по шагам, как решалась поставленная задача и на какие грабли приходилось наступать. Статья рассчитана на людей, владеющих основами программирования и знакомых с языком Python. Итак, приступим.

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



Рассказывает инженер по тестированию Екатерина Родина.

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

В "Чертежи в SVG формате. Часть 4 — Черновик стандарта " приведён пример рисования размеров. В продолжении рассмотрим использование JavaScript и сравним файлы чертежей в разных форматах.

В "Чертежи в SVG формате. Часть 1 — Черновик стандарта (обновляется)" приведён пример объектной модели чертежа, задания масштаба и стилей линий.
Опираясь на основные принципы создания чертежа, для Компас-график 2D создали тестовую альфа версию библиотеки экспорта в SVG.