Всем привет, меня зовут Захаров Антон, и я 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. Казалось бы – не мало ли людей на такое количество команд? Да, не много. А не хотим ли мы увеличить состав? Но реальность такова, что проблему обращений надо решить с помощью имеющихся в наличии ресурсов, а потом, разобравшись с ней и построив процесс работы с бэклогом команды и пониманием его объёма, уже запрашивать ресурсы на расширение команды. Пока этого нет, можем рассчитывать только на имеющиеся руки.

Представьте себе, что вы пытаетесь перевести строительные материалы для вашего дома мечты на обычной лодке, пусть даже с мотором из точки А в точку Б.  Хочется закончить работу как можно быстрее, и вы нагружаете лодку под завязку. Отплываете, и вдруг , из-за набежавшей волны,  лодка переворачивается. Или вы плывете, и видите на берегу нужные материалы, берете их, и опять та же история – лодка идет ко дну. Вы выживаете, но ваша лодка и все стройматериалы пропали. Можно ли их достать? Можно, но для этого потребуются совсем другие усилия. И если правильно рассчитать все с самого начала, история может сложиться совсем по-другому – вы сможете в срок привезти материалы и во время построить дом.

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

Одним из самых важных аспектов договора – это прояснение необходимого уровня детализации или  LOD (Level of Details). LOD часто неправильно понимают только как показатель связанный исключительно с 3D-моделью. Это понятие выходит за рамки простого внешнего вида здания и фокусировки на его композиции, функциях и вписывании в контекст проекта. Этот показатель охватывает широкий спектр данных, выходящих за рамки простой геометрии, включая атрибуты, спецификации, свойства материалов, данные о затратах и графики технического обслуживания. Причем, работа над заполнением атрибутивной информации занимает до 50% рабочего времени.

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

Первая проблема, с которой мы начнём - это тушение пожара в инфраструктуре.

Привет, привет!

Представлюсь: меня зовут Тамара, и я являюсь ведущим инженером по нормативно-справочной информации в компании Bimeister.

Начну с того, что это лишь малая часть той большой истории, которую я хочу вам рассказать.

Будет много вопросов типа «Что это?», «Для чего нужен?» и тд. Ищите ответы на эти вопросы ниже, я вам все объясню)

Чем же занимаемся мы, ребята из отдела разработки НСИ? Давайте попробую вам кратко рассказать:

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

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

Качественная база данных оборудования (БДО) является основой для построения системы автоматизации/цифровизации процессов Управления техническим обслуживанием и ремонтами (ТОиР). В процессе эксплуатации системы Управления ТОиР предприятиям постоянно требуется актуализация существующих аналитических справочников, составляющих БДО. Чтобы иметь возможность планировать ремонт или техническое обслуживание (ТО) любой конкретной обслуживаемой единицы оборудования, а также вести учет истории ремонтов и отказов (дефекты, параметры состояния, наработка, отказы), необходимо, чтобы эта единица была описана в информационной системе (паспортизирована).

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

Вопросы и аудитория

Прежде чем начинать рассказ, следует ответить на вопрос, чем внедрение “DevOps as service” может быть полезно для компании? Какую пользу это внедрение может принести? И что так же не маловажно – кому это будет полезно?

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

Меня зовут Канцедалов Дмитрий, я методолог отдела методологии и сопровождения проектов ООО «БИМЭЙСТЕР ИНЖИНИРИНГ». В этой статье опишу специфику KKS кодирования при создании ЦИМ. В качестве введения предлагаю ознакомиться с термином ЦИМ и типовыми работами в рамках создания ЦИМ.

В настоящее время всё актуальней становится вопрос использования цифровых информационных моделей (ЦИМ) при проектировании сложных производственных объектов. В приказе Минстроя РФ от 31.12.2020 №928/пр под ЦИМ объекта капитального строительства определяют совокупность взаимосвязанных инженерно-технических и инженерно-технологических данных об объекте капитального строительства, представленных в цифровом объектно-пространственном виде. По сути ЦИМ представляет собой объектно-ориентированную трехмерную модель, включающую в себя ряд характеристик (визуальные, физические, функциональные и пр.) объекта и отдельных его частей в виде совокупности взаимосвязанных информационных элементов. Стоит отметить особый интерес к цифровому проектированию со стороны государственных органов, что связано с курсом, обозначенным Правительством РФ, по цифровизации экономики – внедрением цифровых и информационно-коммуникационных технологий в экономику. А капитальное строительство как раз та отрасль, которая сильно влияет на рынок труда, развитие экономики страны в целом и конкурентоспособность на международном рынке.

При создании ЦИМ Объекта методику кодирования KKS необходимо адаптировать как под специфику моделируемого объекта, так и с учётом проектируемой, либо существующей IT-системы Объекта. Детальная проработка методики KKS кодирования, основные концепции которой представлены в статье, обеспечит корректную взаимосвязь БДО-3D-2D-технический архив.

Технологии — ничто. Что действительно изначально важно и очень правильно — это вера в людей. Дайте им инструменты, и с помощью них они смогут сотворить нечто прекрасное. © Стив Джобс

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

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

Что такое надежность

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

Поэтому начнем знакомство с занимательным миром под названием «Надежность» с классического определения данного термина по ГОСТ Р 27.102–2021:

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

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

Всем привет, Меня зовут Олег и я .NET разработчик в компании Bimeister. Я хотел поделиться своим интересным опытом по связи проекта на ASP.NET Core Web App с использованием IAsyncEnumerable коллекций и современного фронт-енд SPA приложения на Typescript.и Vue.js 3 версии.

Все эти технологии не новы и, на самом деле, фреймворк и технологии для веб части могут быть любые на ваш вкус: Angular, или React, или что-либо еще. Весь интерес представляет собой именно унификация процесса обмена с бэкендом на C# с современной асинхронной коллекцией. Я не буду заострять внимание на структуре обеих половин приложения подробно, скажу лишь, что использовал один из сложившихся в моей практики шаблонов для запуска  ASP.NET Core Web приложения с SPA. Все детали можно будет посмотреть в приложенном репозитории.

Всем, привет! Меня зовут Алёна Барыкина и я методолог отдела информационного моделирования департамента цифровизации инвестиционно-строительных проектов компании "Bimeister". И сегодня, хочу с вами поделиться важным аспектом исполнения желаний в проектной деятельности с использованием цифрового информационного моделирования

Вы, конечно же, знаете ключевой принцип успеха любого проекта, включая создания цифровой информационной модели (ЦИМ) - «Начинай только тогда, когда результат уже в уме». Выражение, которое отражает саму суть любой проектной деятельности.

Только вот вопрос - а что каждый участник процесса понимает под необходимым результатом в проекте создания цифровой информационной модели?

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

Когда Заказчик говорит, что ему нужна цифровая информационная модель, он говорит не просто о модели, а о преимуществах, которые он хочет получить с помощью ЦИМ:

Данная статья написана, чтобы помочь рядовым пользователям правильно использовать ChatGPT. В ней раскрываются тонкости устройства больших языковых моделей. А если вы разбираетесь в том, как всё работает, то не тратьте время и листайте ленту дальше!

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

Всем привет, я Карим Аминов, Head of QA в компании Test IT. Компания является частью одного холдинга Yoonion, который объединяет под общим брендом цифровые продукты для удобства работы бизнеса. Наши команды разработали два известных инструмента - это Test IT и TeamStorm.

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

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

Всем привет! Меня зовут Евгений, я backend‑разработчик в компании Bimeister. Сегодня я хотел бы продолжить рассказ о нашем 3D движке Spatium. В статье речь пойдет еще об одном из алгоритмов оптимизации - поиске и удалении избыточных вершин из 3D моделей.

Материал может представлять интерес для инженеров, связанных с проектированием и разработкой в области 3D.

Добрый день! Меня зовут Александр и я С# разработчик в компании Bimeister!

Данная статья предназначена для людей, применяющих или планирующих применять полнотекстовый поиск по объектам в БД PostgreSQL, а также для тех кто хотел бы оценить скорость поиска при использовании встроенных механизмов PostgreSQL для различных объемов данных.