Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

Приветствую моих читателей! Меня зовут Екатерина. Ранее 3.5 года я администрировала bpm-систему, сейчас вот уже более двух лет я работаю системным аналитиком и развиваю нашу собственную bpm-систему. В данной статье хочу рассказать о дилемме, с которой столкнулись я и моя команда.

Немного познакомлю вас с тем, над чем мы работаем — BPMS (система для управления бизнес-процессами, в основе которой лежит BPMN). Движок полностью разработан специалистами компании. Фронтовая часть реализована на основе библиотеки bpmn.io, с доработкой логики, специфичной для внутренних задач. В этой библиотеке представлен широкий выбор элементов, но у нас своя обёртка над ней — bpmn-editor, в которой мы открываем элементы для пользователей по мере проработки логики их автоматизации.

Немного о той части системы, над которой работаю я:

Всем привет, я разработчик из компании Bimeister и я хочу рассказать о шаблонном C# сервисе, который мы создали, чтобы унифицировать наши приложения и сократить время работы разработчиков над базовой настройкой приложения.

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

Для решения этой задачи Microsoft создала возможность делать свои шаблоны приложений для .net. Он представляет из себя обычный проект на C#, который можно упаковать в nuget пакет.

Перво-наперво необходимо определиться с архитектурой приложения, какой подход, какие паттерны будем использовать. Для вдохновения мы смотрели на пример от Microsoft https://github.com/dotnet/eShop.

Салют! На связи Ганзюк Владимир. Тружусь инженером по нормативно-справочной информации (НСИ) в компании Bimeister.

Хочу поделиться с вами опытом работы с Excel: расскажу, как можно ускорить выполнение рутинных задач при работе с составлением наименований согласно нормативно-технической документации (НТД).

Статья ориентирована на читателя, который еще сомневается в том, стоит ли ему пробовать чат‑боты в работе. Если вы знакомы с технологией и пробовали её в повседневной деятельности то вряд ли найдете её полезной.

Немного расскажу о реальном применении GPT у нас в компании.

Представьте, что вы просыпаетесь под звуки рычания львов вдалеке, зная, что ваш дневной офис — это уютный домик, расположенный в самом сердце африканского буша. Возможно, так вы представляете себе удаленную работу в Южной Африке, стране, известной своими захватывающими дух пейзажами, богатым культурным наследием и разнообразной дикой природой. Как обстоят дела на самом деле, я расскажу в этой статье. Меня зовут Екатерина Лосицкая, я родом из Беларуси, два года живу в Южной Африке. Я работаю QA в лучшей компании Bimeister. Многие ребята в нашей компании трудятся над одним делом из разных точек Земли.

Мы запускаем цикл статей «Bimeister на карте», где расскажем про жизнь и работу в самых необычных странах.

3D-Сканирование как инструмент обратного проектирования.

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

Когда может появиться необходимость применения реверс-инжиниринга? Я столкнулся с необходимостью создания динамического и статического оборудования в рамках построения цифрового двойника крупного предприятия ГПНС, используя как облака точек цехов, так и различную документацию на оборудование. Ранее необходимость возникала в связи с созданием базы твердотельных моделей отсканированной 3D сканером оснастки деталей разгонных блоков для ее дальнейшего изготовления на станках с ЧПУ.

В данных случаях, 3D модели оборудования создавались мною в различных программных комплексах и в рамках статьи я хотел бы показать один из способов создания 3D модели, используя облака точек и такие программы как Polyworks и Geomagic Design X.  

Существует заблуждение, что дизайн — это вопрос вкуса, и у него нет объективных критериев оценки. Но не стоит забывать об условиях использования приложения. Например, таких факторах, как шум, низкое качество, старое тормозное оборудование или программное обеспечение, ограничение доступа в интернет из-за  безопасности. Если копнуть поглубже можно найти много критериев. Поэтому давайте наконец развенчаем этот миф!

Привет, Хабр! Меня зовут Кирилл Голубовский. И сегодня хочу поделиться информацией, которая пригодится всем, кто хочет понять, насколько удобным является их решение. Вы разберётесь, что нужно учесть при логическом проектировании сложных систем с запутанными сценариями. 

Сейчас я возглавляю дизайн Bimeister. Мы с командой занимаемся разработкой BIM и ERP-систем, способных эффективно цифровизировать предприятия.

Всем привет! Я Дмитрий - руководитель группы функциональной архитектуры

компании Bimeister, эксперт в областях ТОиР и Надёжности.

Многие слышали словосочетание «Надёжность производства», сопровождающееся непонятными аббревиатурами RCM, RCA, FMECA, RBI и т.д. В одной из статей мы уже описывали, что это за процесс, можно посмотреть тут (Цифровые инструменты управления надежностью / Хабр (habr.com)).

А я расскажу вам более подробно о RCA (Root Cause Analysis) или простыми словами – методология анализа коренных и первопричин, или ещё проще методика проведения расследования отказов на производстве. Перейдём сразу к делу!

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем. В прошлых статьях мы описали сам подход, показали пути решения различных проблем. Со статьями можно ознакомиться здесь Часть1, Часть2, Часть 3. Сегодня мы поговорим о построении процесса развития сотрудников и команды в целом, а также о процессе управления инициативами.

Прежде всего, нам стоит понять сильные и слабые стороны каждого сотрудника подразделения. Начнём мы, безусловно, с hard skills, но и про софтскилы не будем забывать.

Всем привет! Меня зовут Алмаз. Я специалист по НСИ (нормативно-справочной информации) в компании Bimeister.

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

Python

Предыстория

Сейчас довольно много материала по данному языку программирования. Порой новичку очень сложно понять с чего начать и в какую сторону двигаться. По крайней мере для работы в инженерной области, найти что-то полезное для меня было не очень просто. Я начал изучать основы языка Python на Freecodecamp.org.

Всем привет, меня зовут Захаров Антон, и я DevOps-инженер в компании Bimeister! Весь свой опыт  я получил в этой компании, за 5 лет прошел путь от эникея до того, кем я работаю сейчас (большое спасибо коллегам!). Я расскажу, как на базе своих серверов и внутренних ресурсов мы создаем персональные стенды для разработки и тестирования нашего приложения.

«Инженерные данные в 21 веке» 

Привет друзья! Как можно было понять из заголовка статьи, речь пойдёт об управлении инженерными данными.  Цель - дать общий взгляд под новым углом. Статья выполнена по канонам постмодерна, пестрит отсылками и будет не только полезной, но и занимательной, коей и стоит быть статье на Хабре. Приведу реальные кейсы, в нужных местах дам определения и сошлюсь на стандарты, где уместно.

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

Объект данных – квант информации, который состоит из идентификатора и значений параметров. Объект данных обозначает реальный или абстрактный объект физического мира, в этом и есть его смысл. Так, на пример, 3D модель – это набор структурированных инженерных данных, содержит уникально идентифицированные объекты, с перечнем свойств, часть из которых передают пространственное расположение и геометрическую форму объектов. Документ (файл) как таковой тоже является объектом данных: у него есть идентификатор и перечень метаданных, описывающих его свойства. Однако сама техническая информация сконцентрирована не в заголовке файла, а в массиве файла. Если этот документ не таблица или база данных (БД) – то техническая информация в нём может быть отнесена к неструктурированным данным, хотя сам документ может при этом оставаться объектом данных.       

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

5 методик, которые необходимо использовать продуктовому дизайнеру в 24-м

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

Приветствую, читатели! Меня зовут Моисеев Андрей, в ИБэшечке  я уже в совокупности более 5 лет, а сейчас работаю DevSecOps в компании Bimeister. За время своей рабочей деятельности у меня получилось сформулировать некоторые полезные паттерны безопасности, которыми я хотел бы поделиться. Если вы наткнулись на эту статью, то вы явно неравнодушны к инфосеку и желаете преисполниться духом праведным, ну, а если попали сюда просто так, то как минимум сможете понять боль ваших коллег в данной сфере.

Всем привет, меня зовут Зуев Алексей, и я работаю DevOps-инженером в компании Bimeister! Сегодня я расскажу вам о том, как мы облегчаем жизнь нашим разработчикам и как разработчик может отследить состояние своего микросервиса в namespace Kubernetes. Основная цель этой статьи - описать, как мы пришли к дашборду для персональных стендов разработчиков.

Я много слышу от новых коллег, что у нас в компании классный онбординг, что это им легко, комфортно входить в процесс, нет стресса. А ещё внутри компании и команды аналитиков он работает классно, поэтому решила поделиться им.

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

Мой личный опыт онбординга тоже всегда начинался с того, что вот проект/продукт, вот команда, вот задача, греби. Мне приходилось самой искать людей, кто расскажет о системе, покажет кейсы. Чаще всего это были тестировщики, кстати. Приходилось искать документацию, вычитывать её, а сроки по задаче идут. Ещё из сложного в моём опыте онбординга — это угадать принятый в копании или отдельной команде формат оформления задач разработчикам. Часто майнинг такой информации — это поиск людей, кто может и готов рассказать, как надо, или метод проб и ошибок. Ещё из моего опыта: сложности на первых этапах были с узнаванием процессов. Где‑то они были описаны, но описание и реальность немного отличались, а где‑то процессы не были описаны совсем. Тогда так же приходилось пробиваться к знаниям самостоятельно. Выходило так, что выплываешь — молодец, а не выплываешь — увы.

Всем привет, меня зовут Никита, и я QA-инженер в компании Bimeister.

Мы помогаем промышленным предприятиям с цифровой трансформацией. Грубо говоря, помещаем завод с детализацией до каждой балки в окно браузера.

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

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

Для начала попробую описать суть проблемы. Представим, что у нас есть небольшое подразделение, не более 5 человек, которое как служба - одна на все команды разработки и тестирования. Количество обращающихся команд может быть от 10 до 20. Казалось бы – не мало ли людей на такое количество команд? Да, не много. А не хотим ли мы увеличить состав? Но реальность такова, что проблему обращений надо решить с помощью имеющихся в наличии ресурсов, а потом, разобравшись с ней и построив процесс работы с бэклогом команды и пониманием его объёма, уже запрашивать ресурсы на расширение команды. Пока этого нет, можем рассчитывать только на имеющиеся руки.