Сейчас, в том числе и у нас на сайте, и в приложениях ivi, есть явная тенденция роста аудитории на мобильных устройствах. Также растет и доля покупок, совершаемых в интернете с мобильных устройств. В отличие от десктопа, помимо традиционных вариантов оплаты, доступны системы мобильных платежей, например Apple Pay, Android Pay, Samsung Pay. Эти системы можно использовать не только для оплаты в терминалах, принимающих банковские карты, но и для оплаты в приложениях и на веб-сайтах.

Внедрение мобильных платежей мы начали с веб-версии ivi и выбрали мобильный сайт и систему Apple Pay.

Мы в ivi давно собирались обновить наше приложение под Windows 10 (которое для ПК и планшетов). Мы хотели сделать его эдаким «уютным» уголком для отдыха. И поэтому анонсированная недавно Microsoft-ом концепция fluent design пришлась нам очень кстати.

Но я не буду здесь рассказывать про стандартные компоненты, предлагаем Microsoft-ом для fluent design-а (Acrylic, Reveal, Connected-анимации и др.), хотя мы их, конечно, используем тоже. С ними всё просто и понятно — бери документацию и пользуйся. 

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



Идея в том, что мы используем depth и motion из fluent design system. Центральный элемент как бы слегка приподнимается надо всеми остальными. Это достигается за счёт анимации его размера и тени во время скролла. 

В этой статье я хочу рассказать о нашем боте для релизов. У нас много очень разных проектов, начиная от микросервисов backend(a), заканчивая приложением для win 10.

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

Все началось вот с такого крика души:

"Количество разработчиков растет, компания развивается и процесс выгрузки становится все сложнее и запутаннее. Очереди на «добро» скапливаются. Разработчик должен следить нет ли у кого вмерженной и невыгруженной задачи, хотя б на одном из сервисов перед ним и ждать когда, блокировка снимется. Если он еще не получил «добро», то периодически пинать добродавателей, т.к. сообщения с просьбой добра теряются в чатике. А выгрузиться хочется быстрее, потому, что если ты не выгрузишься сегодня, например, то завтра уже кто-то другой может вмержиться и не посмотреть, что предыдущий тег не выгружен => выгрузить незаметно для себя два — и все сломается. Это все превращается в маленький кошмар."

Эта статья — третья часть серии:

• Часть 1: Декораторы методов
• Часть 2: Декораторы свойств и классов
• Часть 3: Декораторы параметров и фабрика декораторов
• Часть 4: Сериализация типов и metadata reflection API

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

В этой статье мы расскажем про:

• Последний оставшийся тип декораторов — декоратор параметра
• Реализацию фабрики декораторов
• Реализацию конфигурируемых декораторов

Эта статья — вторая часть серии:

• Часть 1: Декораторы методов
• Часть 2: Декораторы свойств и классов
• Часть 3: Декораторы параметров и фабрика декораторов
• Часть 4: Сериализация типов и metadata reflection API

В предыдущей статье мы выяснили, какие типы декораторов мы можем использовать в TypeScript.

Мы также узнали, как реализовать декоратор метода и ответили на основные вопросы про то, как декораторы работают в TypeScript:

• Как они вызываются?
• Кто передает в них аргументы?
• Где объявлена функция __decorate?

В этой статье мы познакомимся с двумя новыми типами декораторов: декоратором свойства (PropertyDecorator) и декоратором класса (ClassDecorator).

От переводчика: TypeScript — довольно молодой и активно развивающийся язык. К сожалению, в русскоязычной части Интернета о нем довольно мало информации, что не способствует его популярности.

Многие возможности, которые сейчас реализованы в ES6, значительно раньше появились именно в TypeScript. Более того, некоторые возможности и предложенные стандарты ES7 также имеют экспериментальную реализацию в этом языке. Об одной из них, появившейся сравнительно недавно — декораторах — и пойдет речь.

Предлагаю вашему вниманию перевод статьи (а точнее, цикла статей) о декораторах в TypeScript под авторством Remo H.Jansen

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

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

Эта публикация является продолжением ранее написанной в нашем блоге: «Реализуем безопасный VPN-протокол». В этой статье мы не переделываем и не переписываем протокол, а только чуть дорабатываем его дальше. Реализация всего нижеописанного уже присутствует в версии GoVPN 3.1.



Для создания шума немного изменён транспортный протокол. Для аугментации рукопожатия и усиления паролей изменён протокол рукопожатия. Более подробно обо всём этом под катом.

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



Результатом этой работы предполагается создание работающего клиент-сервера, пригодного для review разработчиками (то есть немного кода на высокоуровневом языке), достаточно производительного, чтобы использоваться в промышленных условиях, имеющего высокий порог безопасности: GoVPN.

Привет, Хабр! Какое-то время назад люди осознали, что увеличивать мощность сервера в соответствии с ростом нагрузки просто невозможно. Тогда-то мы и узнали слово «кластер». Но как бы красиво это слово не звучало, всё равно приходится технически объединять разрозненные серверы в единое целое – тот самый кластер. По городам и весям мы добрались до наших узлов в моём предыдущем опусе. А сегодня мой рассказ пойдёт о том, как делят нагрузку между членами кластера системные интеграторы, и как это сделали мы.



Внутри публикации вас также ждёт бонус в виде трёх сертификатов на месячную подписку ivi+.

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

Персональные рекомендации позволяют познакомить пользователя с объектами, о которых он, возможно, никогда не знал (и не узнал бы), но которые могут ему понравиться с учетом его интересов, предпочтений и поведенческих свойств. Однако, часто пользователь ищет не новый объект, а, к примеру, объект A похожий на объект B («Форсаж 2» похож на «Форсаж»), или объект A, который приобретается/потребляется с объектом B (сыр с вином, пиво с детским питанием, гречка с тушенкой и т.д.). Построить такие рекомендации позволяют неперсонализированные рекомендательные системы (НРС).


Рекомендовать похожие/сопутствующие объекты можно, ориентируясь на знания об объектах (свойства, теги, параметры) или на знания о действиях, связанных с объектами (покупки, просмотры, клики). Преимуществом первого способа является то, что он позволяет достаточно точно определить похожие по свойствам объекты («Форсаж 2» и «Форсаж» — похожие актеры, похожий жанр, похожие теги, ...). Однако данный способ не сможет порекомендовать сопутствующие объекты: сыр и вино. Еще одним недостатком этого способа является тот факт, что для разметки всех объектов, доступных на сервисе, требуется не мало усилий.

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

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

Весной этого года я узнал о возможности базы данных HP Vertica создавать запросы с матчингом паттернов событий. Так называемый Events Pattern Matching хорошо ложился под задачу анализировать поведение пользователей в продуктах ivi.ru. Мы решили попробовать разобраться с воронками оплаты, с поиском проблемных мест на устройствах, глубже погрузиться в анализ трафика. Нашей команде очень нравится, как реализована аналитика у Mixpanel и Localytics (она как раз основана на событиях и их свойствах), поэтому многие идеи были позаимствованы у них.

Когда вы выросли настолько, что появились узлы в разных городах, возникает задача распределения нагрузки между ними. Задачи такой балансировки могут быть разными, но цель, как правило, одна: сделать так, чтобы было хорошо. У меня дошли руки рассказать о том, как это делают обычно, и как это сделано в ivi.ru.

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

Среди высоконагруженных (highload) систем существует большая разница между системами с высокой нагрузкой в плане количества запросов в секунду (RPS, requests per second) и высокой нагрузкой в плане генерируемого трафика (того, который меряется гигабитами в секунду). В нашем ivi.ru нагрузка есть и та, и другая. Сейчас я хочу рассказать про то, как мы генерируем сотни гигабит в секунду, и никому от этого не плохеет.

Одной из наиболее популярных техник для построения персонализированных рекомендательных систем (RS, чтобы не путать с ПиСи) является коллаборативная фильтрация. Коллаборативная фильтрация бывает двух типов: user-based и item-based. User-based часто используется в качестве примера построения персонализированных RS [на хабре, в книге Т.Сегаран,...]. Тем не менее, у user-based подхода есть существенный недостаток: с увеличением количества пользователей RS линейно увеличивается сложность вычисления персонализированной рекомендации.

Когда количество объектов для рекомендаций большое, затраты на user-based подход могут быть оправданы. Однако во многих сервисах, в том числе и в ivi.ru, количество объектов в разы меньше количества пользователей. Для таких случаев и придуман item-based подход.

В этой статье я расскажу, как за несколько минут можно создать полноценную персонализированную RS на основе item-based подхода.