Всем привет! Меня зовут Владислав Шиханов, я ведущий программист в CDEK. В этой статье я хочу рассказать о том, как мы пришли к проектированию и review плана разработки до начала реализации задачи, что это дало и как повлияло на скорость и качество разработки. Также поделюсь практическим руководством: как проектировать и проверять технический дизайн, чтобы это было быстро и удобно. Статья будет полезна разработчикам любой квалификации, но особенно тимлидам и менеджерам для внедрения практики в командах.

Всем привет. Меня зовут Ярослав Карманников, я разработчик команды SmartTV/Web в онлайн-кинотеатре KION МТС Digital. Это четвертая часть сериала, посвященного фиче Autoplay в нашем кинотеатре. Сегодня обсудим нюансы реализации фичи на платформе SmartTV: я расскажу о том, как мы внедряли автоплей, с какими трудностями столкнулись и как их решали.

Добро пожаловать под кат!

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

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

Что будет, если ввести этот элемент в вашу архитектуру? И почему это особенно актуально сейчас, когда так широко распространился микросервисный подход к проектированию систем? Обсудим это сегодня. Все подробности — под катом.

Мы знаем, что про код писать сложно, но хотим, чтобы посты с ним на Хабре становились всё лучше. Поэтому на ежегодном хабраконкурсе «Технотекст-2021» мы поддержали номинацию «Программирование». А ещё  создали коллекцию советов — как написать крутой пост про свой код и порадовать этим постом аудиторию. 

Мы пройдём по основным шагам работы с текстом и покажем, как работать с темой, форматом и структурой. Научим техноавторским приёмчикам. А в пример приведём посты из нашего блога — и отличные материалы участников «Технотекста-2021». 

Привет, Habr!

Вы или ваши близкие точно сталкиваетесь с тем, что раз в месяц нужно выйти на лестничную площадку, включить фонарик в телефоне и переписать показания счётчика электроэнергии, а ещё снять показания счётчиков воды, и, возможно, даже природного газа. Нашим коллегам из департамента недвижимости и эксплуатации приходится проделывать такое упражнение ежемесячно на 18 тысячах объектов! Поэтому у нас в команде Центра искусственного интеллекта (ЦИИ) Блока «Сервисы» появилась идея облегчить жизнь сервис-менеджера с помощью технологии Computer Vision (далее CV), как Optical Character Recognition (сокращённо — OCR).

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

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

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

Я расскажу об автоматической генерации ETL-кода, которая реализована в Сбере на примере одной из использующихся платформ. Поток трансформаций данных в нашем решении называется графом. Этот граф является ориентированным ациклическим графом (DAG, directed acyclic graph). Автоматическую генерацию графов оказалось возможно реализовать благодаря наличию специального инструмента spec-to-graph, который как раз для этого и предназначен. Он позволяет формировать трансформации графа согласно написанному коду, служащему шаблоном. В этом шаблоне указывается, какие трансформации с какими параметрами следует использовать и в каком порядке нужно их соединить. Мы используем подход по генерации графов из базовых субграфов (стандартизированных маленьких графов). Т.е. мы разбиваем ETL-процесс на элементарные операции, каждую из которых реализует некоторый базовый субграф. А из субграфов формируется итоговый граф, осуществляющий загрузку данных. Данные мы грузим из Hive в Hive, дополнительно используя промежуточные индексные структуры в HBase.

Прошло около полугода с момента выхода базовой модели ruDALL-E XL (1.3B), мы – команды Sber AI и SberDevices – получили много лайков и, как подобается таким разработкам, дизлайков. Всё хорошее отразилось в гигантском наплыве пользователей в первые недели релиза: порядка 800 тыс. уникальных пользователей (на текущий момент уже более 2 млн.), – 1.2k ⭐ в репозитории и последующем изрядном списке фантастических файнтюнов (Emojich XL, Surrealist XL, генератор кроссовок, генератор покемонов). Но если читатель обратится к прошлой статье, то обязательно вспомнит, что в ней речь шла о двух версиях модели: XL (1.3B) и XXL (12B). На достигнутом мы не остановились, поэтому, сделав релиз текущего на тот момент чекпоинта XXL на SberCloud, продолжили заниматься сбором данных и дообучением модели. И вот, наконец, мы готовы вывести её в свет.