Привет, Хабр! Меня зовут Толя, я лидер компетенции Java в Цифровом СИБУРе. Наш прошлый материал о Docker собрал классный фидбэк, поэтому мы решили развить тему и подготовить ещё несколько статей, двигаясь от простого к сложному.

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

В 2020 году мы рассказали о нашем продукте «Удалённый эксперт AR» — платформа для дистанционного обслуживания и ремонта оборудования, а теперь рассказываем, как он обрастает новым функционалом. Передаем слово Алле Емец, бизнес-аналитику Индустрии 4.0 Цифрового СИБУРа.

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

К вашему вниманию «ВидеоСОП» — платформа с видеоинструкциями, оптимизированная для работы со специализированными мобильными устройствами, которая даёт возможность пользователю перейти к набору видеоинструкций, отсканировав QR-код на объекте.

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

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

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

Можно, конечно, попытаться обойтись и без машинного обучения. Самый простой подход — проанализировать данные и составить понятный набор правил формата if-else (если-то). Между прочим, это применяется в реальной жизни, например, при анализе потребительской корзины. Составляется набор ассоциативных правил вида {хлеб, чай} → {молоко}. Это означает, что если покупатель приобретает хлеб и чай, то, скорее всего, он также купит молоко. Вуаля — мы сделали прогноз на будущее. 

Культовый разработчик Кент Бек сформулировал принципы написания ПО, которые в вольном изложении звучат приблизительно так:

1. Заставь код работать.
2. Сделай его понятным.
3. Оптимизируй для лучшей производительности.

Этим основам не один десяток лет, однако джуны (да и старшие порой, будем честны:) спотыкаются уже на втором шаге. В результате получается рабочий, но нечитаемый код, который не просто трудно понять — его нельзя дополнить или исправить, не поломав программу.

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

Сгустили мы тучи, однако. Но всё же, как писать понятный код с первого раза? Рассказываем в материале!

Привет, Хабр! С вами снова Юра, тот самый «цифровик» с завода СИБУРа. С момента моего предыдущего рассказа прошло полгода, и несмотря на описанный мной суровый сибирский контекст, я всё ещё жив, здоров и счастлив. И даже дополз пришёл к вам с охапкой новых рассказов.

Привет, Хабр! Меня зовут Катя Муличева, я тестировщица в СИБУР Диджитал (на фото не я).  За 4 года в профессии я успела попробовать различные виды тестирования и в этом материале хочу описать свой опыт тестирования систем с использованием датчиков интернета вещей.

Когда я впервые с ними столкнулась, я понятия не имела, с чего начать, - незнакомо было примерно всё. Поэтому в материале тема объясняется «на пальцах», ровно так, как я и хотела бы её получить в начале своего пути. Надеюсь, он окажется для вас полезным!

В первой части очень кратко разберёмся с теорией, а во второй посмотрим, что с ней происходит на практике.

Всем привет! Меня зовут Юстина Цига, и я владелец продукта IIoT в Цифровом СИБУРе.

Полтора года назад я стала единственным продактом на проекте и прошла от стадии воодушевления и горящих глаз до осознания, что я не справляюсь.

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

Всем привет!

Недавно мы запустили бота, в котором воплощён образ Дмитрия Менделеева (очень важная личность для СИБУРа), в том числе внешность. Он может всякое. Например, рассказывать факты из области химии и науки, отвечать на любой рабочий вопрос и подсказывать правильное решение, рассказывать о СИБУРе и карьере в компании, помогать новым сотрудникам для адаптации — в общем, хороший инструмент для HR-целей.

Сосредоточимся на том, как он устроен внутри.

Тестирование — необязательный этап разработки? Зачем подключать QA к планированию? И неужели люди правда выпускают продукты с дефектами?

Меня зовут Наталья Мурашова, я Senior QA Engineer, тренер по теории, процессам и автоматизации тестирования. Сегодня разберём, что такое тестирование, зачем оно нужно, и как работают тестировщики у нас в СИБУР Диджитал.

Всем привет! Меня зовут Катя Муличева, я тестировщица в СИБУР Диджитал. Последние два года я пишу автотесты для gRPC на Kotlin. Получив опыт, я захотела написать статью, которая очень пригодилась бы мне самой, когда я только начинала разбираться с gRPC. Надеюсь, вы найдете её полезной для себя!

Привет! Меня зовут Александр Апазиди, я руковожу в СИБУРе цифровизацией процессов головного офиса.

Сегодня я расскажу, как мы приводили IT-проекты в огромном нефтегазохимическом холдинге к одной модели, пытались примирить Agile и Waterfall, да и в целом, ускорить выполнение проектов.

С 2020 по 2022 количество наших IT-проектов увеличилось с 70 до 220, так что тема ухабистая. Приятного чтения!

Представьте себе команду, которая пишет F2P-игру для мобильников. Даже если это инди-проект из трёх человек, в этой команде всё равно будут разработчики, тестировщики и хоть кто-то ответственный за инфобезопасность. И, допустим, в команде хаос.

Разрабы долго ждут обратную связь от QA, половина документации нечитабельна, в Git пропала версия кода, до которой очень нужно откатиться прямо сейчас, потому что в новой всё поломалось в проде и надо вернуть как было… Ещё и вся команда в ссоре и ни один дейли не проходит без скандала. Как вы думаете, быстро ли эта игра дойдёт до рынка?

Это, конечно, драматическое преувеличение, но для решения таких проблем и нужны DevOps-практики.

Привет, Хабр! Меня зовут Анатолий Саблин, я java-разработчик и техлид команды эксплуатации в СИБУР Диджитал. Сегодня я расскажу про сложности, которые возникают на этапе эксплуатации продукта, как они влияют на работоспособность, и как их решить. И особенно рассмотрю:

●      Что важно в разработке программного продукта помимо самого кода;

●      Как сделать релиз и не сломать прод;

●      Какая модель работы больше подходит для промышленной эксплуатации.

По легенде, во время премьеры первого в истории человечества фильма «Прибытие поезда на вокзал Ла-Сьота» зрители устроили панику — они решили, что поезд настоящий и движется прямо на них. Больше века спустя на поезда смотрят нейросети — и даже принимают 3D-модели вагонов за реальные.

Я Никита Каменев, видеоаналитик СИБУР Диджитал. Сегодня расскажу, как мы учили нейросеть распознавать прибытие поезда на 3D-моделях из Unreal Engine.

У нас в индустрии есть распространённый мем: мол, есть стандартный офисный IT, а есть тяжёлый диджитал. И «тяжёлый» —  это не про нагрузку, а про общий сеттинг.

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

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

Приятного чтения!

Привет, Хабр! Я Саша Сосновский, разработчик направления «Индустрия 4.0».

Сегодня я расскажу про МАКАРа. Это такая аббревиатура для «Мобильного автоматизированного комплекса аудита работ». А за сложным названием скрывается мобильный вариант «умных камер» с вычислительным модулем и аккумулятором. Казалось бы, простое решение, но может и жизни спасать.

Подробнее о рождении МАКАРа и его пути к успеху – под катом. Приятного чтения!

Какую рекламу показать пользователю, красную или синюю?

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

Но как узнать, какой из баннеров имеет наибольший уровень кликабельности?

Чаще всего для ответа на этот вопрос используется A/B-тестирование. Группа пользователей разделяется пополам, и первой части показывают один баннер, а второй — другой. После этого можно вычислить уровень кликабельности и выбрать лучший из вариантов.

Предположим, что в конце A/B-тестирования у вас получились следующие результаты:

Привет! СИБУР — не просто одна из крупнейших нефтехимических компаний мира, это в принципе довольно большая компания с кучей разных процессов, множеством людей (как штатных специалистов, так и постоянных внешних подрядчиков). А еще — с большим количеством разных продуктовых команд, которые трансформируются, масштабируются, обмениваются разработчиками и аналитиками, в общем, всё это весьма динамично, быстро и всегда затачивается под конкретную задачу.

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

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

Под катом:

• как устроено взаимодействие между командами;

• что ждет новичка, пришедшего работать в СИБУР;

• какие есть пути развития карьеры в целом и своих навыков в частности;

• почему круто, когда разраб может просто приехать на завод и лично посмотреть, кто пользуется его продуктом;

• почему у тестировщика в целях вполне себе может быть конверсия интернет-магазина (и это нормально);

• почему B2B-рынок интереснее, чем пресытившийся B2C.

Привет! Меня зовут Олег, в IT я около 8 лет, и попал в отрасль тогда, когда начинался хайп вокруг гибких методологий разработки на российском рынке. Так что у меня была возможность своими глазами посмотреть, к чему все это привело в больших компаниях.

Кроме того, гибкие методологии разработки способствовали развитию инженерных практик.

Сейчас ситуация такова, что инженерных практик и инструментов существует очень много. Главный вопрос тут — зачем их внедрять и стоит ли их внедрять просто ради внедрения?

Вот, к примеру, набор из уже имеющихся практик и инструментов. Начинает напоминать какой-то зоопарк: