PTC, Inc.

PTC — международная компания, пионер в создании программного обеспечения параметрического проектирования (САПР). Один из основных продуктов фирмы — «PTC/Creo», программа для трёхмерного дизайна, в разработке которой я участвовал. Это аналог CATIA, SolidWorks или AutoCAD, используемый ведущими производителями в аэрокосмической (NASA, Boeing, Airbus, Hill Helicopters), компьютерной (Samsung, Apple), автомобильной (Toyota, Hyundai, Carlin, CUPRA, Volvo) и других областях. Я как-то раз получил сообщение о проблеме даже от дизайнера украшений 🙂 К слову, проблема эта была в действиях пользователя, — он неправильно использовал одну из наших функций.

Моя машина, — Hyundai i20, — спроектирована в программе, которую я писал.

Я работал в отделе, разрабатывающем функциональность Family Table. Этот функционал позволяет создавать несколько различных деталей на основе одной («базовой») и списка изменений, записанного в таблице. Пример: автомобиль может быть оснащён несколькими разными двигателями. Создаётся базовый чертёж автомобиля, а затем строится таблица, в которой указываются различия между моделями, — какой чертёж двигателя подгружать, как сдвигаются крепления двигателя к корпусу, какие нужны изменения в трансмиссии и т. п.. Вот эта таблица называется Family Table. На основе базового чертежа и записей в Family Table очень просто создать целое семейство похожих моделей, и это по-любому будет проще и быстрее, чем для каждой модели ради, может быть, изменения в одном болтике рисовать отдельный трёхмерный чертёж с нуля.

Вышеупомянутый дизайнер украшений использовал Family Table для того, чтобы на основе диаметра кольца размещать на нём разное количество бриллиантов на равном расстоянии друг от друга: чем шире кольцо, тем больше бриллиантов на него можно налепить.

Опыт работы

• Начал в 2012, закончил в 2016.
• Должность: Разработчик программного обеспечения.

Мои достижения

Во время работы над программой «PTC/Creo»:

• Участвовал в разработке поддержки чертежей, созданных в программах-конкурентах.
• Разрабатывал функциональность «Concept Design», позволяющую создавать несколько веток чертежей с возможными изменениями существующего проекта, сохранять особенно успешные чертежи, быстро переключаться между ними, видеть список изменений между чертежами и в конце концов решить, какой из всех этих прототипов лучше всего годится для того, чтобы назвать его новой итерацией основного проекта.
• Участвовал в разработке продукта «Creo Layout», позволяющего воссоздать трёхмерный объект на основе двухмерных чертежей.

«PTC/Creo» за свою долгую жизнь работал на туче всевозможных платформ. Часть кода, который я видел, была написана в 1986 году, ещё до появления официального стандарта языка С. Эту программу можно было запустить на любой операционной системе, от IRIX до MacOS 9 Classic. В PTC меня научили правильному подходу к обеспечению портируемости программы: весь внутренний код программы начисто оторван от операционной системы, а между программой и операционной системой размещается библиотека HAL (Hardware Abstraction Layer), которая переводит вызовы программы в то, что ожидает операционная система. Таким образом, для запуска Creo на новой операционной системе нужно было всего лишь создать новый HAL.

Понятно, что абсолютное большинство HAL-библиотек давно не поддерживалось, — ну кому придёт в голову в 2014 году загружать систему трёхмерного моделирования на мёртвой операционной системе, последняя версия которой вышла в 2006 году? Тем не менее, в офисах было полным-полно оборудования, казавшегося мне легендарным: кинескопные мониторы Silicon Graphics, клавиатуры SUN с кучей дополнительных клавиш слева от буквенного блока, серверы HP-UX и прочее в том же духе… Разработка «Creo» тоже была необычной: код писали в операционной системе Solaris, тестировали под HP-UX, а компилировали и продавали версии под Windows и под macOS X. Я был третьим разработчиком, которому сразу поставили для разработки компьютер с Windows, и одной из моих первых задач было создать руководство по переносу всей разработки на Windows. После решения всех проблем я подготовил двухчасовую лекцию о порядке разработки, компиляции и тестирования под Windows, включая работу с системой управления версиями и прочими интересностями. Эта лекция прошла с полным аншлагом, потому что присутствие было обязательным, она даже была записана на видео в качестве руководства для последующих поколений. По результатам этого проекта я получил «Certificate of Excellence» («Сертификат за выдающиеся достижения») с сопутствующей денежной премией 😊

Одним из недостатков «Creo» была необходимость статической линковки всей программы. Для Linux, Solaris и подобных систем вся программа компилировалась в один гигантский бинарник больше гигабайта весом. Всё, что только есть в «Creo», становилось частью этого исполняемого файла. Напоминаю, мы говорим о 2012 году; я никогда раньше не видел исполняемый файл такого размера, да и сейчас такие файлы — редкость, я надеюсь.

На мой вопрос «почему бы не распотрошить программу и не вынести её части в подгружаемые библиотеки» мне было сказано, что надо бы, но до этого никогда ни у кого не доходят руки. Тогда-то я и познакомился с тем, как относится начальство к термину „Refactoring”. Справедливости ради надо заметить, что другие разработчики всё-таки понимали, что это надо делать, выполняли refactoring по частям во время работы над другими проектами, и под Windows программа уже действительно могла похвастаться каким-то количеством динамически подгружаемых библиотек.

Большой проблемой было быстродействие программы. Детали в чертеже «PTC/Creo» связаны между собой. Их может быть много. В чертеже корабля (да, в «PTC/Creo» проектируются и корабли целиком тоже) может быть четыре миллиарда деталей, каждая с чётко прописанным расположением и с целым списком зависимостей: болтик А скрепляет между собой детали Б В посредством ушек Б1 и В1 с отверстиями в них. Изменение положения ушка Б1 ведёт к изменению детали Б, к изменению положения ушка В1 и детали В. Ушко с отверстием В1 при этом может оказаться в таком месте, где оно не может размещаться из-за того, что там уже помещается деталь Г. Изменение диаметра болтика А ведёт к изменению диаметра отверстий в ушках Б1 и В1, что потенциально отражается как на стоимости деталей, так и на их прочности. Всё это необходимо учесть.

Перерасчёт всего чертежа в результате изменения одного параметра (или больше) называется «регенерацией», потому что вся геометрия, по сути, пере—создаётся заново. И распараллелить эти вычисления на несколько разных потоков не получится, потому что заранее неизвестно, на какие именно части повлияет то или другое изменение одного параметра. Поэтому весь чертёж, сколько бы деталей в нём ни было, перерассчитывается снова, в один поток, по одной детальке за раз. Время регенерации чертежа корабля из четырёх миллиардов деталей на компьютере образца 2010-х годов вы себе хорошо представляете? Вот тут-то и были нужны способности программиста, умеющего писать быстрый и оптимизированный код. Коллеги, с которыми я работал в «PTC», просто настоящие звери, способные скомпилировать, отдебажить и запустить хоть программу XXII съезда КПСС, причём на минимуме ресурсов.

Во время работы над проектом «ThingWorx»:

Затем я в течение года участвовал в разработке проекта ThingWorx, платформе для быстрого развития проектов в сфере Industrial Internet of Things и Augmented Reality. На основе этой платформы, например, компания «John Deere» создала трактор, который сам заказывает деталь взамен сломавшейся, а приехавшему с деталью механику показывает в дополненной реальности, как эту деталь быстрее и правильнее заменить.

• Я был единственным из всего коллектива, кто сидел в офисе в Хайфе; остальной отдел размещался в офисе в Герцлии. Моё особое положение послужило причиной того, что в течение первого года я практически всё время занимался научно-исследовательской работой, сравнивая различные технологии и давая рекомендации начальству.
• Например, я сравнивал различные серверы баз данных и рекомендовал использовать в проекте PostgreSQL.
• За эту свою научно-исследовательскую деятельность я получил оценку «Exceeded Expectations» («Выше ожидаемого») на ежегодной аттестации.



• После того, как исследовательская фаза завершилась, мы начали писать код, причём на Angular JS. Я, системщик, должен был писать на JavaScript! Я ведь даже не знаю, под какой операционной системой мой код будет работать! Это оказалось настолько далеко от того, чем я любил заниматься, что я достаточно быстро взял ноги в руки и покинул это место.