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

Я не буду делать свои прогнозы, так как не экономист, но покажу как сделать инструмент для подсчета своих активов между разными финансовыми инструментами. А сделал я его из Google-таблиц и AppsScript, последний мне понадобился, чтобы узнавать актуальный курс.

Давно я приглядывался к 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 плотно работаю с микросервисами. 

В этой статье я расскажу, как:

— мы организовали разработку микросервисов так, чтобы вынести инфраструктуру из продуктового проекта и управлять ей отдельно;

— создали общее поле разработки для независимых команд, получить единый стиль кода и контролировать качество;

— встраиваем микросервисы в инфраструктуру и собираем метрики и логи, не загружая этим разработчиков.