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

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

Привет! Меня зовут Андрей, я несколько лет занимаюсь разработкой, и за это время успел поработать с разными командами дизайнеров, посмотреть на разные подходы, кто где как делает, где какие есть сложности. 

В этом посте как раз о подобных сложностях я и хочу поговорить, а именно — о проблеме в коммуникациях между разработчиками и дизайнерами. Я очень люблю делать личные кабинеты, поэтому и в качестве примера буду говорить именно о разработке ЛК в билайне за последние три года. О том, какие именно трудности возникали и как мы упростили работу на UI-китом, под катом.

Представьте ситуацию.

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

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

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

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

У некоторых в команде уже был опыт работы с xa-транзакциями.
Довольно удобный способ, когда у вас есть несколько ACID СУБД. Процесс состоит из двух фаз.

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

А что делать, если прямо сейчас у вас нет ни времени на разработку сложных подходов, ни приблизительного понимания, как долго живёт ваш среднестатистический клиент, а задача от бизнеса дать какие-то рекомендации есть?

Меня зовут Артём, я антифрод-аналитик в Каруне, и в данной статье мы рассмотрим достаточно простой подход, с помощью которого можно решить обозначенную проблему. Если вы скажете, что антифрод решает абсолютно другой спектр задач, то будете абсолютно правы. Однако во время работы с одним из проектов при переосмыслении использованного алгоритмического стека в нём, мы пришли к выводу, что отдельные небольшие кусочки этого стека вполне могут подходить и для решения других задач. На базе нашего опыта расскажу, как с помощью байесовского моделирования и библиотеки PyMC3 можно получить примерную картину о том, как долго ваш клиент должен быть неактивным, чтобы считать его отточником. Это может помочь ответить на базовые вопросы бизнеса и подготовиться к реализации более точных и качественных моделей (если это потребуется).

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

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

Привет! Мы в QIWI любим проводить хакатоны. Во-первых, это просто интересно и помогает разгрузить голову. Во-вторых, зачастую помогает решить какие-то внутренние проблемы компании, от организации тех или иных процессов, которые давно хотелось починить.

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

Хакатонам в QIWI более 10 лет. Самый первый хакатон помнят только олды, которые давно в компании. Конечно, времена были разные, когда-то хакатонов проводили больше, а когда-то — меньше, но если говорить о каких-то усредненных числах, то в год мы делаем примерно два хакатона.

На каждый заявляется примерно 10-15 команд. Иногда доходило и до 20. Но одно дело — заявиться, другое — пройти отборочный этап и дойти до непосредственного участия.

Сами хакатоны у нас бывают двух видов:

Отсутствие нормального регулирования крипто рынка, делает его полигоном для испытания всех возможных скам механик. Исследование 2022 года показало, что около 45% объема сделок EVM блокчейнов по NFT являются частью отмывочной торговли.

Учитывая такой большой процент мне стало интересно как с этим обстоят дела в блокчейне TON и я решил применить фильтры из исследования приведенного выше, чтобы найти отмывочные сделки в самой большой NFT коллекции TON - Telegram Usernames.

Рассмотрим:

• что такое отмывочная торговля NFT;

• зачем она нужна и что привело к таким большим процентам отмыва в EVM блокчейнах;

• методологию поиска отмывочных сделок;

• отмывочные сделки в Telegram Usernames.

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

Это вторая статья из цикла. В первой части я рассказывал про самые базовые понятия Elasticsearch. В этом же посте разберем устройство анализа текста и немного пощупаем полнотекстовый поиск.

Несколько слов про анализ текста

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

Мы уже познакомились с некоторыми типами Elasticsearch, но в этом разделе будем рассматривать только два — keyword и text. Тип text анализируется для полнотекстового поиска. Тип keyword преимущественно остается без изменений для точного поиска, сортировки и агрегации.

Привет! Меня зовут Глеб, я разработчик команды продукта «Сервис персонализации» в SM Lab. В цикле из трех постов я расскажу про основы полнотекстового поиска в Elasticsearch.

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

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

Итак, начнём с самых базовых понятий.

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

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

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

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

Немного душная, но важная вводная часть

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

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

• Какую сумму инвестировать в бизнес-направление и когда вложения окупятся?

• Сколько мы зарабатываем на продукте A, и не каннибализирует ли он доходы с продукта B?

• Насколько капитализация нашего бизнеса изменилась за последний год?

Помимо этого, мы принимаем (преимущественно в автоматизированном режиме) множество операционных решений:

• Информацию о каком продукте направить клиенту в SMS-рассылке?

• С каким приоритетом обслужить клиентов в условиях ограниченных ресурсов?

• Какую оптимальную цену предложить клиенту за потребляемые услуги?

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

Бывает такое: смотришь кино, слышишь OST или просто какую-то хорошую песню, которую решили вставить в фильм, и думаешь — а неплохо бы её добавить к себе в плейлист. Способов сделать это было несколько. Можно было пойти и поискать или сам OST к фильму, или неофициальные саундтреки к нему. Можно было посмотреть, что по названию фильма выдаётся в поиске через музыкальные стриминговые сервисы, вдруг какая-то площадка уже позаботилась о вас и собрала тематический плейлист. Отдельные граждане прямо во время фильма включали на смартфоне Shazam и распознавали трек. В общем, кто во что горазд.

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

Меня зовут Алексей Царёв, я занимаюсь развитием технологий в развлекательных сервисах Яндекс. И моя задача в том, чтобы из какой-то отдельно взятой технологии создавать рабочие продукты для конечного пользователя. Именно об этом, на примере распознавания музыки в фильмах, и будет этот пост.

Итак, мы с вами добрались до третьей, самой «хардовой» части цикла. Сегодня поговорим про gRPC.

Что такое gRPC? 

Сам RPC — удалённый вызов процедур (иногда вызов удалённых процедур; RPC от англ. remote procedure call) — класс технологий, позволяющих программам вызывать функции или процедуры других программ, делая это так, как если бы они находились в одном адресном пространстве. Буква g в названии — это гугловая реализация этих технологий.

Разберем это все на примере.

Допустим, что вы — программист и сидите в монолитной репе. У вас одно приложение. Сам проект открыт в IDE и вы в нем работаете. В репе реализован определенный класс (например, на Kotlin), у которого есть метод, возвращающий вам данные по пользователю.