Всем привет!

Меня зовут Марина, я инженер по нормативно-справочной информации (НСИ) компании Bimeister. Наш отдел занимается формированием баз данных оборудования (БДО) и баз данных нормативов (БДН) для создания цифровых моделей производственных активов в ПО Бимейстер.

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

Работа сложная, требующая внимания, терпения и времени. Много различных процессов и этапов.

Мы находимся в постоянном поиске вариантов оптимизации текущих процессов формирования НСИ.

Летом 2022 года в нашей компании прошла серия митапов на тему «Система менеджмента качества и моделирование бизнес процессов». Тема заинтересовала меня потому, что давно были идеи по улучшению рабочих процессов и я решила поучаствовать. После интенсива и обучения я овладела навыками моделирования бизнес-процессов (БП) в нотации BPMN 2.0. При моделировании рабочих процессов и их анализе была предложена оптимизация некоторых из-них.

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

«Разработка по Agile» не предполагает точных сроков реализации функциональности, но каждому владельцу продукта прилетает в неделю сотни «А когда будет готово...?». Даже когда продукт находится на этапе погружения команды в бизнес‑контекст и не завершены исследования, требуется определить сроки выхода MVP, ведь продукт или фича нужны «вчера» и важность стратегического планирования на квартал или год никто не отменял. Рассмотрим ситуацию, когда продукт не находится на ПРОДе и нет точного состава MVP.

Цель статьи — рассказать об оценке бэклога в полной неопределенности.

Прежде, чем выдвигать гипотезы по срокам, важно сделать ряд «приседаний» с командой после дискавери‑фазы: это декомпозировать продукт на фичи, определить MVP, составить USM и только потом с видением продукта приходить к архитекторам и команде, чтобы обсудить не просто оценки, а реализацию и зависимости. Здесь сталкиваемся с рядом проблем задач, например, если команда оценивает бэклог в SP, что невозможно и не правильно переводить в человеко‑дни, а положить SP на календарный график и диаграмму Ганта нереально (подробнее о SP туточки) или есть зависимости от фичей смежных команд и сроки их реализации еще неизвестны, или архитектура еще не готова и остается только выдвигать гипотезы, как будет реализовано. Вот здесь начинается интересный квест.

Владелец продукта вместе с командой разработки могут выбрать такой вариант: оценить риски, заложить время на дополнительные исследования и еще что‑нибудь — в таком случае мы окажемся с MVP через год‑два, что не подойдет никому. И ведь одной из важных задач продакта — это урезать функциональность на MVP по всем канонам и сделать быстро/дешево. В связи с этим рассмотрим шаги для проведения первичной оценки, когда есть понимание функциональности, но еще не проведен подробный бизнес‑анализ. Забегая вперед, это не «красная таблетка» и эти шаги не спасут от возможных изменений состава MVP, переприоритезации или влетающих новых важных задач. Ниже описанные шаги дают вектор движения и помогают сформировать ответ на вопрос «Когда?», не скатываясь в Waterfall.

Вне зависимости от методологии разработки ПО, каждая команда сталкивается с этапом планирования и оценки задач. Есть те, кто привык оперировать человекочасами и человекоднями, есть те, кто уверовал в мощь и эффективность оценок в абстрактных величинах, таких как Story Points (далее SP). У этой статьи нет цели доказать превосходство одного подхода к оценке над другим. В ней речь пойдет об истории одной команды, которая пожила четыре спринта с оценками в часах, перешла на SP, а спустя девять спринтов подумывает о том, не вернуться ли к первому подходу.

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

Привет! Меня зовут Мацкевич Евгений, я бекэнд-разработчик 3D-движка компании «Бимейстер». Хоть это и не очевидно на первый взгляд, но элементы загружаемых пользователями 3D-моделей зачастую повторяются, имея при этом различные положение в пространстве, масштабирование и вращение. Я расскажу о том, как мы научили нашу систему распознавать такие элементы как «одинаковые», выделять из них уникальный, а для остальных – вычислять матрицы трансформации. Это дало возможность однократно загружать уникальный элемент, а вместо прочих одинаковых – их матрицы, что сократило трафик и объем занимаемой оперативной памяти.

Логирование бывает разным.

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

При автоматизации E2E тестирования часто приходится писать много тестов для проверки определённого поведения, например, валидация числового инпута. Один из способов — дублировать метод и изменить значения параметров, но при большом количестве тестовых данных дублирующего кода может быть очень много, а еще такие тесты сложно поддерживать. Но есть способ проще, его идея заключается в создании параметризованного теста таким образом, чтобы один метод теста мог быть использован для выполнения N тестов со всеми тестовыми данными.

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

Всем привет!

Меня зовут Андрей Таболин, я системный аналитик в компании Bimeister.

Casbin – одна из популярных библиотек для построения авторизации в веб-сервисах. В этой статье расскажу, как я тестировал Casbin, попутно подготовил своё решение для сравнения и покажу результаты работы обоих. Тестировалась в первую очередь эффективность работы с СУБД на разных объёмах данных для ролевой модели доступа (RBAC). Использовал: Node.js + PostgreSQL.

Всем привет, меня зовут Денис, я Software Developer Engineer in Test (SDET) в компании Bimeister. Я занимаюсь разработкой софта для тестирования — это фреймворки, автоматизированные тесты, настройка CI Pipeline’ов и многое другое.

В статье расскажу, как мы победили исключение Stale Element Reference Exception при разработке нашего фреймворка, используя Selenium WebDriver и C#.

Мы в Bimeister любим процессы.

А за что ж их не любить, в самом деле? Хорошо отлаженный процесс создает эффект «оно само»: каждый его участник в любой момент времени точно знает, что и в каком порядке ему нужно делать. За его ходом достаточно приглядывать и иногда нежно подталкивать, если кто-то забуксовал.

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

Привет тебе, читатель Хабра! Я Маша Демченко, системный аналитик компании Bimeister, и в своей первой статье я хочу рассказать о нашем опыте выявления и преодоления сложностей в процессе согласования требований к ПО.

Всем привет, меня зовут Сергей, я системный архитектор в компании BIMeister, и, как вы уже догадались, сегодня мы поговорим про маппинг объектов в .net

Мы сравним несколько популярных подходов и библиотек для маппинга, дадим общее представление и посмотрим на различия, которые стоит учитывать при выборе инструментов. Статья ориентирована на младших разработчиков, которые впервые сталкиваются с темой маппинга объектов и на всех неравнодушных. В данной статье мы не будем касаться широкой темы разнообразных ОRМ-ов (Object­Relational Mapping), а также темы сериализации/десериализации данных, которую тоже часто называют маппингом, а рассмотрим сопоставление объектов между различными слоями нашего приложения, например DТО (Data Transfer Object) и объектом из базы данных, с которым оперирует Entity Framework

Меня зовут Михаил Кириченко. Я разрабатываю клиентскую часть в компании Bimeister.

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

Всем привет! Меня зовут Хусрав, я бэкенд разработчик в компании Bimeister.

В этой статье я бы хотел бы поговорить о способе поиска родительских и дочерних элементов структуры посредством PostgreSQL Materialized Path.

Статья является вводной и рассчитана на людей, незнакомых с темой.

Ваше ПО проходит путь от MVP до Enterprise платформы? Атомарных тест-кейсов (ТК) оказывается слишком много, их поддержка становится дорогой с точки зрения времени и ресурсов? Возможное решение  — объединять несколько близких ТК в один и автоматизировать результат. В свою очередь, автоматизация обобщенного ТК невозможна без сохранения промежуточных состояний.

Под катом рассмотрим способы сохранения промежуточных состояний и проверим каждый из них на соответствие «лучшим практикам» автотестирования.

Всем привет!

Меня зовут Андрей Голяков, я руководитель бэкенд разработки компании Bimeister.

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

В этом посте хочу поделиться своими рассуждениями об этой задаче. Бóльшая часть текста родилась в рамках внутренней переписки с коллегами, так что не без «каминг-аута».

Цель статьи — посредством публикации упорядочить свои мысли на тему продвижения бренда посредством публикаций.

Всем привет! Меня зовут Пантелеев Александр и я бекенд разработчик в компании Bimeister. Постараюсь описать исчерпывающе, кратко и понятно суть основных паттернов хранения деревьев в реляционных базах данных. Надеюсь, что статья будет полезна тем, кто до сего момента не сталкивался с такими паттернами, и станет отправной точкой в их понимании.

Привет, меня зовут Андрей Голяков, я руководитель бэкенд разработки компании Бимейстер.

Хочу поделиться опытом быстрого подсвечивания возможных проблемных зон объёмного и малознакомого кода.

Рад приветствовать читателей Хабр. Меня зовут Азамат Акчурин, я QA инженер в Bimeister.
Часто при приемке разного рода фич нам, тестировщикам, не хватает сущностей/данных в тестируемой системе. Тестировать на пустых данных не “comme il faut”, поэтому, чтобы наполнить систему данными, мы можем обратиться к разработчикам, QA automation, добавить данные в БД и т. д. — способов очень много.

И сегодня я расскажу про один из таких способов, который "дешево и сердито" позволит тестировщику самостоятельно, не отвлекая других сотрудников, заполнить систему данными.
Все, что нам нужно
1. Установить Python.
2. Установить IDE для Python — лично пользуюсь PyCharm.
3. Дочитать эту статью, чтобы научиться применять такой способ в решении задач.

N.B.
В данной статье опущу пункты установки Python и IDE — будем считать, что они уже установлены. Перейдем, непосредственно, к практике.

Neo4j без преувеличения является самой распространенной графовой базой данных. Подход «schema free», гибкий язык запросов «cypher» — познакомиться с ней стоит хотя бы для расширения кругозора. Мы в компании Bimeister с целью повышения производительности провели серию экспериментов по переезду на Neo4j. Под катом я рассмотрю одну из сторон возможного апгрейда — импорт данных в графовую БД, проведу оценку ее преимуществ и недостатков и оценю время загрузки каждым из способов.

Хей йо, Хабр! Меня зовут Королёв Николай. Я инженер-конструктор компании BIMeister и при этом успеваю доучиваться в Московском Политехническом Университете на факультете машиностроения. Наш отдел разрабатывает высокодетализированные 3D модели для крупнейших компаний на рынке, к примеру, Газпром, а также внедряет BIM технологии в объектные модели.

Сегодня я расскажу, что такое САПР системы и для чего нужны BIM технологии.