Комьюнити менеджмент в GameDev — это не про мемы, а про сервис, комфорт и вовлеченность

Когда мы готовили it-конференцию DUMP, то предполагали, что секция о разработке игр вызовет интерес. Но то, что мест в зале не хватит, было неожиданностью. Мы решили продолжить обсуждение трендовых тем и пообщались с представителями игровой индустрии о комьюнити менеджменте — профессии, которая в России только набирает обороты. О том, как и для чего сочетать социологию, психологию и маркетинг — в нашем интервью c Александром Мартом, лид КМом, проработавшим в Targem Games без малого 6 лет.

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

— Комьюнити-менеджмент — это работа с пользователями, объединенными общими интересами, целями или болями.

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

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

Почему они нам необходимы? Есть группа игроков, которая помимо того, что находится на игре и получает эмоции от игры, за её пределами хочет сохранять эти эмоции, приумножать их. У них есть энергия на это, общие цели, привязанность к проекту. И чтобы энергию направить в мирное русло и построить более эффективную связь с игрой, повлиять на то, чтобы у игроков сохранилась желание возвращаться в игру и так далее, приходит КМ.

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

— Откуда приходят в комьюнити менеджмент? Эти ребята чаще всего маркетологи?

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

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

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

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

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

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

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

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

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

Есть какой-то топ инструментов, который позволяет проблемы пользователей вытаскивать на поверхность?

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

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

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

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

Но мало быть игроком в своем проекте и понимать к какому типу относятся те или иные пользователи. Также важно понимать интересы аудитории в реальной жизни, говорить с ней на одном языке и на привычной площадке. Сейчас будет пример из мобильных игр. Там есть очень серьезная проблема в том, что многие игроки в социальных играх в кланы объединяются не в Telegram, Discord, VK или Facebook, а в WhatsApp или Viber. Это связано с возрастной категории пользователей. То есть когда играют мужики 30+ в каких-то условных викингах, им привычно пользоваться теми инструментами, которые у него всегда под рукой. Его подсадили на WhatsApp, он будет пользоваться WhatsApp. Туда приходит молодой КМ лет 20 и говорит, чтобы все пошли в Telegram. Игроки говорят: “А не пошёл бы ты дальше”. Поэтому иногда КМ-у нужно не только знать своего пользователя, но и найти его в привычной среде обитания.

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

Расскажи, какие KPI используются для оценки работы менеджера?

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

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

Есть советы для тех, кто хочет стать комьюнити менеджером?

— В первую очередь быть просто адекватными. Как бы абсурдно это не звучало. Осенью мы собеседовали порядка 15 человек, и только 2 из них прошли по критерию “адекватности”. Чего мы только не насмотрелись, хотя общие пожелания были минимальными: нам просто нужен был человек, которого мы всему научим. И таких вакансий на младшие позиции в геймдеве бывает достаточно много. Курсы, кстати, не могут являться гарантом трудоустройства, ни в одной компании, с которой я знаком, сейчас не практикуется просмотр курсов, на которых ты бывал. Корочки могут служить только для вашего собственного развития, но не бонусом при приёме на работу.

Есть ещё общий совет для всех работников сферы IT: не соглашайтесь на бесплатную стажировку, бойкотируйте эти вакансии. Любая работа должна быть оплачена. При этом неоплачиваемые тестовые задания — это норма. Просто потому, что использовать ваш труд из него довольно проблематично. А устраивать подставные вакансии для поиска решений с помощью тестовых на КМа невероятно дорого и нецелесообразно. Поэтому в нашей специальности бояться подобного не стоит. Также не бойтесь его выполнять, даже если не знаете о чём вас в нём спрашивают.. Главное — то, что вы думаете, в какую сторону идет ваша мысль при формировании ответа. В тестовом задании чаще смотрят на ход мышления, а не на правильность ответа.

Ну и напоследок, случай с тестовым заданием. Одна из задач в тестовом у нас — придумать конкурс. . Собеседующийся предложил сделать конкурс про машину Илона Маска (он тогда как раз анонсировал свой квадратный пикап). Параллельно такой конкурс запустился от КМа, который у нас уже работает. Просто потому что такой инфоповод было сложно не осветить в рамках нашей игры. Но нас всё равно обвинили в том, что мы украли решение из тестового. В нашей сфере, на мой взгляд, нет проблем с креативом. Есть проблемы с мышлением и пониманием аудитории, с тем, чтобы чувствовать свою работу. Ну и с общим представлением окружающих о профессии. Так что, если вы молодой, активный, вас тянет к работе с людьми и вам порой кажется, что вы понимаете людей чуть лучше, чем они сами себя, то определенно стоит попробовать себя в КМ-стве.

ссылка на оригинал статьи https://habr.com/ru/company/it_people/blog/565328/

Монтирование и управление LVM-томами на Android Linux Deploy. Часть 2


В этом руководстве мы рассмотрим создание и монтирование LVM томов на рутованном устройстве Android. Это вторая часть моего проекта «Резервный сервер на Android», но она будет на 80% состоять из работы с LVM и лишь на 20% с UrBackup/Linux Deploy. Первая часть доступна здесь.

По итогам предыдущей части мы развернули Debian 10 на рутованном телефоне Android, установили UrBackup сервер и подключили клиента. Для завершения этой части руководства вам потребуется кое-какое дополнительное оборудование:

  • Внешний HDD/SSD с USB-кабелем;
  • USB hub/dock с портом для зарядки и (необязательно) ethernet-портом;
  • (необязательно) ethernet-кабель.

Более подробно по этим пунктам можете почитать в разделе «Дополнительное оборудование» Части 1.

План

  1. Краткое знакомство с LVM
  2. Создание логического тома из внешнего хранилища
  3. Монтирование созданного тома
  4. (На будущее) Добавление хранилища

LVM

Для начала мы вкратце познакомимся с LVM (менеджер логических томов). Понимание этого инструмента пригодится вам в принципе, а в данном случае существенно упростит процесс расширения резервного хранилища в будущем. Вот схематичное представление принципа действия LVM:

Надеюсь, эта схема поможет вам разобраться, как он работает. По существу, вам нужно понимать следующее:

  1. Физические блочные устройства разбиваются на разделы, которые мы размечаем как физические тома.
  2. Затем мы переопределяем их в логические «пулы», называемые группами томов.
  3. Группы томов повторно разделяются на логические тома.

В чем вообще смысл? Вот сравнение:

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

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

Если вы думаете, что: «Как-то все неоправданно усложнено», то ошибаетесь. Было бы глупо, если бы LVM использовался только для этого. Мы же в основном применяем его, чтобы в дальнейшем иметь возможность делать следующее:

Настроив блочное устройство хранения с помощью LVM, мы сможем легко добавлять к нему хранилище позднее без необходимости переноса данных на устройства большего объема. Можно просто добавить еще одно устройство в группу томов и расширить логический том БЕЗ потери данных. На деле это легко как 1 + 1 = 2. Если в ходе чтения руководства вы где-то запутаетесь, то вернитесь к этим схемам и определите, в какой именно части процесса находитесь.

Шаг 1. Создание логического тома из внешнего хранилища

Предполагается, что вы авторизованы как root-пользователь.

A. Установите LVM:

apt -y install lvm2

B. Отобразите udev.

Это касается только среды Linux Deploy. В нормальной среде Linux делать этого не нужно. В Linux Deploy udev будет вызывать различные ошибки в процессе LVM.

Откройте lvm.conf:

nano /etc/lvm/lvm.conf

Найдите следующие строки:

multipath_component_detection = 1 md_component_detection = 1 udev_sync = 1 udev_rules = 1

Измените их на «0»:

multipath_component_detection = 0 md_component_detection = 0 udev_sync = 0 udev_rules = 0

Сохранитесь и выйдите.

Примечание: Вы по-прежнему можете получать ошибки, утверждающие: «Kernel not configured for semaphores (System V IPC). Not using udev synchronisation code.» Игнорируйте.

C. Определение имени для устройства хранения.

Подключите USB-хаб и внешнее устройство хранения. На сервере введите:

lsblk

Эта команда выведет список устройств и разделов. Найдите тот, что совпадает с вашим (размером и # разделов).

Объем моего внешнего диска составляет 160Гб, так что, похоже, это sde. Если вы подключили устройство после загрузки, то оно скорее всего будет в списке sdX последним. Блочные устройства Android расположены в /dev/block, значит мой внешний диск находится в /dev/block/sde. Если вы используете стандартный дистрибутив Linux, то ваше устройство будет в /dev/sdX.

D. Разбиение диска на разделы:

fdisk /dev/block/sde

Эта команда запустит среду секционирования fdisk. Сначала просмотрите текущую таблицу разделов:

p

Как видите, у меня один раздел, /dev/block/sde1, занимающий все 149.1Гб.

Мы будем разбирать процесс с нуля, поэтому данный раздел я удалю. Это необязательно, и вы можете оставить существующие разделы.

d

Очистив таблицу разделов, я отформатирую диск в DOS/MBT:

o

Это относится только к среде Debian в Linux Deploy. В обычной среде Linux для LVM нет разницы MBT или GPT, потому что эта сигнатура все равно будет в последствии стерта.

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

Для использования всего пространства диска укажите следующую команду и выйдите:

w

Если же вам нужен раздел, то эту:

n

Для применения установок по умолчанию просто жмите Ввод (как показано красными рамками ниже). В пункте настройки последнего сектора можете прописать, какой объем раздела вам нужен, указав + и размер в кибибайтах (К), мебибайтах (М), гибибайтах (G), тебибайтах (T) или пебибайтах (P).

Обратите внимание на номер раздела. Если бы я хотел использовать этот раздел, то прописывал бы /dev/block/sde1. Однако в оставшейся части руководства я буду использовать все блочное устройство и ссылаться на него через /dev/block/sde.

Введите и выйдите:

w

E. Создайте физический том для раздела:

pvcreate /dev/block/sde

Менеджер спросит вас об удалении сигнатуры dos; выберите y.
Если возникнет ошибка filtered или not found, вернитесь на предыдущий шаг и убедитесь, что тип disklabel установлен как dos, а не gpt.

F. Создайте группу томов с физическим томом:

vgcreate vg_backup /dev/block/sde

Можете выбрать другое имя для vg_backup.

После создания проверьте детали группы томов:

vgdisplay

Эта команда покажет статус всех групп томов.

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

G. Создайте из группы логический том:

lvcreate -L 149G -n lv_backup vg_backup

  • Замените 149G нужным размером логического тома. Это не обязательно должен быть полный размер группы томов. Если останется свободное место, то можете создать из этой группы и другие логические тома.
  • Замените lv_backup на нужное имя логического тома.
  • Замените vg_backup на имя, которое установили для группы томов на шаге E.

После создания проверьте детали логического тома:

lvdisplay

Вы увидите примерно такой путь: /dev/vg_backup/lv_backup. Игнорируйте его. Ссылаться на логический том мы будем через следующий:

/dev/mapper/vg_backup-lv_backup

Т.е. volume_group_name (тире) logical_volume_name

H. Отформатируйте логический том в EXT4:

mkfs.ext4 /dev/mapper/vg_backup-lv_backup

Шаг 2. Монтирование логического тома

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

В реальной жизни (то есть на нормальной машине Linux) логический том всегда монтируется через добавление в /etc/fstab. В Android нет /etc/fstab, но, к счастью, монтирование может выполнить Linux Deploy.

A. Вернитесь в меню свойств Linux Deploy. Убедитесь, что пункт MOUNTS enabled. Смонтируйте логический том в директорию UrBackup из Части 1.

B. Перезапустите сервер (на основном экране Linux Deploy нажмите STOP, а затем START).

C. Убедитесь, что том смонтирован должным образом.

Для этого подключитесь через SSH к серверу. Выполните:

df -h /path/to/your/mount/point

Просмотрите вывод этой команды. Логический том должен быть перечислен в Filesystem. Также убедитесь, что Size, Used и Available отражают адекватные данные.

D. Убедитесь, что пользователь «urbackup» по-прежнему обладает разрешениями для использования резервной директории.

В родительском каталоге резервной директории выполните:

ls -l

При необходимости обновите разрешения

Подробно читайте в Части 1. Если кратко:

chown urbackup /backup/directory

chgrp urbackup /backup/directory

Если вы не можете изменить разрешения на пользователя urbackup и группу urbackup, то можете установить UrBackup для запуска от лица root-пользователя.

Для этого измените последнюю строку файла конфигурации (/etc/default/urbackupsrv) с urbackup на root. Перезапустите сервер.

E. Авторизуйтесь в веб-интерфейсе UrBackup. Если UrBackup не сможет обратиться к резервной директории, то вы сразу увидите предупреждение. Если оно не возникает, значит все завершилось успешно. Можете приступать к резервному копированию.

(На будущее) Добавление хранилища

A. Создайте логический том по шагам 1.С — 1.E

B. Расширьте группу томов:

vgextend /dev/vg_backup /dev/block/sdX

Убедитесь, что операция vgextend прошла успешно:

vgdisplay

VG Size должен отражать добавление физического тома.

C. Расширьте логический том:

lvextend -L +200G /dev/mapper/vg_backup-lv_backup

Замените +200G значением, на которое хотите расширить логический том.

Убедитесь, что lvextend выполнена успешно:

lvdisplay

LV Size должен отражать произведенное расширение.

D. Измените размер файловой системы, чтобы он соответствовал логическому тому:

resize2fs /dev/mapper/vg_backup-lv_backup

E. Убедитесь, что новый размер отражается в точке монтирования:

df -h /path/to/mount/point 

На этом все! Разве не сильно проще, чем переносить все данные на новый диск?


ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/564442/

Стартапы для медицины: российские проекты

В России работает около 700 000 врачей. Эти люди ежедневно и круглосуточно помогают людям. И медицина – одна из областей, которые требуют постоянного внедрения новых технологий. Среди технологий, которые помогают врачам работать и учиться, есть такие направления, как:

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

  • VR и AR платформы, которые помогают студентам учиться, а действующим врачам – тренировать свои навыки,

  • Маршрутизация для транспорта, позволяющая быстрее доставить пациентов в стационар.

Мы сделали подборку проектов для медиков (и, конечно, их пациентов), которые мы получили на интенсив «Архипелаг 2121». Напишите в комментариях, какие из этих проектов, на ваш взгляд, особенно интересны.  

Гиппократ

По данным команды стартапа, 10 раз в год каждый житель РФ встречается с врачом. При этом:

1. Врачи пропускают клинически важную информацию

2. 30% ошибочных диагнозов

3. 50% заболеваний выявляются на поздней стадии

4. Существующие сервисы врачу не помогают, потому что:

  • неполнота данных

  • неудобство в использовании

  • недостоверность информации

  • невыгодно приобретать

Система поддержки принятия врачебных решений Гиппократ — это инструмент для диагностики и лечения заболеваний.

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

Paithology

Ассистент врача патолога помогает во время микроскопического скрининга или диагностики патологических процессов.

Программа с помощью нейросетей классифицирует процессы по морфологической картине в гистологическом, цитологическом, иммуногистохимическом или цитогенетическом микропрепарате.

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

Разработка обучающего виртуального эмулятора по рентгенологии

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

Функционал разрабатывают с применением технологий ИИ: одна нейронная сеть генерирует снимки, а другая их распознает, с применением генеративных конкурентных сетей по типу GAN.

Система оценки нейрохирургического вмешательства

Сегодня болезнь Паркинсона – это одно из наиболее распространенных экстрапирамидных заболеваний с распространенностью до 80% от числа всех нейродегенеративных заболеваний.

Цель проекта – уменьшить шанс врачебной ошибки и снизить себестоимость персонализированной реабилитации за счет уменьшения длительности и точности выбора действий лечающего врача.

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

Виртуальная клиника

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

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

Возможно и удаленное обучение.

Кардионет

Проект IT-маршрутизации скорой помощи за счет внедрения современных технологий позволит сократить время доставки пациентов с инфарктом миокарда в стационар.

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

Реализация данного проекта на территории всей РФ позволит сохранять более 1 350 человеческих жизней ежегодно.

На участие в Архипелаге 2121 мы получили около 15 000 заявок. С проектами, которые представили участники интенсива, вы можете познакомиться на Витрине.

ссылка на оригинал статьи https://habr.com/ru/company/2035_university/blog/565540/

Программирование ESP32 с использованием JTAG программатора ESP-Prog и ESP-IDF

ESP-Prog

Всем доброго времени суток. На просторах Али можно найти такой программатор, как ESP-Prog, на чипе FTDI2232H, с виртуальным COM-портом на борту:

image

Среда разработки

Как IDE мы будем использовать Visual Studio с плагином VisualGDB. Данный плагин предназначен для разроботки ПО для микроконтроллеров, имеет встроенный OpenOCD, который, в большинстве случаев, не надо вручную отлаживать или конфигурировать.

Программируемый микроконтроллер

Нашим таргетом будет ESP-DevKit_V4, с ESP32-WROOM-32D:

image

Установка драйверов для ESP-Prog

Скачиваем с официального сайта драйвера, устанавливаем через диспетчер устройств, «Установить драйвер» — «Искать драйвера на этом компютере», выбираем папку с распакованными драйверами.

Дальше нам понадобится программа Zadig, скачиваем, запускаем. Видим окно:

image

в меню «Options» выбираем «List All Devices», и если драйвера для FTDI2232H установлены правильно, из списка устройств выбираем «Dual RS232-HS (Interface 0)», А в меню «Driver» выбираем «WinUSB». Должно получиться так:

image

Реинсталим драйвер, при успешном завершении извлекаем программатор от ПК и засовываем обратно.

Подключение программатора к микроконтроллеру

На задней части программатора есть информация про выводы.

Подключаем по схеме:

image

image

а питание для ESP32 будем брать с другого порта, так как с одного порта мощности для программатора и ESP32 не хватит.

Настройка дебагера

Запускаем Visual Studio с уже установленным VisualGDB. Жмём «Start new project», там выбираем ESP32/ESP8266 IDF/ADF Project Wizard:

image

Жмём «Next»

image

Выбираем тулчейн, он установится автоматически:

image

Тут мы выбираем экзампл, К примеру «softAP»:

image

Жмём «Next»

В данном окне мы настраиваем сам дебагер, ставим все как тут, тестим:

image

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

image

Жмём «Finish», ждём окончания генерации проекта.

Тестирование в Debug Mode

Компилируем код, ставим брейкпоинт, нажимаем в меню «Debug» — «Start debugging with VisualGDB», ждем окончания загрузки прошивки на ESP32, и дебажим:

image

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

Заключение

Мы получаем легкий способ отладки ESP устройств, не нуждающийся в глубокой настройки, плагин все делает сам.

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

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

ссылка на оригинал статьи https://habr.com/ru/post/565544/

Proxmox 7.0 beta 1: обзор основных изменений

24 июня стала доступна первая бета-версия популярной системы виртуализации с открытым исходным кодом Proxmox 7.0. Сегодня посмотрим, какие кардинальные изменения будут представлены в будущем релизе.

Разумеется, мы ни в коем случае не пытаемся заменить полный changelog, его можно в любой момент посмотреть на официальном сайте Proxmox VE. Но нам было важно рассмотреть ключевые изменения, так что добро пожаловать под кат — мы все изучили и излагаем результаты собственных наблюдений.

Инсталлятор


Для начала взглянем на изменения в инсталляторе. Визуально он никак не изменился, все те же привычные действия и значения. Главное изменение — функциональное, это переход с chroot на switch_root. Оно улучшает загрузку модулей и прошивок, а также слегка снижает потребление ОЗУ во время установки.

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

Временная файловая система initrd и образы squashfs используют механизм сжатия без потерь Zstandard, а набор утилит BusyBox обновлен до версии 1.33.1. Небольшому тюнингу подверглась система работы с ISO-образами, в частности улучшена поддержка ISO-образов с флешек USB3, а также увеличено время распознавания медленных устройств (таймаут увеличен с 20 до 45 секунд).

Веб-интерфейс

Главное окно веб-интерфейса Proxmox VE 7.0 beta 1

Серьезным изменениям подвергся и веб-интерфейс, в частности:

  • в заметках теперь можно использовать Markdown, который будет правильно отображаться и позволит лучше структурировать все заносимые данные;
  • при создании бэкапов вручную появилась возможность задавать ограничения для политик хранения резервных копий на целевом хранилище;
  • на экране обзора хранилища используется международная система единиц СИ (по основанию 10) и теперь цифры соответствуют генерируемым графикам;
  • появилась возможность применять аппаратные ключи безопасности, такие как YubiKey в качестве ключей SSH при создании контейнеров или cloud-init образов;
  • корректное отображение групп IOMMU при добавлении устройств PCI в гостевые машины с QEMU;
  • улучшен перевод интерфейса с арабского, французского, немецкого и польского языков.

Пример заметки, отформатированной в Markdown

Базовая система


Переходим к тому, что изменилось внутри системы виртуализации. Самым значимым изменением новой версии Proxmox станет переход на Debian 11 «Bullseye» на ядре 5.11, стабильный релиз которого выйдет в конце 2021 года. Задействуется актуальная версия QEMU 6.0, о которой мы рассказывали здесь, на Хабре, пару месяцев назад, так что теперь для всех вновь запущенных или мигрированных гостевых систем будет применяться фича io_uring (асинхронный механизм IO).

Если же для диска требуется вернуть предыдущий режим работы, то исправить это можно командой:

qm set VMID --DRIVE EXISTING-DRIVE-OPTS,aio=native

Обновился и набор инструментов для контейнеризации приложений — LXC теперь имеет версию 4.0, с полной поддержкой cgroups2, механизма для иерархической организации процессов и распределения системных ресурсов. Разумеется, не обошли стороной и активно продвигаемую файловую систему ZFS — ее версия обновлена до 2.0.4.

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

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

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

Еще из важных изменений: теперь не потребуется устанавливать вручную ifupdown2, требуемый при применении сетевых параметров без перезагрузки хоста. В Proxmox 7 beta 1 этот пакет устанавливается «из коробки». При всем этом первая версия пока также поддерживается, но, вероятно, будет удалена в будущих релизах.

Проблемы бета-версии


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

  • непреднамеренное изменение имен сетевых интерфейсов, в частности на сетевых картах Mellanox;
  • генерация MAC-адресов на основе имени интерфейса и machine-id системы может привести к тому, что в рамках одной сети могут возникнуть коллизии, связанные с появлением одинаковых MAC-адресов, поскольку хосты с Proxmox VE (с версии 4.0 и до версии 5.4) могут иметь неуникальные machine-id.

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

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

Пара советов от Капитана Очевидность


Обязательно организуйте резервный канал управления серверами, например посредством IPMI или IP-KVM, так как возможна ситуация с потерей доступа к SSH-консоли. Перед выполнением апгрейда обязательно проверьте текущие политики резервного копирования и восстановления, приведите их в соответствие с изменившейся логикой поведения гипервизора.

Не используйте бета-версии в продакшне, ничем хорошим это не кончится. Мы предупредили 🙂

ссылка на оригинал статьи https://habr.com/ru/company/selectel/blog/565542/