(фото из зарубежного проекта вместо текущего по просьбе безопасников)

До этого в России были внедрения электронных ценников в рознице (МАН, Магнит и так далее), но использовались устройства без сетевой связности, то есть нужно было ходить и обновлять их с помощью программатора либо выставлять на них цену кнопками, как на электронных часах. Плюс прошлые поколения ценников были с жидкокристаллическими дисплеями и суровым bluetooth, а новые — с e-ink и сильно переделанной версией IEEE 802.15.4 с поддержкой сна и невероятно экономичных по питанию транзакций. То есть прошлым надо было менять батарею раз в три-семь дней, а новые уже держат два года (по заявлению производителя, пока не было шанса проверить, но аналогичные устройства LORA мы начали использовать лет десять назад, и один-два года похоже на правду), причём год — это в секции холодильников, где аккумуляторы должны чувствовать себя зябко.

Собственно, я участвовал в одном из первых в России аналогичном проекте и потому хорошо представляю тот ад, который тогда творился. КРОК 15 лет занимается розницей, и мои коллеги тоже знают, что первые модели были, скорее, прототипами. Но всё равно даже те электронные ценники были лучше, чем резать бумагу и наклеивать скотчем с точки зрения скорости обновления цен в магазине после пересчёта базы на 300-400 позиций за ночь.

Новые ценники имеют управляющий сервер, который обновляет ценники мгновенно, как только в 1С или SAP поменялись цены. Точнее, лаг есть — он равен промежутку между сеансами связи оконечных устройств, но это не больше нескольких минут. Каждый ценник привязан к конкретному товару в базе и на полке.

Пока «накрыто» два крупных магазина федеральной розничной сети, там 79 тысяч ценников. Если этот проект проживёт полгода успешно, через год ждите такое почти по всей России — и наконец-то пропадут проблемы про «мы не успели переклеить» и «акция уже кончилась». Но, возможно, будут новые с тем, что в 18:30 алкоголь будет дороже, чем в 7:00.

Хабр, привет! Меня зовут Ася, я ведущий инженер-тестировщик (QA Lead) в КРОК.

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

Про профессию тестировщика часто слышу, что это самый легкий и быстрый порог входа в ИТ — а там и на разработчика переучиться можно. Я же наоборот — училась на разработчика и даже успела им немного поработать, но душа к этому не лежала, потому что искать баги намного веселее. За всю мою карьеру я участвовала в совершенно разнообразных проектах: документооборот, файлообменники, статистические наблюдения, обработка обращений пассажиров в ЦППК, учет оборудования. А потом поняла, что этот опыт можно масштабировать на свою жизнь и даже на работу целого департамента. Так я стала агентом изменений департамента разработки программного обеспечения (ДРПО).

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

Привет, Хабр! Я Маша, старший инженер-разработчик iOS в КРОК и аспирант на кафедре Прикладной математики и Искусственного интеллекта в московском вузе. А еще я уже четыре года преподаю. Два года назад мы с коллегами с кафедры, преимущественно аспирантами, основали кружок спортивного программирования, который вырос в большое IT-коммьюнити в стенах универа, где мы делимся разного рода знаниями со студентами.

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

Первый ужас я испытала на первом же занятии со студентами. Одна группа не могла привести ДНФ в КНФ, другая — не смогла даже общим усилием воли вспомнить таблицу истинности для конъюнкции и дизъюнкции. Третья — не понимала как программно устроены списки (это у нас проходят годом ранее). А потом я вспомнила себя — про мой курс преподы говорили то же самое. И про курсы до нас, и про курсы после меня. И школьную учительницу Ольгу Николаевну вспомнила: «В этом году класс еще слабее, чем в прошлом — если так пойдет и дальше, вернемся к жизни на деревьях!». В школе мне казалось, что это такой изощренный педагогический прием, который должен подхлестнуть нас учиться усерднее чтобы «доказать, что мы лучше чем кажется». Ошибалась.

Решили мы с коллегами порефлексировать — а почему так происходит? Результаты, наши грабли и опасные эксперименты с тигром под катом!

Похоже, власти прислушались к жалобам бизнеса на неудобные законы и приняли закон об экспериментальных правовых режимах в сфере цифровых инноваций (Федеральный закон от 31.07.2020 № 258-ФЗ). По сути государство говорит нам: «Вам не нравится действующее регулирование? Окей, придумайте свои законы, которые вас устроят. Мы на время сделаем их обязательными для вас и других желающих и посмотрим, как они работают. Если эксперимент пройдет хорошо, то сделаем из вашей идеи полноценный закон, обязательный для всех».

Давайте рассмотрим, кому от нового закона станет удобнее и в чем его особенности.

Поехали!

Привет, Хабр! XR-разработкой я занимаюсь около семи лет: проделал путь от младшего специалиста до директора бизнес-юнита КРОК Иммерсивные технологии. Моя команда уже более пяти лет создает XR-продукты для промышленности. За это время наш небольшой отдел превратился в целое направление в ИТ-компании, создав проекты для таких гигантов, как Saudi Aramco, «Сибур», «Газпром нефть», «Росатом», «Норникель», «Мособлгаз» и других российских и международных компаний. А в прошлом году наша копилка успешных кейсов пополнилась образовательным проектом в Бахрейне. В этой статье я расскажу, как мы обучили арабских студентов VR и AR-разработке всего за пять месяцев, научили их вести проект заказчика под ключ. Забегая вперед, скажу, что некоторые выпускники даже получили работу по этой специальности.

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

Первый совет — хватит доставать своих людей!



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


Дятел-менеджмент в чистом виде

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

Карта полёта, отмечены точки с концентрацией метана свыше 3 000 ppm*m. И это много!

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

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

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

Услуга автоматизированного замера уровня метана с помощью дронов очень востребована в Европе.

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

Привет!

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

С другой стороны, частые переговоры означают много поездок. Иногда везёт. Вот в Дубае выходные пятница и суббота, а воскресенье — рабочий. При этом рейсы на воскресенье дорогие, и куда выгоднее лететь в пятницу. Встреча по поводу наших разработок по машинному зрению для дронов была на воскресенье, и когда наш переговорщик прилетел, заказчик извинился и сказал, что не получается, и нужно перенести ещё на пару дней. Так у него получились незапланированные выходные. Ну а дальше он закономерно вышел на пляж и уснул. После чего всем говорил, что сгорел на работе. Но интересно не это: дело в том, что ещё один наш коллега как раз застрял посреди тундры. Это примерно два часа вертолётом от Нового Уренгоя, и, кроме вертолёта, там транспорта нет. У него была метель — и, как следствие, нелётная погода. Он прибыл, обследовал талевые канаты и не смог вылететь. К началу истории уже сидел там два дня. Синоптики обещали открыть площадку только ещё через три дня. Из развлечений у него там была еда в столовой на месторождении, настольный теннис с вахтовиками и SMS на телефоне. Вот они друг другу и жаловались, кто и где застрял.

Иногда бывает так:

— Приезжайте, у нас упало. Если сейчас не поднять — покажут по телевизору.

И мы едем. Ночью. На другой край страны.


Ситуация, когда не повезло: на графике показан резкий рост нагрузки на СУБД. Очень часто это первое, на что смотрят администраторы системы и это первый признак того, что наступила жопа

Но чаще речь идёт про какие-то типовые вещи. Например, заказчик столкнулся с низкой производительностью системы документооборота. По понедельникам и вторникам система падала, они перезагружали сервер, и потом всё поднималось. Захлёбывалась база данных. Хотели докупить оборудования (что долго и дорого), позвали нас просчитать смету. Мы им посчитали смету и заодно предложили разобраться, что же именно тормозит. За три-четыре часа локализовали источник проблемы. Выяснили, что это медленные запросы в базу данных и неоптимальные схемы индексирования. Создали недостающие индексы, поковырялись с оптимизатором запросов в Оракле, некоторые проблемы потребовали изменения кода — поменяли условия поиска (без изменения функциональности), заменили часть запросов на использование предрассчитанных представлений. Если бы у них был нормальный человек по БД — могли бы сделать то же и сами. Но вместо нормального человека был аудит базы данных раз в полгода крутыми ораклистами — они выдавали общие рекомендации по настройкам и железу.

Запустив наше облако, мы стали предоставлять сервис хранения, аналогичный S3 Амазона (с совместимым API, чтобы российские заказчики могли использовать стандартные клиенты для работы с S3, изменив только endpoint для подключения). Основная задача сервиса — хранение снапшотов виртуальных машин и различных файлов клиентов. Амазон был взят за образец, куда надо развиваться, и в начале 2014 года стало понятно, что имеющееся файловое хранилище устарело, заказчики требовали современных фичей, недоступных у нас и так нравящихся им у AWS. Но доработка существующего решения светила огромными трудозатратами, поэтому было принято решение построить новое S3-совместимое хранилище с нуля.

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

Это было чертовски долго, но всё прошло спокойно.