Технотекст

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

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

Привет, Хабр! На связи участница профессионального сообщества NTA Марина Коробова.

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

Одной из главных проблем, с которыми сталкиваются компании, это непосредственная работа с базами данных с помощью языка SQL (Structured Query Language). Не все знают этот язык, и не у всех есть время изучать его. Поэтому на рынке появляются инструменты, позволяющие писать запрос на естественном языке и получать ответ на языке запросов.

В посте познакомлю вас с двумя AI-инструментами для генерации SQL-запросов: SQLCoder Defog и SQLthroughAI.

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

На связи участник профессионального сообщества NTA Кухтенко Андрей.

В интернете постоянно что-то рекомендуют: посмотреть новое видео, добавить друга или купить товар. Как работают эти алгоритмы, расскажу в посте ниже и реализую рекомендательную систему с помощью графов.

Привет, Хабр! На связи участница профессионального сообщества NTA Александра Грушина.

Поговорим о важности написания тестов к своему коду, о магии подхода test-driven development. Я расскажу о своём пути: от первого знакомства с концепцией TDD до умелого использования инструментов тестирования на Java (Junit 5 + Mockito).

Привет Хабр!

Сегодня с вами участники профессионального сообщества NTA Пётр Хрущёв.

Как прочитать файл Excel, если он напоминает монстра Франкенштейна? Как склеить множество таких файлов в единый датасет и обработать их, не потеряв ни одной ячейки? Это и многое другое, включая подробности разработки нового инструмента — найдёте в посте.

В М2 большой объём письменной коммуникации с клиентами. Это и ответы на общие вопросы — о компании, процессах подбора и покупки недвижимости, — и обсуждение конкретных деталей запущенных сделок. К примеру, клиенты хотят знать, в каком отделении банка они будут подписывать документы, пришли ли деньги продавцу, прошёл ли объект недвижимости проверки перед продажей.

Работа с вопросами происходит в тикет-системе клиентской поддержки (UseDesk). Для каждого вопроса через любой канал коммуникации (e-mail, мессенджеры, чат на сайте) заводится обращение, и сотрудник экспертной поддержки отвечает на него с определённым SLA. 

Для оптимизации работы с обращениями процесс разделён на 3 линии поддержки. Первая линия отвечает только на вопросы без привязки к продукту и не знает о конкретных сделках. Она обрабатывает порядка 10 000 обращений в месяц. Вторая линия знает о продуктах и отвечает на вопросы по сделкам, таких обращений около 3 000 в месяц. Третья линия — это уже команды продуктов, до них доходят единичные вопросы.

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

Так выглядел контекст проблемы, с которой вышла на внутренний хакатон наша команда из трёх человек. 

Кстати, интересно ваше мнение, как бы вы подошли к решению задачи по автоматизации такого бизнес-процесса? Напишите в комменты или личку. 

Для общеязыковых тематик существует множество мультиязычных бенчмарков (наборов тестовых задач) для оценки качества эмбеддингов, полученных с помощью разных моделей. С помощью этих бенчмарков можно сравнивать модели и выбирать подходящую для своей задачи. К сожалению, в области эмбеддингов научных текстов выбор не такой широкий, особенно для русского языка. Для английского языка существует бенчмарк SciDocs и его расширенная версия SciRepEval, разработанные Allen Institute for AI. Для русского языка первый бенчмарк ruSciDocs был опубликован нами около года назад вместе с моделью ruSciBERT, и состоял из небольшого количества данных на русском языке, которые мы смогли собрать в открытом доступе (на порталах ЕГИСУ НИОКТР и Semantic Scholar).

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

Хабры и Хаброчки, я хотел бы перед самой статьёй обсудить вопрос целесообразности писать свой движок, вместо готовых решений. Есть куча статей, которые опишут разные движки от более популярных до менее. Я бы хотел затронуть немного другой вопрос: "Как человеку, который изучал программирование много лет заняться геймдевом?". Обычно, есть два пути в геймдев:

Умышленный путь. Это когда человек, который играет в игры рано или поздно решит их создать. Тогда, он выбирает где ему учиться этому и выучивает игровые движки и C-образные языки к ним (чаще всего, C#).

Путь прогеров. Программист увлекается математикой и пишет код. Так или иначе, везде где есть код — есть компьютер. Цифровые развлечения (в том числе и игры) не проходят мимо тех людей, который постоянно пишут код. Так, часть прогеров решает написать свою игру и начать свой путь в геймдев. Об этом пути мы и поговорим.

Так зачем выбирать "сложный" путь? Во-первых, не для всех он сложнее. Лично мне сложнее перейти на C# с использованием Unity, чем написать новый проект на Python. Во-вторых, люди не всегда понимают сам движок. Сейчас я преподаю в институте "Бизнеса и Дизайна". Это один из первых профильных учреждений, занимающихся геймдевом. И вот у студентов я спросил зачем им движок. Каково было моё удивление, что далеко не все понимаю, вообще зачем он нужен. Спойлер, не из-за пресетов.

Всех заинтересовавшихся, приглашаю в мир змеиных игр!

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

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

Погнали собирать мусор!

Несколько лет назад уже писал про свои поиски идеальной и недорогой панели управления умным домом (статья собрала 200 закладок), тогда в 2020 году я остановился на недорогом андроид планшете, который перепрошил на чистый андроид для выполнения удаленных команд через ADB.

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

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

Выбор пал на NSPanel из‑за цены около 3,5 тысяч рублей, а также возможности установки в подрозетник или покупки настольной подставки — как у меня на фото.

Меня зовут Валя Борисов, и я — аналитик в команде Ozon. Задача нашей команды — создавать инструменты для мониторинга и анализа скорости. 

Наши усилия направлены на то, чтобы в реальном времени следить за тем, как быстро работают наши сервисы и платформа. Благодаря инструментам, которые мы создаём и поддерживаем, команды разработки получают представление о том, как пользователи видят работу нашего сайта или приложения. Мы помогаем выявлять причины деградации скорости и определять узкие места в инфраструктуре.

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

Когда я в последний раз менял работу и проходил собеседования, конечно, основные вопросы были про навыки продакта и особенности продуктов, которыми я занимался. Вопросы касались метрик, экономики продукта и взаимодействия с пользователями. Поскольку мой опыт специфичен :), в какой-то момент у меня даже закралось сомнение, а точно ли я продакт? Начал размышлять, откуда родился такой вопрос — и понял.

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

Но чаще всего авторы обходят стороной продукты, которые существуют для гораздо меньшего числа пользователей, и которыми пользуются те команды, которые делают большие, классные и успешные продукты. Я говорю о внутренних ИТ-продуктах компаний.

Меня зовут Денис Соловьев, и так получилось, что я работал и продолжаю работать как раз на таких внутренних ИТ-продуктах. Я хочу сравнить, какие из инструментов и подходов работают для них.

Привет! Меня зовут Владимир Крылов, и я проектирую внутренние сервисы в Ozon.

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

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

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

Команда разработки и вообще любая группа людей — это сложный клубок из межличностных отношений и персональных компетенций. Я руковожу командами разработки и эксплуатации уже 8 лет, и за это время встречался с разными командными проблемами. Хочу предложить вам свою методологию их решения при помощи разговорных ролевых игр (РРИ).

Под катом вас ждет:

• История о том, как я сам пришёл к тому, чтобы проводить РРИ для коллег.

• Краткий рассказ о том, что из себя представляют такие игры.

• Примеры решения реальных командных задач.

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

Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.

Без системы контроля версий сейчас невозможно представить ни один проект. Это оплот любой кодовой базы, это мощнейший инструмент, с помощью которого эту базу можно изменять и отслеживать. Однако нередко чистотой истории изменений пренебрегают, полагаясь на старое доброе «И так сойдёт!», абсолютно игнорируя при этом сложность понимания и поддержки такой истории в будущем.

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

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

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

Всем привет! 

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

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

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

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