Привет, читатели Хабра!

Меня зовут Николай Усов, я работаю в отделе тестирования «Цифровой индустриальной платформы». В нашей команде в качестве системы управления тестированием программных продуктов используется Test IT. Система в целом нам нравится, претензий к функционалу почти совсем нет. Однако инструментарий Test IT не всегда позволяет настроить работу тестировщиков так, как удобно. Например, тот, кто с ней работал, знает, что при большом количестве тестов может быть затруднительным поддержание соответствия между автоматизированными и ручными тест-кейсами, если их слишком много. Плюс могут потребоваться иные методы расчета успешности автотестов или более простой интерфейс для удаленного просмотра статистики по прогонам. В этой статье я расскажу, как с помощью telegram-бота, работающего в связке с Test IT, мы сделали жизнь тестировщиков немного приятнее.

Всем привет! Меня зовут Ксения Непомнящая, я — технический писатель в команде Zyfra Mass & Energy Balance (Z-MEB) компании «Цифровая индустриальная платформа». Z-MEB — это продукт для предприятий добычи и переработки нефти, газа и руды, участвующий в программе импортозамещения. Сегодня предлагаю вам взглянуть на пользовательскую документацию как на путеводитель по продукту и рассмотреть ее роль в увеличении ценности продукта.

Понятный интерфейс как город с понятной планировкой и развитой инфраструктурой

Представим себе город с понятной планировкой и развитой инфраструктурой и рассмотрим два варианта взаимодействия с ним.

Всем привет! Меня зовут Елена Галата, в ГК "Цифра" я руковожу направлением разработки программного обеспечения. Хочу сегодня немного поговорить об информационной безопасности и о том, как она выглядит со стороны тех, кто имеет отношение к созданию ПО. Не только программистов, но и специалистов QA, аналитиков, продуктовиков и других. В этой статье я и хочу обсудить три важных вопроса: почему нам так важна безопасность, как она выглядит со стороны разработки, и куда двигаться дальше.

Меня зовут Юлия Седова, и я представляю команду технических писателей ГК «Цифра». В рамках масштабной работы по повышению качества документации мы столкнулись с проблемой отсутствия культуры предварительного планирования трудозатрат технического писателя. В этой статье я хочу поделиться нашим решением проблемы.

Всем привет! Тут уважаемые коллеги уже много раз писали о различных инструментах и технологиях платформы ZIIoT для работы с промышленными данными и создания приложений. Но как-то руки пока не доходили до одного из самых важных ее компонентов — единой объектной модели (ЕОМ). В этой статье я исправлю это недоразумение и расскажу, как реализована концепция ЕОМ у нас и как работает наш инструмент для графического конфигурирования моделей — Zyfra Graphic Object Designer. Меня, кстати, зовут Александр Пучков, я ведущий владелец продуктов в компании «Цифровая индустриальная платформа», которая занимается развитием отдельной модификации ZIIoT для нефтегазовой и нефтехимической отраслей – ZIIoT Oil&Gas – и приложений на ее основе.

Случается, что нам, техническим специалистам, нужно принять решение в пользу того или иного кандидата для найма в команду. Обычно мы делаем упор на технические знания и навыки и не слишком обременяем себя размышлениями о том, подходит ли подходящий нам по техническим компетенциям кандидат под уже сложившуюся модель взаимоотношений внутри коллектива и может/хочет ли он справляться с ролью, которую ему в этом коллективе предстоит играть. В этой статье, которую я назвал по мотивам известного альбома Pink Floyd, я хочу рассказать, как на собственном опыте убедился, что обременить себя этими размышлениями при найме специалистов не только полезно, но и необходимо. Можете считать это работой над ошибками.

Дисклеймер. Эта статья создана техническим специалистом, чтобы помочь таким же техническим специалистам выработать свой подход к найму персонала, а не HRом для HRов. Если что-то тут кажется очевидным для  HR-профи или написано недостаточно научно, то ну и ладно.

Всем привет! Меня зовут Сергей Лысов, я занимаюсь тестированием производительности платформы интернета вещей ZIIoT Oil&Gas. Если вы о ней еще не слышали, то велком сюда. А в этой статье я расскажу о том, как мы ускоряли и упрощали ее тестирование через автоматизацию контроля тестов и сборки  отчетов, а также внедрение изолированных тестов. Точнее — с чего мы этот путь начали и куда примерно движемся.

Переносимость процессоров и паттерны

Вот и обещанная третья часть саги о том, что в NiFi можно делать и как это делать правильно, без претензий на истину в последней инстанции, конечно. Сегодня расскажу о переносимости процессоров и дам несколько паттернов для самых популярных задач на платформе ZIIoT. Если вдруг вам интересно почитать про оптимизацию схем и производительности в NiFi — велком в первую часть. Если мечтаете узнать больше о мониторинге, то вторая часть — must read. Только потом сюда не забудьте вернуться.

Всем привет! Меня зовут Алексей Бакукин, я старший бизнес-аналитик в дивизионе «Цифровой завод» ГК «Цифра». Из названия понятно, что мы занимаемся проектами цифровизации заводов. Чаще всего эти проекты преследуют две цели:

1. Рост прибыли предприятия за счет уменьшения затрат или увеличения выхода продукции.

2. Упрощение процесса, автоматизация типовых действий (отчет, расчет, дашборд и так далее).

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

Бытует мнение, что главное — это реализация первой цели. Только вот если компания действительно ее хочет достичь, то второй целью жертвовать никак нельзя. Обычно, как изменится жизнь сотрудников с внедрением новой системы, объясняют через функционал этой системы. Но на мой взгляд, это не самое эффективное решение задачи. Лучше это делать через бизнес-процесс. Ниже объясню суть метода и почему так правильнее.

Мониторинг 

Продолжаем разговор о том, что в NiFi делать можно и нужно, а что можно, но лучше не стоит. Если вы пропустили первую часть разговора, то вам сюда. Там про улучшение читаемости схем и повышение производительности (ну почти). Здесь же пойдет речь о том, как проводить мониторинг бизнес-части схемы, чтобы всем было хорошо (ну или чтобы не было плохо), ну и немного о переносимости процессоров. Поехали!

Есть мнение, что хуже всего — не вести мониторинг бизнес-части схемы совсем, используя популярный подход «и так сойдет!». Но если подумать, есть одна вещь хуже отсутствия мониторинга — неправильный мониторинг.

Улучшаем читаемость схем и повышаем производительность

Всем нам (ну хорошо, большинству!) приходится иметь дело с Apache NiFi в качестве ETL-инструмента. У нас он используется для управления потоками данных в платформе ZIIoT (кому интересно, что это за зверь, можно почитать здесь). Apache NiFi — инструмент хороший, местами удобный, позволяет быстро решать задачи, в том числе и достаточно высокой сложности, не формируя для этого отдельную группу разработчиков. Однако, как правило, по ходу проекта условия этих задач меняются несколько раз, и нередко их решением на разных этапах занимаются разные люди в режиме аврала. И вот в результате мы видим НЕЧТО

Привет, Хабр! Меня зовут Илья, я — разработчик систем восприятия окружения в компании Zyfra Robotics. Проще говоря, я учу самосвалы и буровые станки «видеть» окружающий их мир. Наши роботы бурят скважины на просторах Перу, а самосвалы без водителей трудятся на карьерах Хакасии. Чтобы они могли делать это быстро и, главное, безопасно, мы наделяем машины «глазами» и учим ими пользоваться. Для этого мы применяем камеры, радары и, конечно, лидары. В этом посте я хочу рассказать, что это вообще такое и с какими проблемами мы сталкиваемся.

Всем привет! Недавно у нас в Группе компаний «Цифра» прошла очень крутая ежегодная внутренняя техническая конференция TechTalks. Мы настолько ей гордимся, что решили поделиться внутренней кухней с вами и рассказать про ивент через призму того, как мы его делаем.

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

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

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

Под "мы" здесь и далее имеются в виду я – Семён Косяченко – и мои коллеги Александр Подвойский и Александр Калиниченко. Вместе мы разрабатываем решения на основе ML для нефтегазовой отрасли в компании "Цифровая индустриальная платформа" (совместное предприятие ГК "Цифра" и "Газпром нефть").

Многие читатели «Хабра» имели опыт построения «умного дома» и, скорее всего, использовали для этого беспроводные устройства. Кто захочет портить квартиру/дом, особенно после ремонта, ворохом проводов? Но вот на заводе для решения подобных задач беспроводных датчиков вы вряд ли увидите. Мы в отделе аппаратной разработки компании «Цифра» решили это исправить и сделали беспроводное устройство для сбора промышленных данных. Зачем оно нам понадобилось и как мы его разрабатывали, расскажу под катом.

Привет, Хабр! Меня зовут Светлана Захарова, и это мой первый пост. Я работаю в команде внедрения ВИСТ, ГК «Цифра», а именно обеспечиваю жизненный цикл бюджетирования проектов нашей компании. Хочу поделиться своим опытом и сконцентрировать внимание заинтересованных читателей на некоторых деталях этого процесса. В этой статье речь пойдет о начальных этапах управления проектом – его бюджете, и, возможно, тема будет не столько интересна сообществу разработчиков, сколько руководителям проектов внедрения, которые, как ни удивительно, слишком часто проявляют некоторое легкомыслие при планировании. В дальнейших статьях я постараюсь рассмотреть более технические вопросы, связанные с интеграцией наших систем в единую систему управления проектами внедрения.

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

Прекрасные дамы и неподражаемые господа, здравствуйте.

Меня зовут Федор, я технический писатель компании «Цифровая индустриальная платформа». Это совместное предприятие ГК «Цифра» и ПАО «Газпром нефть».

Скажу вам по секрету – сразу хотел вам показать в тик-токовском стиле «10 крутых лайфхаков как писать текст», устроив из этого целый цикл статей/рубрику.

Однако меня скорректировали. Сказали, чтобы я начал с самых азов и представил свою профессию, прежде чем учить местных айтишников-учёных. Что же, без занудства и скукоты попытаюсь это сделать.

Всем привет. Меня зовут Семён. Я занимаюсь разработкой интеллектуальных приложений для нефтегазовой отрасли в компании «Цифра». В этой статье я и моя коллега Анна Тарасова расскажем, как мы искали решение для проблемы с прихватами при бурении нефтяных скважин с помощью машинного обучения и к чему в результате пришли.

Привет, Хабр! Ранее я писал о том, как можно подружить разработчика и писателя в рамках единого процесса и о подходе Docs-as-code к документированию разработки. Здесь мне бы хотелось поразмышлять, как в условиях agile и постоянного развития одновременно перестраивать документирование под требования других процессов, зачастую не очень предсказуемых, и при этом сохранить максимальную целостность, качество и единообразие документации.