Давно я приглядывался к Serverless технологиям, но все не доходили руки. Как и во многих компаниях, там где я работаю есть строгое разделение на бэкендеров и фронтендеров. Проблемы у этого известные и самая неприятная — надо договариваться, а разработчики далеко не всегда самые общительные люди.
Чтобы применять Domain-Driven Design, DDD Aggregate и Transactional outbox на MongoDB, наша команда создала open source — библиотеку calypso для работы с BSON.
Публикация для тех, кто стремится к современным практикам разработки и разделяет наше влечение к Scala 3.
Готовы к открытиям? Добро пожаловать в мир функционального программирования и надёжной работы с schema-on-read.
Привет! Меня зовут Сергей, я немножко ведущий фронтенд-разработчик и немножко продуктовый менеджер, а еще друг, поэт и музыкант. Как так получилось — история для другой статьи, а здесь я расскажу о другом.
По долгу профессии я сталкиваюсь с наймом новых сотрудников и вижу, какие трудности сейчас поджидают новичков в IT, какие преимущества из текущей ситуации на рынке труда может извлечь наниматель, и чем текущая ситуация может закончиться для рынка и для бизнеса. Я считаю, что симптомы кадрового кризиса проявляются для всех по-разному, но источники связаны и разбираться с этим лучше в комплексе.
Получилась длинная статья, где я даю советы как для новичков в IT, так и для нанимателей, а в конце я предлагаю некоторый выход из сложившейся ситуации.
Привет, я Настя — младший разработчик в «Метре квадратном». Это статья о том, как я пришла в разработку практически с нуля в 2023 году. Знаю, на «Хабре» таких уже много, но когда-то подобная статья помогла мне начать свой путь, и я решила, что этот текст тоже может быть полезен кому-то другому.
В статье описала мой опыт: обучение разработке с нуля и поиск работы в IT. Если вам не хочется читать статью, но интересно посмотреть алгоритм действий, он в самом конце текста.
В этой статье я расскажу об алгоритме, который помогает нам решить задачу дедупликации данных без идентификатора, дам контекст решаемой проблемы и словесное описание алгоритма с визуализацией. Реализацию алгоритма можно посмотреть по ссылке в заключении.
Алгоритм решает простую задачу. Он объединяет персональные данные из разных систем и получает на выходе «золотую запись». Делает он это в батчёвом и транзакционом режимах с приемлемой вычислительной сложностью, несмотря на принадлежность к формальному классу комбинаторных алгоритмов.
«Золотая запись» выступает в дальнейшей цепочке обработки данных в качестве уникального ключа. Это позволяет решить на масштабах компании задачу сопоставления ранее несвязанных событий, что даёт профит бизнесу как напрямую (через лучшее понимание клиентского пути), так и опосредованно через лучшую организацию аналитики и выстраивание предиктивных моделей.
Все мы привыкли к общепринятым инструментам для тестирования. Думаю, список есть у каждого и он постоянно пополняется. Лично мой: Postman, IntelliJ IDEA и DataGrip от JetBrains, ShareX для скриншотов и его величество DevTools.
В этой статье я хотел бы отдать дань самоделкам нашего ремесла. Мелкие скрипты и утилиты или целые приложения, написанные для того, чтобы помочь в нелёгком деле создания продукта. На первый взгляд незначительные штуки, которые делают процесс работы таким удобным.
В М2 большой объём письменной коммуникации с клиентами. Это и ответы на общие вопросы — о компании, процессах подбора и покупки недвижимости, — и обсуждение конкретных деталей запущенных сделок. К примеру, клиенты хотят знать, в каком отделении банка они будут подписывать документы, пришли ли деньги продавцу, прошёл ли объект недвижимости проверки перед продажей.
Работа с вопросами происходит в тикет-системе клиентской поддержки (UseDesk). Для каждого вопроса через любой канал коммуникации (e-mail, мессенджеры, чат на сайте) заводится обращение, и сотрудник экспертной поддержки отвечает на него с определённым SLA.
Для оптимизации работы с обращениями процесс разделён на 3 линии поддержки. Первая линия отвечает только на вопросы без привязки к продукту и не знает о конкретных сделках. Она обрабатывает порядка 10 000 обращений в месяц. Вторая линия знает о продуктах и отвечает на вопросы по сделкам, таких обращений около 3 000 в месяц. Третья линия — это уже команды продуктов, до них доходят единичные вопросы.
Вопросы к первой линии поддержки и частично ко второй — однотипные, их обработку можно автоматизировать и сократить тем самым затраты на поддержание бизнес-процесса.
Так выглядел контекст проблемы, с которой вышла на внутренний хакатон наша команда из трёх человек.
Кстати, интересно ваше мнение, как бы вы подошли к решению задачи по автоматизации такого бизнес-процесса? Напишите в комменты или личку.
Комплекс доменной неполноценности — это когда веришь, что доменный слой приложения должен быть самым большим и самым важным, и винишь себя в том, что в твоём коде это не так. Это происходит, если воспринимать «Чистую архитектуру» как единственно верный способ писать код.
Привет, меня зовут Саша, я Head of mobile в компании «Метр квадратный». Под катом — почему появился этот комплекс и как с ним бороться. Сразу оговорюсь, в статье много моего личного мнения, и будет круто, если в комментах вы поделитесь своим.
— Дима, посмотри, пожалуйста, тикет по саппорту, ЭТО ОЧЕНЬ СРОЧНО!!!
Было время, когда ответы на такого рода сообщения занимали большую часть рабочего времени нашей дежурной смены от команды разработки. К счастью, постепенно ситуацию удалось исправить.
Подходами, за счет которых это получилось сделать, как раз и хочется поделиться в этой статье. Если у вас, как и у меня, от упоминания технической поддержки начинает дергаться глаз, а необходимость ей заниматься не вызывает ничего, кроме чувства вселенского уныния, добро пожаловать под кат. Серебряной пули не обещаю, но что-то полезное, может, и найдется.
Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:
Писать, собирать, агрегировать и сохранять логи для последующего анализа важно: это наиболее подробное представление того, как работает система.
Логи можно собирать и отправлять в централизованную систему по-разному, например используя библиотеки в самом приложении или сторонние агенты вроде Filebeat, Fluent Bit, Vector. Есть множество систем хранения вроде Elasticsearch, Loki, Splunk, файлы на диске или объекты в S3.
Мы в М2 тоже занимаемся этим вопросом и постоянно ищем схемы и инструменты, помогающие улучшать централизованную систему логирования. Я, как инженер развития инфраструктуры, непосредственно принимаю в этом участие. В статье хотел бы поговорить об этапе агрегации и поделиться нашими наработками.
Привет, Хабр! Разрабатывая экосистему для «Метр квадратный», мы со старта проекта планировали большую линейку продуктов. Поэтому подбирали стек, который поможет реализовать максимум идей. В итоге мы пришли к протоколу gRPC.
В этом материале я расскажу:
— о преимуществах gRPC;
— об особенностях работы с протоколом, и о том, как с ними жить;
— о тех проблемах, с которыми мы столкнулись;
— и о том, как их решить.
Привет! Меня зовут Максим Гореликов, я Backend Tech Lead в M2. Несколько вещей, которые надо знать об этой статье, прежде чем углубляться в нее:
— эта статья — расшифровка моего доклада на конференции Yandex Scale 2021 с некоторыми доработками;
— данные собирали с разных участников переезда и набрали много интересного, но доклад был в слоте про Yandex Data Platform, поэтому оставили кейсы только на эту тему;
— материал скорее обзорный, чтобы понимать, с чем можно столкнуться. Каких-то суровых технических подробностей немного, потому что в каждом переезде они будут свои.
События, описанные в статье, происходили в 2020 году, сейчас входим в топ-5 клиентов по объему потребляемых сервисов Yandex.Cloud. Когда переезжали, ещё не все процессы в Yandex.Cloud были хорошо налажены, поэтому расскажу о самых ярких воспоминаниях — проблемах, с которыми столкнулись. Хороших моментов тоже хватало, но проблемы всегда интереснее обсудить.
Привет, Хабр! Меня зовут Андрей Перепелкин. Я руководитель группы бэкенд-разработчиков, вошел в IT более 15 лет назад, 10 лет занимаюсь Java и около 4 плотно работаю с микросервисами.
В этой статье я расскажу, как:
— мы организовали разработку микросервисов так, чтобы вынести инфраструктуру из продуктового проекта и управлять ей отдельно;
— создали общее поле разработки для независимых команд, получить единый стиль кода и контролировать качество;
— встраиваем микросервисы в инфраструктуру и собираем метрики и логи, не загружая этим разработчиков.
