Практические шаги к InnerSource
Концепция InnerSource предполагает реализацию принципов Open Source в границах одной компании. Она оказалась весьма востребованной для многих предприятий, в том числе не имеющих отношения к ИТ, поскольку позволяет добиться определённых организационных преимуществ.
Основатель проекта Jono Bacon Consulting Джоно Бэкон часто выступает в роли консультанта, помогая различным организациям выстраивать внутренние и внешние сообщества. Опираясь на свой опыт он представил на сайте OpenSource.com модель, которая показывает, какие шаги необходимо сделать руководителю программы реализации концепции InnerSource в компании.
Подготовительный этап
Эксперт отдельно подчёркивает, что InnerSource — прежде всего изменение культуры компании, а не корректировка процесса разработки программного обеспечения. Это создание адекватной во всех отношениях среды для совместной деятельности. Разумеется, процесс включает и развитие разработки, но не ограничивается только им.
Главная же проблема изменений культурной среды определяется тем, что сама культура — аморфная категория, включающая в себя идеи, взгляды, привычки, страхи, мечты, ценности и многое другое. Из этого вытекает, что не понимающий существующую культуру человек не сможет её изменить.
Внедрение InnerSource должно начинаться с понимания существующей инфраструктуры и коммуникационных процессов. Они включают в себя хостинг кода, рецензирование, автоматическое тестирование, непрерывную интеграцию, создание документации, базы знаний, программы стимулирования и многое другое.
Руководитель программы должен понимать эту систему до мельчайших деталей. Бэкон рекомендует разбить организацию на команды и собрать по каждой из них следующую информацию:
· какие ресурсы потребляет команда;
· что производит команда;
· как работает команда;
· как команда взаимодействует с другими командами;
· достоинства и недостатки существующей системы.
Компания — это множество людей со своими целями, личными особенностями и точками зрения. Любые изменения культуры происходят в реальной среде, сформированной этими людьми. Невозможно реализовать InnerSource-программу через диктат — такой путь практически наверняка завершится неудачей.
Для лучшего понимания существующих в компании реалий эксперт предлагает использовать следующую схематизацию:
· основные заинтересованные стороны и лица, принимающие решения;
· рабочие команды и ключевые сотрудники;
· отдельные сотрудники, их внутренние и внешние мотивации.
Составление плана
После того, как у руководителя программы появилось ясное понимание текущей ситуации, можно приступать к составлению дорожной карты. Первый шаг — определение общей стратегии, что значительно сложнее, чем кажется на первый взгляд. Интеграция принципов Open Source включает в себя вмешательство в рабочие процессы, инфраструктуру, коммуникации, корпоративную политику (например, открытость и прозрачность), управление и многое другое.
Чтобы план получился реалистичным, следует иметь в виду, что приоритеты будут меняться, поскольку у компании наверняка есть другие проекты, причём более важные, чем реализация InnerSource. Также не нужно рассчитывать на большие ресурсы и единодушную поддержку со стороны руководителей и коллег — наверняка многим не понравятся грядущие перемены, поскольку перемены вообще мало кому нравятся.
Таким образом, задача сводится к выполнению следующего:
· реализация возможных особенностей каждой из этих частей.
Бэкон рекомендует сначала составить общий план на ближайшие один-два года, охватывающий основные направления деятельности. А потом разбить этот план на более короткие периоды с конкретными ключевыми целями и практическими показателями.
По сути, стратегия — это всего лишь карта, которая только указывает конечную цель. Для практического воплощения она должна быть преобразована в цепочку конкретных проектов, требующих определённых ресурсов. Причём каждая стратегическая цель порождает множество субпроектов, что усложняет привлечение ресурсов.
Лучшим способом решения возможной проблемы эксперт считает тотальное резервирование. Лучше выбиться из графика, чем начать реализацию необеспеченного ресурсами проекта.
Одна из серьёзных задач этапа планирования заключается в достижении понимания того, как выглядит успех от реализации InnerSource. Допустим, компания заинтересована в повышении эффективности работы программистов, но когда дело доходит до проверки кода, сразу становится непонятно, каким образом измерить эффект от инновации.
Если не будут выработаны единые критерии оценки, то проблема будет усугубляться различным отношением к ней со стороны рабочих групп, на которых реализация проекта оказывает влияние — у них могут быть разные представления об успехе. Руководство же, как правило, не имеет желания вникать в детали, предпочитая получать общую информацию о наиболее важных тенденциях.
Для упрощения решения проблемы Бэкон рекомендует использовать т. н. «модель зрелости», согласно которой каждому этапу соответствует определённый хронологический статус:
· решение оптимизируется и совершенствуется.
Соответственно, для каждого статуса определяется ожидаемый результат. Например, результатом статуса изучения могут быть осуществляемые некоторыми рабочими группами эксперименты с некритическими участками кода.
Реализация программы
Если ранее выполнялась хоть и важная, но «незаметная» работа, то от успеха начального этапа реализации зависит всё будущее проекта. Поэтому выбор его имеет важнейшее значение. Исходить следует, разумеется, из доступных ресурсов, иначе получится авантюра.
Актуальность этапа тоже важна, но в меньшей степени. Лучше успешно закончить не самый значимый субпроект, чем громко провалить приоритетный.
При реализации InnerSource-программы важно постоянно поддерживать связь с различными группами, что само по себе положительно влияет на её успех, поскольку именно коммуникации — одна из базовых составляющих концепции.
При этом руководитель программы должен постоянно отслеживать следующую информацию по всем заинтересованным сторонам:
· понимание плана работы;
Только важно иметь в виду, что различные рабочие группы имеют различные коммуникационные потребности. Высшее руководство интересует только общие результаты, а лидеры групп требуют важных для них деталей.
Очевидно, что обеспечение всех заинтересованных сторон необходимой информацией лежит на руководителе программы. Причём крайне желательно постепенно переводить коммуникации из «ручного режима» в системный, когда обмен данными осуществляется без непосредственного участия какого-либо одного заинтересованного лица. Тем более, что это одна из составных частей концепции InnerSource.
Итоги и улучшения
Реализация InnerSource — процесс, который не имеет конца. Этим он чем-то похож на внедрение ПО, нуждающегося в постоянном сопровождении и поддержке. Да и сама компания — не застывшая система. Она постоянно меняется и используемый когда-то подход должен постоянно обновляться, для чего нужна действующая система мониторинга.
Бэкон предупреждает, что и в этом случае важную роль будут играть нетехнические аспекты. Все сотрудники предприятия прекрасно понимают, что под термином «мониторинг» подразумевается самый обычной контроль. А это всегда вызывает страх, причём сколько-нибудь формализованного способа борьбы с ним не существует.
Основа системы мониторинга — сбор количественных данных. Для каждого проекта определяется набор показателей, значение которых свидетельствуют об уровне благополучия. Эксперт подчёркивает важность этой задачи — если нет цифр, то нет и контроля.
Однако несмотря на безусловный приоритет измеряемых показателей нельзя пренебрегать и обычным человеческим фактором. Для его оценки следует регулярно проводить опросы сотрудников (желательно на анонимной основе), в которых они могут высказать своё мнение о уровне комфорта в работе.
Очевидно, если какие-либо показатели выходят за рамки допустимых, следует срочно вносить изменения в конкретную реализацию InnerSource. Причём по примерно такой же схеме, которая использовалась при внедрении концепции.
InnerSource: Open Source для внутреннего потребления
В последние годы получила распространение концепция InnerSource. Она предполагает использование принципов Open Source в одной организации. Иными словами, в рамках этой модели выстраивается сообщество, но только из сотрудников компании, в результате чего права на код остаются за ней.
Автор труда «The Art of Community» и основатель проекта Jono Bacon Consulting Джоно Бэкон на страницах сайта OpenSource.com рассказывает, что уже работает с предприятиями, выстраивающих внутри себя InnerSource-сообщества. По первым итогам этой деятельности он смог сформулировать несколько важных принципов, которыми делится с читателями.
Сначала культура, потом код
Как правило, в большинстве компаний InnerSource начинается с пилотного проекта. Это разумно, поскольку позволяет не только увидеть практическую отдачу от методики, но и получить определённый опыт, на который можно будет опираться при расширении сферы применения концепции.
Обычно в проекте принимают участие несколько конкретных команд, совместная деятельность которых будет наиболее показательна при подведении итогов эксперимента. Таким образом, InnerSource — это прежде всего некий новый рабочий процесс, требующий определённой культурной адаптации. Именно она является самой большой проблемой, но одновременно с этим — и ключом к успеху.
Существует ошибочное мнение, что самое важное для InnerSource заключается в создании жизненного цикла разработки ПО в конкретной компании. А именно, организация хранилищ и каналов связи, анализ кода и непрерывная интеграция вкладов. Безусловно, всё это играет существенную роль.
Однако Бэкон уверен, что эти составляющие — примерно то же самое, что элементы конструктора Lego. Истинный же смысл InnerSource заключается в создании стимулов для людей, создающих из «кирпичиков» невероятные вещи.
Таким образом, InnerSource — прежде всего создание определённой рабочей среды, в которой может быть реализована культура Open Source, ведь именно она включает в себя систему стимулов, ассоциирующихся прежде всего с открытым исходным кодом. Построение подобной культуры в традиционных организациях — очень непростая задача.
Основная сложность заключается в том, что культурные изменения не могут происходить по команде сверху. Они являются результирующей отдельных действий людей, создающих социальные конвергенции, объединяющие отдельных специалистов в организованные группы. Для решения этой задачи руководителям компании следует смотреть на проблему глазами рядового персонала и понять, как сделать их деятельность более эффективной и полезной при неформальном сотрудничестве.
Очевидно, что какие-то конкретные рекомендации в данном случае невозможны. Создание сообщества внутри организации — всегда творческий процесс, учитывающий как специфику деятельности компании, так и сложившуюся в ней систему взаимоотношений. Впрочем, некоторые предметные советы эксперт всё-таки даёт.
Разработка методологии
Несмотря на то, что InnerSource — относительно новая концепция, к ней вполне применимы некоторые проверенные методики, давно практикуемые сообществом Open Source. Разумеется, с некоторыми оговорками и уточнениями.
Бэкон утверждает, что видел и хорошие, и плохие способы реализации InnerSource в различных организациях. Одни практикуют сугубо «корпоративный» подход к решению проблемы: сотрудникам объявляется о начале работы по новому методу в соответствии с заранее составленным и утверждённым графиком. Другие предпочитают инициировать инициативу снизу, когда специально сформированная группа пытается неофициально вовлечь людей в проект.
По всей видимости, оптимальным методом будет некая комбинация вышеназванных. Любое изменение внутрикорпоративной культуры нуждается в явной поддержке сверху и поощрении практикующих новый подход сотрудников. Однако вместо диктата правил руководство компании должно прежде всего формировать среду, в которой работники могут самостоятельно начинать работать в соответствии с концепцией InnerSource.
Эксперт предлагает руководителям компаний не обманывать самих себя — сотрудникам никогда не нравятся внедряемые сверху изменения. Никто не любит, когда вместо системы поощрений для формирования новой культуры начальство действует посредством приказов, обязывающих людей к каким-либо действиям, смысла которых они могут не понимать.
Чтобы максимально использовать преимущества обоих путей, Бэкон рекомендует использовать циклы. Перед завершением каждого цикла лидеры команд проводят опрос сотрудников, в котором им предлагается высказать своё мнение о реализации программы. На основе полученных данных руководство компании вносит необходимые коррективы в проект и определяет цели следующего периода.
Таким образом, участники команд могут не просто разрабатывать код, но и непосредственно влиять на проект в целом. Что, в свою очередь, позволяет достигнуть разумного компромисса между принятой в корпорациях жёсткой должностной иерархией и принципами Open Source, предполагающими значительно большую демократию.
Удалённость и асинхронность
Наиболее интересная проблема, которую предстоит решить при внедрении InnerSource-модели, заключается в вовлечении в проект сотрудников удалённых подразделений, которые могут находиться в другом часовом поясе. Именно тут требуется вносить наиболее заметные изменения во внутреннюю корпоративную культуру.
Как правило, большинство компаний предпочитает очный стиль работы: все ходят в офис, проводят встречи в конференц-залах, принимают решения на совещаниях. В крайнем случае с удалённым сотрудникам проводят сеанс видеосвязи. Однако это плохо сочетается с принципами Open Source, предполагающими максимально широкое вовлечение в проект.
Если слепо переносить корпоративные принципы на InnerSource, то команды будут формироваться «по офисам», что совершенно неэффективно, поскольку автоматически вычёркивает из разработки потенциально полезных специалистов компании, работающих в других городах. В то время как проекты Open Source уже давно и успешно функционируют в асинхронном режиме, при котором место и часовой пояс участников не имеет никакого значения.
Бэкон рассказывает, что такие банальные для любого свободного проекта вещи оказываются серьёзной проблемой для традиционных компаний. Руководство зачастую отказывается понимать, что можно решать какие-то вопросы не на очной встрече или анализировать код не на доске в конференц-зале. По этой причине в корпоративной инфраструктуре попросту отсутствуют средства для асинхронной работы.
Очевидно, что эта проблема может решаться только сверху, поскольку требует внесения изменений в инфраструктуру компании. В результате помимо возможности применения InnerSource организация получает среду, поддерживающую удалённую работу. Что, в свою очередь, существенно расширяет её кадровый потенциал.
Экспертиза в рабочем процессе
У Open Source есть два важных принципа. Во-первых, вклад любого участника рассматривается другими разработчиками, которым предлагается найти недостатки и исправить их. Во-вторых, экспертиза (как процесс, так и результат) открыта для всех.
В корпоративной среде это может привести к некоторым проблемам. Например, если код принадлежит формальному начальнику, то подчинённые могут решить, что в данном случае от критики лучше воздержаться. В результате, экспертиза либо не проводится совсем, либо проводится кулуарно.
Этим процессом следует управлять особенно тщательно. Критический анализ — это часть культуры Open Source, которая наиболее эффективно влияет на качество разработки. Необходимо организовать процедуру так, чтобы ни одна из сторон не ощущала дискомфорта, понимая, что в конечном счёте всё осуществляется исключительно для пользы дела.
При этом необходимо учитывать две особенности. Во-первых, каждому участнику свойственно преувеличивать значение и размер своего вклада. Во-вторых, если человек ощущает, что не может полностью контролировать собственное будущее, то он чувствует себя скованно и не может максимально реализовать свой потенциал.
Таким образом, экспертная оценка должна использоваться для объективной оценки вклада каждого участника InnerSource-проекта, независимо от его формальной должности. Любое изменение и дополнение следует рассматривать минимум двум рецензентам. При этом обратная связь организуется таким образом, что разработчик имеет возможность постоянно улучшать свой код, сохраняя контроль над конечным результатом.
Стимулирование участников
Ещё один важнейший элемент InnerSource-культуры заключается в способах оценки результатов работы и поощрения наиболее активных и результативных участников. Очевидно, что без должного стимула проект сам собой сойдёт на нет.
Бэкон выделяет три момента, на которые следует обратить внимание руководству компании.
Во-первых, нужен способ получения количественного представления эффективности работы каждого человека. При этом оцениваться должны их реальные заслуги, а не то, как часто они мелькают перед глазами начальства и демонстрируют ему собственную бурную деятельность.
Во-вторых, на основе этого представления следует обеспечить участникам InterSource-команд какие-то стимулы и дополнительные выгоды. Они могут быть либо материальными (деньги, футболки, подарочные карты и т. д.) или моральными (публичное признание заслуг, уважение, восхищение и т. п.). Поскольку и то, и другое одинаково важно, руководство компании должно сочетать виды поощрений.
Технический подход к пониманию интерфейсов мозг — компьютер
Пересечение медицины и науки о данных всегда было актуальным; возможно, самый очевидный пример — реализация нейронных сетей в глубоком обучении. По мере развития науки о данных и машинного обучения будет развиваться и медицина, но верно и обратное.
Нанотехнологии, стволовые клетки, оптогенетика, метаболомика, редактирование генов и интерфейсы мозг — компьютер — вот лишь некоторые области, выигрывающие от взаимовыгодных отношений медицины и науки о данных, представители которых должны научиться расти и адаптироваться к эволюции в своей сфере — иначе они рискуют остаться позади. К старту курса по Machine Learning и Deep Learning делимся статьёй о возможностях пакета MNE для визуализации данных о мозге. По словам автора — нейрохирурга и спикера TEDx — как только MNE будет сопряжён с TensorFlow, sklearn или другой библиотекой машинного обучения, в интерфейсы мозг — компьютер сможет погрузиться любой человек.
Мозг интригует почти каждого, кто его рассматривает; он одновременно двусмыслен в своей запутанности и конкретен — в действии. Кроме того, сложность мозга требует изобретательности и творческого подхода при его изучении.
В своей предыдущей статье «Введение в интерфейсы мозг — компьютер»¹ я подробно описал некоторые сложности мозга и связанные с ними нейротехнологии. В этих сложностях бывает трудно разобраться, но определённые инструменты позволяют практически любому человеку работать с данными нейровизуализации и воспроизводить научные эксперименты².
Эта библиотека очень полезна для визуализации многих этапов, используемых в различных системах интерфейсов мозг — компьютер, и для лучшего понимания этой развивающейся технологии. Рассмотрим возможности MNE и работу с наборами данных для тестирования этих возможностей.
1. Импорт модулей
Люди с опытом больше наверняка знакомы с Jupyter Labs и Anaconda, с которыми и следует работать при использовании MNE. Загрузка Anaconda и последующая установка MNE позволят вам использовать Jupyter Labs на localhost и значительно упростят программирование. При выполнении программы в Jupyter Labs вы можете разбить свой код на блоки, которые можно выполнять независимо друг от друга; это гораздо удобнее подхода типичных IDE.
Однако, как только программа будет готова, вы можете перенести её в IDE по выбору (убедитесь, что установили MNE в виртуальном окружении, если вы используете его) и запустить программу. Когда я переносил программу, то столкнулся с несколькими проблемами, в основном они решались загрузкой и импортом нескольких модулей.
Я не был знаком с picard, surfer или sobol_seq, но они были необходимы для построения некоторых используемых графиков.
Седьмая строка: from mne.datasets import sample, собирает фундаментальный набор данных, используемый для изучения MNE. В этом наборе данных уже есть информация, чтобы любой человек мог начать работать с MNE. К сожалению, некоторые задачи, поставленные перед людьми, которые отдали свои данные для набора, были простыми, но в MNE есть множество встроенных наборов данных⁴.
Модуль mne_bids⁵ не использовался в моём коде, но это важная часть MNE, которая задействована в большей части кода.
Поскольку он очень полезен, я, конечно, решил не использовать его. Это упростит жизнь…
Этот модуль совместим со структурой данных визуализации мозга (BIDS)⁶, то есть с типичным способом организации нейрофизиологических данных. В частности, он определяет следующее:
Как присваивать имена файлам.
Где размещать файлы в каталоге.
Какие дополнительные метаданные следует хранить.
Папка out_data уже существует, в ней создаётся sample_BIDS с необходимой информацией о пациенте. События и event_id мы определили ранее.
2. Импорт необработанных данных
После того как мы импортировали данные нашей выборки, можно импортировать исходную информацию, которая будет необходима для дальнейшего анализа.
После создания пути данных и навигации по данным мы можем построить их различными способами.
Рисунок необработанных данных с датчиков МЭГ Рисунок необработанных данных с датчиков ЭЭГ и ЭОГ и каналов стимулов
Создаваемый график интерактивен, это сильно облегчает жизнь. Например, электрод ЭЭГ 053 выглядит как выброс, который я не хочу видеть в составе своих данных. Я могу просто щёлкнуть канал, щелчок пометит его как «плохой». Если вы хотите увеличить масштаб данных, достаточно использовать функциональную клавишу и клавиши со стрелками (по крайней мере на mac).
Я также могу нанести электроды на модель головы. Следует отметить, что изображение, созданное с помощью Jupyter Labs и PyCharm, было другим. PyCharm применялся для создания изображения ниже, но некоторые датчики, кажется, немного смещены.
Ничего страшного, если датчики не находятся непосредственно на голове — это означает, что они могут быть на ушах, шее или где-то ещё, однако это необходимо учитывать при построении графиков.
Рисунок электродов ЭЭГ. Красный электрод — это канал, ранее отмеченный как плохой (ЭЭГ 053)
Также можно создать 3D-модель.
Изображение 3D-модели электродов ЭЭГ
Нижняя часть приведённого выше кода была посвящена поиску различных событий на основе каналов стимулов. Событиям, которые были обнаружены MNE, присвоены номера 1, 2, 3, 5 и 32. Эти номера связаны с конкретным стимулом — благодаря документации MNE были найдены и обозначены правильные стимулы. Я использовал эту информацию, чтобы создать график сырых данных с аннотациями при помощи датчиков ЭЭГ.
Рисунок нефильтрованных данных ЭЭГ с помеченными стимулами.
Общее количество слуховых событий составило 145, а общее количество зрительных событий — 144.
3. Фильтрация необработанных данных и построение спектральной плотности мощности
Прежде чем двигаться дальше, отфильтруем данные, чтобы они выглядели намного чище и их проще было анализировать.
Я использовал фильтр низких и высоких частот с частотами 40 Гц и 0,1 Гц. Частоты ниже 40 Гц и выше 0,1 Гц сохранены, другие — удалены. Используемые частоты будут различаться в зависимости от эксперимента, но эти значения для данного набора — это хорошие значения по умолчанию.
Рисунок отфильтрованных данных ЭЭГ с обозначенными стимулами
После получения нефильтрованных и фильтрованных данных я могу построить график спектральной плотности мощности сигнала (далее — PSD ), полученного от разных электродов. PSD — это мощность сигнала как функция частоты, по частотам
График PSD, полученный от электродов ЭЭГ до и после фильтрации. Нижний график гораздо чище и анализируется проще, чем верхний
4. Эпохи и вызванная информация
Как уже упоминалось в предыдущей статье, эпохи — это просто сегментация данных на несколько различных частей. Вызванные объекты — это усреднённые сигналы нескольких эпох ЭЭГ или МЭГ, такая стратегия обычна при оценке вызванной стимулом активности.
Изображение отфильтрованных по эпохе данных ЭЭГ для визуальных стимулов
Хотя я продолжаю использовать данные ЭЭГ, в этом нет необходимости. Можно также использовать исходные необработанные данные с информацией о МЭГ и разделить данные на эпохи. В дальнейшем их можно очистить с помощью независимого компонентного анализа (ICA). Чтобы использовать исходные необработанные данные, вместо raw_eeg_filtered я задействую raw.
Изображение исходных необработанных данных, помещённых в эпоху
Я также могу построить график вызванных данных относительно каждого метода получения данных.
Рисунок различных методов получения информации после разделения на эпохи и усреднения, чтобы найти вызванную информацию
Топокарта также может быть создана с использованием вызванных данных для просмотра напряжения на различных участках головы от начала до конца эпохи.
Топокарта напряжения на различных электродах ЭЭГ на коже головы
Я также могу сравнить вызванную информацию связанных с различными стимулами эпох.
Рисунок сравнения слуховой и зрительной вызванной информации
4. Применение независимого компонентного анализа (ICA)
Как объяснялось в моей предыдущей статье, ICA — это метод, используемый для очистки эпох, не входящий в состав основных методов фильтрации, применяемых к исходным данным. С помощью ICA можно найти и устранить определённые артефакты, включая улавливаемые электродами компоненты ЭОГ и ЭКГ.
Оператор if нужен только для того, чтобы эта часть кода не запускалась каждый раз в IDE. Это излишне в Jupyter Labs, но удобно после того, как очищенные эпохи уже сохранены: значительно сокращается время выполнения.
Изображение нескольких различных компонентов ICA
После применения ICA мы можем просмотреть эпохи до и после.
Изображение за несколько эпох до ICA Изображение эпох после ICA
Мы также можем просмотреть оценки компонентов ICA. Это позволяет определить, какие компоненты с наибольшей вероятностью связаны с различными артефактами.
Изображение оценок компонентов ICA
Одним из компонентов, который показал высокую вероятность связи с артефактом, был компонент 001, его можно проанализировать.
Изображение ICA001
Мы также можем просмотреть эпохи до и после очистки другим способом, то есть просмотреть сигнал для каждого метода сбора до и после применения ICA.
Изображение методов получения сигнала до и после применения ICA
5. Временно-частотный анализ
Временно-частотный анализ также возможно сделать через MNE, но я использую эту функцию не так часто. Однако особенно интересная часть этого этапа для меня — просмотр наличия различных мозговых волн на разных частях черепа. На основе найденной частоты можно определить различные мозговые волны.
Изображение трех различных типов мозговых волн после применения ICA
6. Визуализация данных сканов МРТ и датчиков ЭЭГ
Один из самых интересных моментов в MNE заключается в том, что источник сигнала можно отследить, выполнив несколько шагов. Эти шаги включают следующее:
Энергетический метаболизм мозга.
Расчёт прямого решения.
Изображение из MNE на различных этапах оценки источников
Приведённый ниже код иллюстрирует некоторые шаги, которые необходимы MNE для запуска протокола локализации источника. Опять же пример данных содержит всё необходимое для выполнения этих шагов при условии, что вы перейдёте в нужную директорию. Многие переменные, которые я использовал, можно заменить. Например, последняя переменная, brain, имеет поверхность pilal, но изображение, как в начале этой статьи, может быть сгенерировано, если установить поверхность inflated.
Снимки МРТ испытуемых Изображение макета пациента с датчиками ЭЭГ и шлемом МЭГ Изображение сгенерированной исходной локализации с использованием образца данных
Локализация источника правосторонней визуальной информации дала изображение, показывающее активность в левой затылочной доле и некоторую временную информацию. Также наблюдается некоторая подкорковая активность вблизи таламуса (который передаёт сенсорную информацию.)
Заключение
[1] Gulamhusein A. An introduction to brain-computer interfaces [Internet]. Medium. Geek Culture; 2021 [cited 2021Aug1].
[2] Gramfort A, Luessi M, Larson E, Engemann DA, Strohmeier D, Brodbeck C, et al. MEG and EEG data analysis with MNE-Python [Internet]. Frontiers in neuroscience. Frontiers Media S.A.; 2013 [cited 2021Aug1].
[3] Python homepage¶ [Internet]. MNE. [cited 2021Aug1].
[4] Datasets overview¶ [Internet]. Datasets Overview — MNE 0.24.dev0 documentation. [cited 2021Aug1].
[5] Appelhoff S, Sanderson M, Brooks TL, Vliet Mvan, Quentin R, Holdgraf C, et al. MNE-BIDS: Organizing ELECTROPHYSIOLOGICAL data into the Bids format and facilitating their analysis [Internet]. Journal of Open Source Software. 2019 [cited 2021Aug1].
[6] Holdgraf C, Appelhoff S, Bickel S, Bouchard K, D’Ambrosio S, David O, et al. iEEG-BIDS, extending the brain imaging data Structure specification to human Intracranial electrophysiology [Internet]. Scientific data. Nature Publishing Group UK; 2019 [cited 2021Aug1].
MNE-Python — это невероятный инструмент, но он — только один представитель мира интерфейсов между мозгом и компьютером. Эта статья не учебник, она даёт обзор возможностей MNE и некоторых протоколов, которые можно легко просмотреть при помощи небольшого количества данных. Изучение мозга — также только одно приложение науки о данных из огромного количества возможных приложений. Если вы хотите стать специалистом в области, которая сегодня находит применение почти везде, приходите на наши курсы по Machine Learning, флагманский курс по Data Science или курс по аналитике данных. Также вы можете узнать, как начать карьеру или выйти на новый уровень в других направлениях:
Data Science и Machine Learning
