Подготовка технической документации *

Идея создания цифровых двойников прочно вошла в умы всех людей, занятых модернизацией производства во всем мире. О работе команды TechnologiCS в этом направлении мы уже говорили в статье «TechnologiCS 7.9 – цифровизация всего жизненного цикла продукции на базе одной системы». Теперь пришло время обсудить элементы инфраструктуры взаимодействия пользователей с цифровым двойником. Ведь автоматизировать сбор разнородных данных и собрать на них каркас цифрового двойника не является конечной целью в процессе создания модели производства – необходимо организовать работу сотрудников с огромным объемом все увеличивающейся информации. И не просто наладить работу, а сделать ее комфортной и эффективной. Для этого следует иметь в арсенале удобные точки взаимодействия с цифровым двойником, упрощающие работу и доставляющие необходимую информацию пользователю «just in time».

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

Вариант автоматизированного формирования документа в формате *.docx с использованием скрипта на языке Python и библиотеки python-docx. Как правильно подготовить документ стандартными средствами Microsoft Office, что нужно учесть при создании скрипта, порядок сборки и сохранения документа.

Рассмотрим взаимодействие с компанией SweetCard, которая представляет достаточно удобную платформу таргетированных предложений держателям карт. В «МКБ Онлайн» это раздел «Персональные предложения».

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

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

За свою карьеру программиста я видел множество разных технологий и фреймворков от гигантов индустрии, таких как Oracle, Microsoft, IBM и т. п. Но в каждом из них было какое-то неудобство. А конкретнее у них у всех было одно общее, это необходимость реализовывать серверную логику чтобы можно было использовать ее в шаблонах. И это мне сильно не нравилось, приходилось делать одну и ту же работу из проекта в проект.

Один из таких подходов разнесения логики был паттерн программирования MVVM(Model-View-ViewModel). Его активно продвигали во фреймворках для C#. Структурно с точки зрения разнесения логики, я считаю этот паттерн самым удобным.

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

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

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

Одно видео уже готово, но пока не было времени сделать пост-продакшн, анимашки всякие добавить, в общем сами понимаете, если делать продукт, то его надо делать качественно.

После небольшого вступления, давайте приступим именно к сабжу.

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

Привет, Хабр! Меня зовут Роман Блинов, я ведущий технический писатель в «Цифре» — в команде по развитию платформы ZIIoT. Этот пост будет о подходе Docs-as-code для документирования разработки ПО. Пишу с прицелом на тех читателей (то есть писателей), кто этот подход пока не пробовал и по факту имеет набор файлов в Confluence, файлы формата .docx и .pdf, на поддержку, обновление и оформление которых тратится порядка 70 % времени (а хотелось бы меньше), и 101 отговорку разработчиков, чтобы не участвовать в документировании.

Сначала расскажу, с какими проблемами сталкиваются писатели до перехода на Docs-as-code, затем опишу подход в общих чертах и в конце упомяну об основной трудности его внедрения по собственному опыту и опыту коллег.

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

При работе в разных компаниях, чаще всего встречалось раздражающее отсутствие актуальной документации или «документационная мусорная куча», где было сложно найти требуемое. Нередко проблемы были в стиле «это знал уволившийся Петя, но его не спросить». Или в наличии деталей, которые были незначимы по мнению разработчика, но которые оказывались критическим знанием «переоткрываемым» последователями (нередко и самим разработчиком, вернувшемуся к проекту). Для облегчения жизни, был сделан специальный инструмент, позволяющий держать записи по проекту прямо среди исходных текстов.

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

Можно встретить много  примеров того как применять customer development, который опирается на “персоны”,  для B2C, B2B продуктов, даже для B2BC решений, но сегмент продуктов внутреннего потребления как правило скрыт от посторонних взглядов. Их чаще называют проектами по “автоматизации бизнес-процессов”, которые решают задачу для внутреннего клиента. Особенностью таких проектов/продуктов является секретность, неотвратимость пользования создаваемым продуктом (как считают многие оптимизаторы) и возможность “дотянуться” до потребителя рукой.

В статье аккумулированы некоторые типичные ситуации, выстраданные многолетней практикой по автоматизации бизнес-процессов в десятке отраслей, где я побывал на разных ролях: от business analyst до product manager. Ключевый объект суммирирования опыта — люди, а именно знаниях об их осознанных или неосознанных потребностях, которые являются отправной точкой улучшений.

В прошлой статье про XWiki я обещал не затягивать с публикацией новых материалов, но оказалось, что "не затягивать" это понятие растяжимое (простите за каламбур, не удержался). И перерыв вышел долгим.

В этот раз мы рванем сразу с места в карьер и попробуем расширить профиль пользователя в Xwiki.

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

Эта статья продолжает цикл публикаций о российских BIM-технологиях и посвящена программному комплексу Model Studio CS Технологические схемы, предназначенному для решения задач разработки схемных решений при проектировании разделов ТХ.

Введение

На первый взгляд разработка схемных разделов технологических решений может показаться простой и довольно тривиальной задачей. Результат в виде получившейся схемы всегда представляется простым и понятным. Но когда понимаешь, что внесенная информация и решения, принятые на этом этапе, проходят через все стадии проекта, становится ясно – для эффективной работы и сокращения числа возможных ошибок необходим удобный и надежный инструмент. Инструмент, который автоматизирует стандартные операции и позволит не отвлекаться от процесса проектирования. Такой, каким в полной мере является программный комплекс Model Studio CS Технологические схемы.

JSDoc - это язык разметки, используемый для аннотирования исходного кода JavaScript с использованием комментариев. Аннотации обрабатывается различными инструментами для создания документации в доступных форматах, таких как HTML и Rich Text Format.

Всем привет! Меня зовут Семен. Я Java-разработчик и руководитель группы Java-разработки в Центре Big Data компании MTS Digital. В этом посте я хочу поговорить о Release Notes. Что это такое, почему не стоит писать их вручную и какие есть способы автоматизации. Покажу и реальный пример того, как организована  работа с Release Notes в нашем проекте.

Подобно безумному исследователю, я вот уже пятый год пытаюсь создать идеальную продуктовую документацию. Но, раз она всё еще не идеальна, значит я что-то делаю не так. Вот про это и будет статья.

Хочу очертить тот путь, который мы прошли, и рассказать о том, какие решения принимали, и что из этого вырастало.

Привет! Меня зовут Катя, я руководитель команды технических писателей в Ozon.

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

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

Hello World!

Меня зовут Сергей Павлов, я тимлид по системной аналитике в банке "Открытие” на продукте МСБ “Бизнес-Портал”. Хочу рассказать, как я решал задачи по управлению командой, когда к ней присоединился.

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

Итак, морозное утро, вежливый голос руководителя мне говорит: “Это команда системных аналитиков, начинай творить добро”. Я смог выдавить только “угу” и сел думать насчет того самого творить и того самого добра.

Привет! Меня зовут Наталья и я DocOps-инженер в компании Yadro.

Я планирую выпустить цикл статей об этой профессии на примере Yadro. Первая статья носит обзорный характер, последующие будут более техническими и содержать примеры реальных кейсов, с которыми приходится сталкиваться во время работы.

Немного о себе

Я окончила механико-математический факультет, во время учёбы занималась матмоделированием в области авиастроения, затем семь лет работала инженером по локализации и техническим писателем в Xsolla, потом полтора года в роли руководителя команды автоматизации, и вот я DocOps в компании Yadro.