Как стать автором
Обновить
20
0
Павел Юркин @Pavel_Yurkin

Пользователь

Отправить сообщение

Рекомендательный движок за 2 строчки кода

Время на прочтение 5 мин
Количество просмотров 5K

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

Алгоритм можно описать всего в одном предложении: берём историю продаж и обучаем на ней гугловый Word2Veс, фильтруем результат.

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

Читать далее
Всего голосов 23: ↑23 и ↓0 +23
Комментарии 7

Эволюция оркестратора микросервисов. Как переход на WebClient помог пережить пандемию

Время на прочтение 11 мин
Количество просмотров 5.4K

Хочу рассказать о том, как мы оптимизировали наш оркестратор микросервисов.

Потому что в случае с такого рода сервисами наш любимый подход "пихаем в базу - строим индексы" не работает. Как минимум потому что базы нет).

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

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

Читать далее
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 19

Как сэкономить на психотерапевте используя test-driven development

Время на прочтение 27 мин
Количество просмотров 19K
У вас когда-нибудь было такое состояние?

image

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

Ниже я покажу, где были самые большие различия.

Лично мне это было важно, потому что каждый раз, когда кто-то находил баг в моём коде, я ловил увесистый минус на самооценку. Да, я понимал, что баги — это нормально, их пишут все, но ощущение неполноценности никуда не уходило. Также, в процессе эволюции сервиса, я иногда понимал, что сам понаписал такого, что чешутся руки всё выкинуть и переписать заново. И как это получилось — непонятно. Как-то всё было хорошо в начале, но вот пару фич и через некоторое время уже на архитектуру без слёз не взглянешь. Хотя вроде каждый шаг изменения был логичный. Ощущение того, что мне не нравится продукт собственного труда, плавно перетекало в ощущение, что программист из меня, простите, как из говна пуля.

Оказалось, я не один такой и схожие ощущения возникают у многих моих коллег. И тогда я решил, что либо научусь писать нормально, либо пора менять профессию. Я попробовал test-driven development в попытке что-то изменить в своём подходе к программированию.

Забегая вперёд, по результату нескольких проектов, могу сказать, что TDD даёт более чистую архитектуру, но при этом замедляет разработку. И подходит не всегда и не всем.
Читать дальше →
Всего голосов 32: ↑31 и ↓1 +30
Комментарии 27

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность