Каково быть создателем популярной библиотеки с открытым исходным кодом? Конечно, помогать большому количеству людей по всему миру - это здорово, но разве вас не перегружает объем работы? Как с этим справиться? Сколько работы можно делегировать другим?
Мишель Вестстрат знает все: его библиотека MobX насчитывает более 17 000 звезд на GitHub и более 100 участников. Еще в 2018 году он был основным докладчиком на HolyJS, и члены программного комитета HolyJS Дмитрий Махнев и Евгений Кот задавали ему много вопросов об open source в целом, MobX в частности, а также о конференциях. Тогда мы опубликовали это интервью на русском.
Теперь мы рады сообщить, что Мишель снова приедет на HolyJS - и мы решили опубликовать это интервью на английском языке. Кое-что изменилось с 2018 года (сейчас Мишель работает на себя), но большинство ответов по-прежнему актуальны.
- Для тех, кто вас не знает, не могли бы вы рассказать нам немного о себе?
Мишель: Конечно. Меня зовут Мишель Вестстрат, для большинства людей это слишком сложно произнести. Я из Нидерландов. Большинство людей знают меня по моей работе над MobX или Immer. На самом деле я работаю в компании под названием Mendix. В основном мы создаем программное обеспечение для создания программного обеспечения, поэтому у нас есть студия разработки приложений, которую используют многие консалтинговые фирмы и т. Д. Мы автоматизировали многие крупные страховые компании банков и подобные системы.
Я занимаюсь технической стороной дела, это в основном то, что мне нравится делать. Я окунулся в мир открытого исходного кода около двух лет назад, и с того момента я довольно активен, в основном в сообществе React и сообществе JavaScript в целом.
- Чем вы занимаетесь в Mendix? Насколько я понимаю, вы технический руководитель.
Мишель: Я ношу там несколько разных головных уборов, и самая важная из них действительно принадлежит техническому руководству. Это означает, что я в основном отвечаю за принятие (или координацию) технических решений для одного из наших племен. Я работаю над продуктом, о котором упоминал ранее, это приложение на основе браузера, и я много участвую в создании правильных ограничений или выборе правильной технологии. И я все еще занимаюсь программированием в этой области.
Я также участвую в сообществе открытого исходного кода, и это очень хорошо сочетается с предыдущей частью, потому что это двунаправленная вещь. С одной стороны, Mendix очень сильно связан с корпоративным миром, и то, что мы делаем, часто довольно близко к внешнему миру. И мы делаем несколько действительно крутых технических вещей, которыми хотим поделиться на конференциях, поэтому я либо говорю об этом сам, либо пытаюсь побудить своих коллег сделать это. С другой стороны, частое посещение конференций приятно тем, что происходит и обратное: вы обнаруживаете что-то, что может или может быть актуальным для нас, а затем мы исследуем это больше и применяем к нашему собственному стеку.
- Вы упомянули, что действительно занимаетесь евангелизацией OSS. Что это такое и почему это важно для вас?
- Что я заметил, так это то, что материалы с открытым исходным кодом на самом деле не экономят ваше время, но это означает значительное повышение качества при тестировании, потому что такая библиотека, как MobX, используется множеством способов и обстоятельств. А это означает, что программное обеспечение с открытым исходным кодом - это преимущество, которое иначе получить очень сложно. Это одно. И еще один: я действительно считаю, что то, что мы строим на низком уровне, не делает различия для самой компании, так почему бы не поделиться этим? Я имею в виду, что это то, что вы создаете с помощью технологий, которые делают вас лучше или хуже на соревнованиях, но не то, что вы используете на низком уровне. И если вы будете сотрудничать, вы все выиграете от этого, и я думаю, что это просто ускорит технологическое развитие в целом.
- Я слышал некоторые мнения о том, что открытый исходный код - это действительно дорогое удовольствие. Поэтому большие проекты OSS, такие как Linux, требуют больших денег от таких поставщиков, как Oracle и Microsoft. Как вы думаете, может ли мир OSS жить без крупных поставщиков?
- Я думаю, это зависит от обстоятельств. У вас есть библиотеки меньшего размера, которые могли бы жить без этого, но у вас также есть действительно сложные проекты, подобные упомянутому вами, или что-то вроде React Native: это настолько сложно, и так много людей зависят от него, что ему нужна суперпрочная финансовая модель. . В этом случае я думаю, что это действительно сложно сделать без крупных компаний, стоящих за программным обеспечением. Но я не думаю, что это должно быть проблемой. Я думаю, что важнее, чтобы компании научились брать на себя ответственность, а не выясняли, как сделать OSS без компании.
- Но что бы произошло, например, если бы Facebook пришел к вам и сказал: «Эй, вы создали MobX, можем ли мы его купить или, может быть, стать спонсором, чтобы вы разработали MobX под нашим брендом?»
- Ну, вообще-то они спонсируют MobX. Забавно, они - один из спонсоров Открытого коллектива. Так что в этом смысле это уже происходит. Я думаю, что Open Collective - действительно хороший пример того, как мы можем улучшить финансовый мир открытого исходного кода, потому что он позволяет компаниям спонсировать программное обеспечение таким образом, который им удобен (это надежно в финансовом отношении: вы можете выставлять счета и т. Д.). В Mendix мне уже платят за обслуживание MobX, поэтому мне не интересно переходить на Facebook. Но я могу представить, что это сработает для других, и я думаю, что в этом нет ничего плохого. Я думаю, что до тех пор, пока программное обеспечение и лицензия остаются открытыми, можно добавить имя главного спонсора к программному продукту. Это ничем не отличается от просмотра футбола по телевизору: важно то, что все могут видеть, как команды играют в футбол, а название бренда на футболках не имеет особого значения.
- Но может ли крупный спонсор заставить библиотеку каким-то образом измениться?
- Не думаю, что я видел, как это произошло на самом деле или, по крайней мере, не так, чтобы это действительно стало проблемой. Если я не ошибаюсь, webpack в основном допускает эту модель, люди могут платить за функции. Так что риск есть, но я думаю, что ответственность за то, чтобы проект оставался верным своей философии, лежит на сопровождающих. И в этой философии, вероятно, есть много места для маневра. И что хорошо в открытом исходном коде, так это то, что если что-то пойдет не так, по крайней мере, есть выход с помощью разветвления.
- Когда библиотека становится популярной, ей требуется больше ресурсов. Сколько времени вы проводите с MobX?
- В последнее время не так уж и много. MobX сейчас довольно стабилен. Но, конечно, в прошлом я тратил на это много времени. Это очень разнообразно. Я думаю, что в первые два года в среднем это было по крайней мере несколько вечеров или после обеда в неделю. И много моментов, когда вы просто отвечаете на небольшие проблемы или быстрые вопросы в Твиттере: на самом деле это не похоже на то, чтобы тратить много времени, но, вероятно, тоже складывается. Но это очень сложно измерить. Это похоже на проверку деловой почты: вы также проверяете свои проблемы и быстро оставляете ответ.
- Как быть продуктивным в этой ситуации? Не каждый может работать с открытым исходным кодом в рабочее время, поэтому, если библиотека становится все более популярной, это может стать проблемой - как с этим жить?
- Когда я работал над MobX, сначала я делал это и в свободное время, позже он стал спонсироваться, когда он стал более популярным. Но я заметил, что есть несколько вещей, которые действительно очень мне помогли. Один из них - всегда быть в курсе вашей документации. Например, если вы заметили, что три или четыре раза получаете один и тот же вопрос в своем трекере проблем, убедитесь, что вы записали его где-нибудь в своем документе: это действительно хорошее вложение времени, потому что вы увидите, что входящие проблемы уменьшаются.
Второе: очень критически относитесь к качеству вопросов, которые вы принимаете. Вначале, когда сообщается о проблеме, вы пытаетесь воспроизвести ее на основе полученного описания, а затем, вероятно, обнаруживаете, что не можете воспроизвести ее. Но это очень затратно по времени, поэтому в настоящее время, когда кто-то сообщает о проблеме, я требую что-то, что я могу запустить напрямую, будь то песочница кода или запрос на перенос для модульных тестов. Что-то для меня, чтобы проверить, находится ли ошибка на стороне библиотеки или на стороне потребителя. Это очень важно, потому что это экономит много времени. И это дает вам уверенность в том, что человек, отправляющий вопросы, тоже готов инвестировать в это. Некоторые говорят: «У меня нет времени делать репродукцию», а я такой: «Ну, тогда у меня нет времени решать вашу проблему». Я имею в виду, что вам, вероятно, платят за работу и использование моей библиотеки, так почему я должен тратить свое свободное время на решение вашей проблемы? Итак, это помогает, но для этого нужно быть более безответственным по отношению к своей библиотеке, чем обычно. Естественно, вы хотите помочь всем остальным. Но я обнаружил, что это просто нереально.
Так что такие вещи помогают. Кроме того, поскольку я поддерживаю несколько библиотек, я обычно не отвечаю на все свои проблемы сразу, я перескакиваю с одной библиотеки на другую. Несколько дней я работаю над одним из них, отвечая на вопросы, а затем перехожу к следующему. Так что может случиться так, что я отвечу в течение нескольких минут, если вы просто запишите что-то о том, над чем я работаю, или это могут быть дни, потому что я просто работаю над одной из других своих библиотек. И это помогает мне сделать его более осуществимым и уменьшить количество переключений контекста. Мы надеемся, что это советы, которые могут помочь, когда ваша библиотека станет более популярной и начнет приносить больше работы.
- Но если вы потребуете модульные тесты или что-то в этом роде, может ли это привести к тому, что люди подумают: «Эй, этот парень ведет себя как суперзвезда и не может ответить на мою простую проблему»? Приводит ли это к плохому отношению к сопровождающим?
- Думаю, я видел, как это происходило несколько раз, но очень редко, и в целом люди, кажется, понимают, что сопровождающие довольно заняты и, скорее всего, это на их стороне. Если вы используете фильтр из Lodash и что-то пойдет не так, вы сначала почувствуете, что он, вероятно, на вашей стороне, потому что все используют Lodash. Таким образом, большинство людей понимают, что они должны быть точными в своих вопросах и доброжелательно задавать вопросы.
- Когда библиотека становится популярной, вы понимаете, что не можете поддерживать ее самостоятельно. Как насчет предоставления некоторых прав другим участникам сообщества?
- Это супер хорошая идея, и я, как правило, делаю это, как только вижу, что кто-то отправляет несколько разумных PR (или даже один большой PR). Я обычно даю людям права участников, и я думаю, что это очень хорошо работает. Например, для mobx-state-tree большая часть обслуживания до сих пор выполнялась другими людьми, а не мной. В кодовой базе есть области, с которыми они знакомы больше, чем я, и это действительно отличное место для изучения.
Что касается MobX, то я этого не делал, потому что он в основном устоявшийся, а сами алгоритмы не менялись за последние два года, поэтому обслуживание, особенно в этом, не такое уж большое. Но для mobx-state-tree я определенно выбираю людей, которые создают множество пользовательских библиотек, а также дают им возможность сотрудничать, потому что это имеет большой смысл. Если вы интенсивно используете библиотеку в повседневной работе, вы также обнаружите закономерности или распространенные проблемы, которые я пропустил. И поэтому, если есть разработчик, у которого нет контроля над библиотекой, я думаю, что это мотивирует и также чувствует себя в безопасности, потому что вы можете заставить его работать так, как вы с ним делаете.
- Неужели вы никогда не чувствовали, что после предоставления прав участника библиотека, как младенец, начинает ускользать из ваших рук? Может быть, вы не совсем согласны с тем, как он развивается, или что-то в этом роде.
- Да, немного, иногда. Но я думаю, что это нормально. Вы провели отличную аналогию, сравнив это с младенцем: в определенный момент младенцы вырастают, и вы должны отпустить их, потому что они должны найти свой собственный путь. Я думаю, что частично то же самое и с библиотекой с открытым исходным кодом. Если они будут успешными, вы увидите более сложные ситуации, вам придется разбираться с делами, которые вы не хотели решать. Код больше не будет таким красивым, чистым минимальным кодом, каким вы хотели его видеть. Это всегда будет происходить, когда все будет успешным.
В MobX есть отличный пример: изначально я писал для TypeScript, который имеет очень простую модель декоратора, а затем люди начали использовать его с Babel, у которого была совершенно другая реализация. А некоторые части в кодовой базе довольно уродливы, потому что они пытаются определить, используете ли вы транспилятор TypeScript или Babel. Это звучит ужасно и ужасно выглядит. Но это часть работы. Вам это не очень нравится, но вы должны убедиться, что он работает везде и везде. И в этом смысле ваш ребенок может пойти в направлении, которого вы на самом деле не планировали, но это нормально, потому что в конечном итоге имеет значение тот факт, что люди могут успешно применять его.
- С годами разработка программного обеспечения сильно изменилась, людям стало легче вносить свой вклад. Что вы думаете о текущей ситуации в мире OSS и о том, что может произойти в будущем? Например, будут ли управлять этим миром крупные корпорации и не будет ли отдельных участников или все будет наоборот?
- Сложный вопрос. Не уверен, что будет много изменений. И движение происходит в обе стороны. Меня особенно впечатлили Facebook и Microsoft: насколько широко они открывают исходный код в настоящее время и на каком уровне они позволяют отдельным разработчикам вносить свой вклад. React Native - хороший пример того, что большая часть работы исходит не от самого Facebook.
С другой стороны, действительно, для отдельного человека, вероятно, никогда не было так просто внести свой вклад или создать проект с открытым исходным кодом, как сейчас. Все инструменты становятся все более стандартизированными, у нас есть отличные онлайн-среды разработки, такие как CodeSandbox или Gitpod. Я работал с Gitpod последние несколько недель, это действительно здорово, я могу просматривать PR, даже не проверяя что-то на месте. Просто запустите его в Docker в своем браузере и развивайте там.
Так что я не уверен, что изменилось в этом направлении, очень сложно сказать.
- Помогут ли такие вещи, как отличные инструменты, развивать открытый исходный код в будущем? Стоит ли ожидать появления большого количества проектов с открытым исходным кодом через пять лет?
- Думаю, движение будет продолжено. Одна из причин: и компании, и разработчики все больше и больше осознают, что открытый исходный код также очень полезен для привлечения талантов. Глядя на открытый исходный код, который кто-то создает, вы можете рассказать о человеке больше, чем вы можете узнать за день собеседования. То, как кто-то реагирует на проблемы или проблемы с файлами, многое говорит о характере этого человека. И я думаю, что и разработчики, и компании все больше осознают ценность этого.
- Значит, разработка библиотеки с открытым исходным кодом может помочь разработчику на собеседовании?
- Точно. Как компания, если у вас есть библиотеки с открытым исходным кодом, которые не имеют решающего значения для вашего API, это замечательно, потому что люди будут вмешиваться, и они могут быть именно тем, что вы ищете. А если вы сможете нанять некоторых из ваших участников, их будет легче адаптировать, и вы будете более уверены в том, чего ожидать. Так что я думаю, что даже по этой причине компании стали открывать интересные вещи с открытым исходным кодом.
- Давайте перейдем от open source в целом к MobX. Первый вопрос: как и почему вы начали работать над MobX?
- Хороший вопрос. На самом деле на него есть вполне конкретный ответ. В Mendix у нас было приложение с графическим интерфейсом для Windows, написанное на C #, и в какой-то момент мы решили перенести его в Интернет. И мы начали исследовать, какой стек мы хотим использовать для этого. React только начался, Angular существовал какое-то время, Ember был довольно популярен. И довольно быстро мы влюбились в React из-за его компонентной модели и уровня абстракции, которые он предоставляет.
Но затем мы обнаружили проблему с производительностью при обновлении DOM. В C # мы могли просто обновлять модель и все время перерисовывать холст, и никто ничего не оптимизировал, потому что это было уже достаточно быстро. С помощью Интернета мы внезапно обнаружили, что нельзя просто перерисовывать все 60 раз в секунду, потому что DOM не справляется с этим. Итак, мы начали выяснять, как сделать это эффективно.
Мы рассмотрели неизменный подход в целом, но он не сработал для нас по нескольким причинам. Во-первых, это связано с природой наших данных и тем, как мы их обрабатываем. Рендеринг в разных местах. Эти данные действительно сложно нормализовать. А во-вторых, казалось, что здесь задействовано слишком много деталей. Вам нужно написать селекторы, чтобы, например, получать обновления для любых данных, которые вы визуализируете.
Но что, если вы хотите написать такой же тупой, как наш старый код C # код, «отрисовывать что-то», и вам не нужно беспокоиться о том, что что-то изменится в будущем? Что, если вы не хотите говорить компонентам: «Эй, вам нужен этот фрагмент данных, возьмите этот фрагмент и затем вы сможете что-нибудь визуализировать»? Итак, мы начали изучать, какие технологии могут сделать это возможным. И быстро добрался до парадигмы программирования, используемой в Knockout , Meteor или (по крайней мере, концептуально) даже в Angular. Где вы больше не указываете, какова взаимосвязь между зависимостями данных и компонентов, и не указываете, что и когда должно отображаться.
И я начал исследовать, почему люди часто ненавидят эти подходы, особенно когда приложение становится сложным. И большинство вещей, связанных с предсказуемостью и отладкой: что-то может запускаться слишком часто, недостаточно раз или в неправильном порядке. И я понял, что мы можем добиться большего. Что мы можем стремиться к той же цели, но делать это более разумно с точки зрения реализации. И вот в основном то, откуда приходит MobX.
Он не просто фиксирует отношения между наблюдателями и наблюдаемыми объектами, он строит целые графы зависимостей, чтобы убедиться, что все ваши наблюдатели работают в наиболее эффективном порядке. Так что «сбоя», как его называют в реактивном программировании, быть не может. По сути, это было связано с тем, что уже существует, но с попыткой сделать это предсказуемым.
- Итак, ваш опыт подсказывает нам, что если мне нравится какой-то подход, но библиотеки плохи, я могу создать свой собственный, и он может стать популярным?
- Да, точно! Первоначально я написал его для внутренних целей, а затем отправился на ReactEurope 2016 (или мне так кажется), и внезапно возникло много разговоров о паттернах Flex. Я думаю, это был момент, когда происходили все войны Flex. И я просто сидел и чувствовал, что люди вкладывают столько усилий в проблему, которую мы уже решили. Так что именно в этот момент я подумал: «Давайте откроем исходный код». И это вроде как сработало. Наверное, потому, что это была не очередная реализация Flex, а нечто совершенно иное. Он понравился многим.
- Итак, идея MobX была довольно простой. Но теперь в нем много кода и функций. Вам никогда не казалось, что это стало слишком сложным?
- Ага! У меня всегда было такое чувство: Я хочу создать MobX Lite. По сути, вы можете написать какую-то версию MobX в 200 строк кода. У меня даже есть разговор, где я как бы делаю это. Затем вы можете добавить несколько сотен строк, чтобы оптимизировать это дерьмо и сделать его намного быстрее при любых обстоятельствах. Вот и все ядро MobX. Но я думаю, что три четверти кода MobX находится на поверхности API. Есть основная идея, а затем библиотека просто решает все, чтобы API был как можно лучше. Например, в MobX 5 изменились прокси.
- Большинство разработчиков пока не используют прокси в продакшене, а вы это делаете. Было ли это сложно?
- Иногда бывает сложно одним из первых внедрить технологию. Но прокси существуют довольно давно, я думаю, что четыре года назад были стабильные реализации. Их применяют так поздно, потому что прошел всего год с тех пор, как они были внедрены во всех основных браузерах. И у прокси были значительные накладные расходы, но теперь эти накладные расходы незначительны и, вероятно, будут вызваны вашей реализацией, а не самими прокси.
- Хорошо. Поговорим немного о государстве. Мы помним дни, когда jQuery был правителем веб-разработки, и на клиенте не было состояния, мы хранили его в глобальном объекте или что-то в этом роде. Теперь вы не можете создать приложение без какой-либо библиотеки управления состоянием. Что изменилось?
- Думаю, на это есть два ответа. Во-первых, во времена jQuery на клиенте не было такого большого состояния. jQuery часто использовался для добавления интерактивности, когда состояние оставалось на сервере, что в настоящее время считается плохой практикой.
Но, возможно, более важной причиной перехода от jQuery к модели на основе компонентов, такой как React, является то, что React позволяет нам использовать компоненты независимо, что упрощает масштабирование вашей кодовой базы. Таким образом, переход от jQuery к React упростил создание более сложных приложений.
И я думаю, что управление состоянием делает для состояния то же самое, что и React для пользовательского интерфейса. Это позволяет вам разбивать ваши состояния на более сплоченные паттерны. Вы можете перейти к автономным фрагментам данных и логики, которые вы можете модульно тестировать без своего пользовательского интерфейса, чтобы вы могли лучше контролировать их.
- Что вы думаете о будущем государственного управления? Пришли ли мы к идеальным решениям или впереди нас ждет большой путь?
- Думаю, мы еще не дошли. Особенно если речь идет о государственном управлении, ориентированном на неизменные ценности. Мы не упростили работу с ним.
Я думаю, что одна из причин, по которой Immer стал настолько популярным в 2017 году, заключается в том, что он наконец-то заставил неизменяемые состояния чувствовать себя естественными в JavaScript. Но я думаю, что еще многое предстоит сделать, я чувствую, что многое еще не так естественно, как могло бы быть. Появляются новые подходы, GraphQL очень интересно упомянуть в этой области, но я еще не чувствую, что это есть, когда речь идет о местных штатах. Так что в этом смысле я ожидаю, что это тоже будет развиваться.
- Не могли бы вы назвать одну или две функции, которые вы хотели бы добавить в MobX в ближайшие годы?
- Есть кое-что, что я действительно хочу добавить, но для многих это не актуально: я хочу сделать преобразования данных более реактивными. Например, у вас есть список дел, а затем вы выполняете некоторую фильтрацию, фильтруете все незавершенные задачи. В настоящее время, если на этом этапе вам нужно пересчитать, вы снова запустите свой фильтр, и он снова обработает все ваши элементы. Но это потратит впустую больше времени, чем могло бы. Только измененные элементы могут изменить результат вашего фильтра, поэтому ваш фильтр не должен перекрывать все ваши задачи. Но в настоящее время нет удобного способа выразить такие преобразования. Но преобразования данных могут быть более реактивными, чем сейчас. Так что было бы здорово добавить это в будущем.
- Поговорим о конференциях и семинарах. В России есть проблема с культурой воркшопа: в целом он непопулярен и публика думает, что это только для юниоров. Как работают семинары в Европе и что вы о них думаете?
- Мне очень нравятся семинары, и я считаю, что это хороший способ учиться. Мне лично нравится учиться двумя способами: я либо сижу на диване и читаю книгу от корки до корки, либо посещаю семинар. Лично я не из тех парней, которым нравится учиться на видео (хотя я сам создал несколько видеокурсов), потому что для меня это всегда либо слишком медленно, либо слишком быстро.
Когда я начал заниматься Docker, я просто пошел на семинар, чтобы изучить его основы. А поскольку это довольно практично, вы сразу же понимаете, как это работает, каково это и как вы могли бы это применить. Не думаю, что семинары интереснее для юниоров, чем для старших. Я думаю, что смысл семинаров в том, что они являются самым быстрым способом освоить новую технологию, с которой вы пока совершенно не знакомы. Я думаю, что это самая большая ценность семинаров, и это то, чего вы не получите из книги.
Книга больше похожа на то, чтобы получить более широкую картину и выяснить, действительно ли что-то актуально или нет. Но если вы действительно хотите начать над чем-то работать или серьезно обдумываете это, семинар - это самый быстрый способ подойти к делу. Люди следят за семинаром, но в перерывах они также будут приходить с реальными проблемами, которые у них есть, или задавать больше вопросов о том, как они могут применить то, что они узнали, к своим конкретным проблемам. В этом преимущество семинаров: вы действительно с кем-то разговариваете, вы можете задавать вопросы, связанные с вашей ситуацией. Я очень твердо верю в мастерские как в средство освоения новых технологий.
- Некоторые в России думают, что конференции не очень важны, потому что вы можете просто читать статьи на Medium. Как вы думаете, почему человек должен пойти на конференцию, а не просто посмотреть видео на YouTube?
- Очень хороший вопрос. Думаю, в отличие от семинаров, цель конференции в первую очередь не в том, чтобы учиться. На мой взгляд, нет. Основная причина, по которой вы должны посещать конференции, - это вдохновиться тем, что происходит в поле или тем, что делают люди. Это заставляет вас хотеть учиться, но этого может не быть на самой конференции.
С этим приходит вся сеть. Когда вы идете на конференцию, старайтесь не слишком много разговаривать со своими коллегами. Вы их уже знаете. Вы уже знаете, какие проблемы они решают. Намного интереснее разговаривать со случайными людьми, которые могут стоять в одной очереди за едой или чем-то еще. Что они делают? Как они решают проблемы? Что у них было с библиотекой, о которой кто-то говорил ранее этим утром?
И просто найдите спикеров, если у вас есть к ним вопросы. Многие люди боятся приближаться к спикерам, но для меня как спикера и, вероятно, для большинства других спикеров, выступление перед посетителями - одна из самых крутых частей конференции. Я имею в виду, не разговаривай со мной за пять минут до моего выступления, но в остальном я очень доступен или стараюсь быть им. Так что не стесняйтесь поговорить со мной.
- Это очень крутой совет. Спасибо за уделенное время!
Мишель приедет на HolyJS 2019 Piter, который пройдет в Санкт-Петербурге, Россия, 24–25 мая.
