В 2019-м зрители JPoint крайне впечатлились докладом «Атомарный рефакторинг» Тагира Валеева (lany). Демонстрация того, как можно нестандартно использовать средства IDE для рефакторинга, взорвала многим и при этом была практически полезна — а в итоге по зрительским оценкам доклад стал лучшим на конференции. Можете сами посмотреть видеозапись.
А в онлайн-трансляции JPoint 2019 у Тагира взял интервью другой спикер Егор Бугаенко (yegor256), и благодаря этому зрители трансляции узнали другие интересные вещи. Например, какой «ход конём» помог Тагиру при собеседовании в JetBrains или как он использовал Stack Overflow для популяризации своей библиотеки.
Сейчас готовится новый JPoint (Москва, 15-16 мая), и стала известна новая тема, с которой приедет Тагир: в этот раз он закроет конференцию выступлением «Заменят ли роботы программистов». А мы тем временем подумали, что прошлогоднее интервью слишком интересное, чтобы оставлять его только зрителям трансляции — и для Хабра сделали текстовую расшифровку.
Как попал в JetBrains
Егор: Доброе утро! Второй день конференции JPoint, и я беру интервью у спикера Тагира Валеева: мне он интересен и как спикер, и как программист, и как сотрудник JetBrains. Он сейчас о себе в двух словах расскажет, а потом я задам ему массу вопросов.
Тагир: Здравствуйте, меня зовут Тагир Валеев! Я работаю в компании JetBrains, в команде поддержки языка Java в IntelliJ IDEA. Если вы программируете на Java в IntelliJ IDEA, вы, возможно, пользуетесь моим кодом.
Егор: У меня будут вопросы больше к тебе лично, чем к JetBrains. Мне интересно, как ты попал в эту компанию?
Тагир: Очень просто. Я жил себе в Новосибирске, горя не знал, тут я выяснил, что JetBrains открывает офис у нас в Новосибирске. Я решил, что это прекрасная возможность поработать в замечательной компании.
Егор: Ты резюме отправил?
Тагир: Да, я отправил резюме, меня пригласили на собеседование и приняли.
Егор: То есть они до этого тебя не знали и не хотели, а ты просто сам отправил через обычный сайт резюме и просто попал?
Тагир: Сказать, что они меня не знали, неправильно, потому что я до этого выступал на конференциях, в том числе на конференциях @jugru, а JetBrains регулярно эти конференции спонсирует. Естественно, мы где-то пересекались, болтали, так что какие-то люди видели меня и мои доклады.
Кроме того, у меня была немножко заметная деятельность в мире Java: я писал библиотеку StreamEx и что-то делал по статическому анализу. И в тот момент, когда я решил, что хочу работать в JetBrains, я писал свой статический анализатор, который вскоре после этого забросил.
Егор: FindBugs?
Тагир: FindBugs был до этого, а потом я писал другой под названием HuntBugs, потому что мне надоело бороться с FindBugs, там всё было очень плохо. Я писал HuntBugs на движке Procyon.
Егор: Писал сам, как опенсорс-продукт, без всякой поддержки?
Тагир: Да, как опенсорс, просто целиком с нуля. Не считая того, что я взял готовый движок, который строил модель Java-кода по байткоду.
Егор: И долго ты этим занимался?
Тагир: Несколько месяцев в свободное время.
Егор: И всё? За несколько месяцев ты создал опенсорс-продукт? Он сейчас жив на рынке?
Тагир: Нет, он не жив.
Егор: Ты его бросил, перейдя в JetBrains?
Тагир: Да.
Егор: А почему бросил?
Тагир: Просто потому, что в JetBrains я стал заниматься практически тем же, но в рамках IDE. И решил, что довольно глупо распыляться и делать параллельно две одинаковые вещи.
Егор: То есть то, что у тебя был опенсорс-проект, и то, что ты выступал на конференциях, помогло тебе попасть в JetBrains?
Тагир: Да. Ещё я сделал такой хитрый ход конём: взял свой статический анализатор в том виде, в котором он был, и натравил его на исходные коды IntelliJ IDEA.
Естественно, там нашлось какое-то количество предупреждений. Я выбрал из них такие, которые сама IDEA не находит, и написал статью на Хабр, где рассказал, что у меня есть такой замечательный статический анализатор, давайте попробуем его на IDEA — хоп! — вот, вот, вот, вот, такие баги есть в IDEA.
Уже потом я узнал, что, естественно, сотрудники JetBrains всё это прочитали. И даже завели у себя тикеты: «Да, надо нам вот это поддержать, вот эти баги пофиксить». То есть я, в некотором смысле, представился несколько заранее. И когда я пришёл на интервью, эти люди уже примерно представляли, с кем имеют дело.
Егор: И легко всё прошло? Интервью было коротким?
Тагир: На удивление, прошло всё достаточно легко. Ну как, не «на удивление»: понятно, что эти предыдущие шаги, думаю, мне помогли.
Егор: А тебя просили какие-то алгоритмы нарисовать на доске, что-то запрограммировать на интервью? Были какие-то технические вопросы?
Тагир: Да, были технические вопросы. Например, мне дали такой несложный с виду технический вопрос, но я на нём даже затупил. Идея была в том, что у нас есть некоторое представление, древовидные структуры в памяти. Есть два узла, у каждого можно получить родителя. И задание в том, чтобы найти ближайшего общего родителя. Это дерево, то есть в какой-то момент родители заканчиваются, и мы приходим к null. Я придумал несколько решений, но тем, кто проводил мне интервью, пришлось мне подсказать, чтобы я нашёл то оптимальное решение, которого они ожидали.
Егор: А долгое интервью было по времени?
Тагир: Примерно час, наверное.
Егор: Одно интервью было? И тебя взяли?
Тагир: Да, одно. После этого было некоторое, так сказать, code review, так как я показал свои опенсорс-проекты: HuntBugs, StreamEx. Сказал: «Вот у меня есть опенсорс, можете посмотреть, как я программирую».
Егор: И они посмотрели?
Тагир: Да, они посмотрели, и мне потом по почте прислали несколько вопросов по архитектуре: почему я принял такие решения, а не другие. Какой-то был у нас диалог. А после этого мне прислали оффер.
Активность на Stack Overflow
Егор: Знаешь, я часто рассказываю в своём блоге, как важно иметь опенсорс, как важно выступать на конференциях. И многие программисты пишут мне, что это никакому работодателю не важно. Когда ты приходишь на интервью, им плевать на твой опенсорс, на твой StackOverflow-аккаунт (который у тебя лично тоже немаленький). И они мне говорят: «Зачем к этому готовиться, если работодателю, на самом деле, всё равно?». Ты можешь как-то прокомментировать? Твой работодатель — это какое-то исключение? Или эти люди ошибаются?
Тагир: Ну, я не очень часто в своей жизни устраивался на работу. Три раза, и в первый раз это было практически по знакомству в стартап, а в другой раз меня передали из одной компании в другую, потому что там занимались похожими вещами. И в третий раз это был JetBrains. Поэтому у меня нет опыта хождения по собеседованиям — по факту, это было первое такое полноценное собеседование в моей жизни. Поэтому я не могу составить какую-то общую картину. В моём случае я считаю, что это сыграло существенную роль. Скорее всего, если бы у меня не было кода показать, мне бы дали тестовое задание. И там уже неизвестно: может быть, я бы с ним плохо справился. Это существенно упростило мне попадание в JetBrains.
Егор: А ты когда всё это делаешь (допустим, проявляешь активность на StackOverflow или ведёшь опенсорс-проекты), ты думаешь о будущих собеседованиях, или делаешь это для себя?
Тагир: Сейчас я уже активно не сижу на StackOverflow, но действительно был период (наверное, полгода), когда я буквально каждый день отвечал на вопросы. В основном связанные с Java Streams.
История была такая. Я начал писать свою библиотеку StreamEx, которая расширяет стандартные Java streams, по большому счёту просто потому, что меня пропёрло. Сперва мне показалось, что стримы — это очень круто, а потом начал понимать, что в них много чего не хватает и надо их расширять. Я начал их расширять, опубликовал библиотеку, но подумал, что довольно глупо просто опубликовать библиотеку, кто про неё узнает? Случайно найдут на GitHub три человека и будут пользоваться. Как-то приложение сил не очень эффективное.
Поэтому я подумал: «А как бы её немножко порекламировать?». Тогда я тоже написал статью на Хабр, это принесло некоторое количество звёздочек, скачиваний и какого-то интереса, но не очень большое.
Потом я посмотрел на StackOverflow и заметил вопросы, для которых с помощью стандартного Stream API нормального решения нет, а моя библиотека их прекрасно, изящно, в один метод решает. И как раз можно было дать удачный ответ в этом месте.
Я внимательно прочитал правила StackOverflow относительно рекламы своих продуктов, и выяснил, что, в принципе, так делать можно. И начал участие в этом сообществе в основном с целью продвинуть эту библиотеку. А цель была именно в том, чтобы мои труды не пропали, чтоб люди как-то ими пользовались. Но потом это немножко сдвинулось, просто мне стало интересно отвечать на вопросы на StackOverflow. Там у них очень неплохо построена геймификация: бейджи, репутация и всё такое. Меня это немножко затянуло именно как игровой процесс. А потом в какой-то момент интерес пропал, и я стал реже там появляться.
Егор: А вопросы ты там задавал? Или задаёшь сейчас?
Тагир: Я задал, может быть, вопросов шесть (прим. ред.: мы перепроверили, оказалось 12). В некоторых случаях это тоже были, скажем так, хитрые вещи.
Например, была пара вопросов, на которые я сам ответил, на StackOverflow так тоже можно. Если вы хотите поделиться знанием, то можете задать вопрос и самостоятельно дать на него ответ. Там есть некоторые ограничения вроде того, что нельзя сразу же принять свой ответ как единственно верный: нужно подождать какое-то время (не помню точное), может быть, кто-то ответит лучше.
Понятно, есть риск, что сообщество решит, что я просто выпендриваюсь, пытаюсь накрутить себе карму, и нещадно всё это заминусует. Но если это действительно интересная тема, которая ещё никем не поднималась, то могут и тепло принять.
Потом была пара вопросов, когда я наталкивался на баг в Java, в стандартном Stream API, и оформлял это в виде вопроса, на StackOverflow некоторые тоже так делают. Я раньше просто не знал более эффективных способов. Писал: «Вот я делаю то-то, поведение оказывается такое-то, а я ожидаю такое-то. Может быть, я что-то не понимаю?» И иногда кто-нибудь, в том числе и из Oracle, отвечал: «Видимо, ожидаемое поведение — это всё-таки то, как ты его ожидаешь, то есть, видимо, это действительно проблема». Уже потом я узнал, что эффективнее писать в мейлинг-листы по Java, у меня появился доступ в систему багтрекинга Java и так далее, а начинал с такого.
Работа
Егор: А чем ты сейчас занимаешься конкретно в JetBrains? Каждый твой рабочий день из чего состоит?
Тагир: В JetBrains моя официальная должность — technical lead в Java Team. Я занимаюсь как обычной разработкой, так и некоторыми вещами в масштабе команды. Я слежу за стабильностью подсистемы, если какие-то тесты начали в нашей подсистеме падать, то это моя забота — исправить или назначить ответственного.
Кроме того, какие-то митинги и планирования тоже проходят. Но много и программистской работы: я исправляю текущие проблемы, создаю новые инспекции, улучшаю существующие intention actions, исправляю подсветку. Вот у нас буквально в декабре (2018-го — прим. ред.) было вложено много труда в поддержку Switch Expressions из Java 12, там команда практически целый месяц довольно интенсивно работала, чтобы хорошо и красиво поддержать…
Егор: А какой именно код в вашей ответственности находится? Код всей IntelliJ?
Тагир: Нет, код Java-плагина, то есть всё то, что связано непосредственно с поддержкой языка Java: Java intentions, Java inspections, Java refactorings, Java highlighting и так далее.
Егор: А как ты оцениваешь качество этого кода? Ты же пришёл уже на готовый код, он был написан до тебя?
Тагир: Да, конечно. Я считаю, что для кода, который дополнялся и эволюционировал на протяжении 20 лет, это весьма хороший код. Даже если сравнить в рамках всей IntelliJ IDEA, я считаю, что Java-подсистема написана лучше среднестатистического уровня, скажем так.
Безусловно, есть проблемы — где-то есть вещи, написанные не очень красиво, не очень опрятно, по которым плачет рефакторинг. Но в целом нормально.
Егор: Это закрытый код, правильно? Мы его не видим?
Тагир: Нет, это опенсорс, вы можете зайти на GitHub, и практически 99% моих коммитов туда попадают.
Егор: А чем вы собираете? Можешь технические детали рассказать? Какие у вас юнит-тесты, что вы используете для юнит-тестинга, что для сборки, что для статического анализа?
Тагир: Я могу не знать идеально текущее состояние дел, потому что непосредственно поддержанием билд-скриптов я не занимаюсь. Я знаю, что у нас билд начинается с Gant (надстройки над Ant). Часть вещей, в том числе выкачивание зависимостей, делается с помощью Gradle-скриптов, которые, видимо, запускает этот самый Gant, но полного пайплайна у меня в голове нет.
Когда я устроился в 2016 году, у нас вообще не было внешних зависимостей, все JAR-файлы лежали непосредственно в репозитории IDEA. Но теперь было предпринято довольно большое усилие, чтобы с этим справиться. Это была немаленькая работа, потому что иногда брали какую-нибудь библиотеку из веба, может быть, немножко её доделывали, что-то просто морально устарело, и с каждой зависимостью приходилось работать отдельно. То есть не ситуация, когда просто вписали мавеновские координаты и всё заработало.
А теперь у нас практически все зависимости берутся из внешних репозиториев, соответственно, всё скачивается и собирается. Насколько понимаю, для юнит-тестирования у нас в основном JUnit 4, даже, наверно, больше тестов на JUnit 3. И некоторые люди до сих пор считают, что в рамках JUnit 3 писать удобнее. Честно говоря, мне нет особой разницы, потому что тестовые фреймворки, по-моему, overrated. Assert — это метод из трёх строчек, ты его написал — и вот у тебя тестовый фреймворк, считай.
Егор: А это решение по переходу от файлов, которые лежат в репозитории, к нормальному dependency-менеджменту, было твоей идеей?
Тагир: Нет.
Егор: Это команда хотела до тебя делать?
Тагир: Во-первых, команда хотела до меня, а во-вторых, это инфраструктурное решение. Я всё-таки занимаюсь отдельным компонентом, а это инфраструктурное решение на уровне IDEA, этим занимались люди в core team.
Егор: А были какие-то новые решения, которые ты принёс в команду? Когда ты пришёл в 2016 году, ты что-то решил исправить?
Тагир: Ты имеешь в виду инфраструктурные решения?
Егор: Нет, по твоей зоне ответственности.
Тагир: По моей зоне ответственности было очень много решений. Про какие-то довольно большие компоненты я просто решил, что их надо делать — либо сам их сделал, либо другие помогали.
Егор: У меня вопрос в том, как принимались твои решения. Сначала спрошу, тебя сразу взяли на позицию тимлида?
Тагир: Нет, меня взяли на позицию senior developer. А сейчас у меня не тимлид, у меня technical lead, это не включает административную работу. То есть я не занимаюсь решением, кто сколько денег будет получать, кто когда пойдёт в отпуск, только техническим руководством.
Егор: До этой технической позиции ты был повышен через какое-то время?
Тагир: Да, и не очень давно, буквально с этого года. А до этого я был senior developer, но при этом принимал многие решения в плане «сделать большую вещь».
Например, когда я пришёл, преобразование циклов в стримы у нас было в совершенно зачаточном состоянии. Я это довёл до очень хорошего состояния. После этого мне пришла в голову мысль, что нам нужна и обратная фича — преобразование стримов в циклы. Причём это не был запрос от пользователей, никакого тикета ни от кого не было, у меня просто была внутренняя убеждённость, что если мы умеем циклы преобразовывать в стримы, то должны уметь и обратно делать. Я это обсудил с руководителями, люди согласились: «Да, это вполне разумное пожелание». И я это сделал, довольно большой компонент.
Много усилий я потратил на кардинальное улучшение потокового анализа. Например, когда пришёл, не было никакого анализа целочисленных диапазонов, анализа выхода за пределы границы массива, IDEA совершенно не понимала, как работает Stream API в плане потокового анализа. То есть если мы взяли сейчас nullable-значение в стриме, а потом написали фильтр «not null», и после этого в следующем map его дереференсим, она говорила: «У вас тут может быть NullPointerException».
Егор: Мой вопрос вот к чему. Наталкивался ли ты на сопротивление от команды в период своей работы за последние 3 года? Или все твои идеи принимаются на ура и со всем команда соглашается говорит: «Конечно, Тагир, давай воплощать!»?
Тагир: Чаще с моими идеями соглашаются, но бывало, что я что-то придумал, а люди как-то усомнились, и в итоге мы не стали это делать. Я с ходу каких-то ярких примеров не вспомню, но такое совершенно точно бывало.
Егор: А ты доволен окружающими тебя программистами? Они тебе в уровень? Они так же с тобой мыслят? Они так же понимают, что такое качество кода, что такое правильный дизайн, правильная архитектура? Или есть люди, которых ты хотел бы научить и поднять их уровень?
Тагир: Программистами, которые давно работают, общей командой, я в целом доволен. У нас иногда появляются интерны, в том числе которых я лично брал — то есть студент, которого мы взяли на летнюю практику, а потом преобразовали в постоянного работника. Понятно, что тут нужно какое-то обучение, менторство, просто потому что у человека недостаточно опыта. Но при этом обычно нам удаётся брать людей, у которых в голове уже есть правильное понимание. То есть они понимают, например, что качество — это важно.
У нас несколько специфическая ситуация, потому что мы как раз работаем над продуктом, одна из целей которого — это помогать людям делать качественный код. Мы делаем инспекции, подсвечиваем некачественный код. Поэтому, так как люди этим занимаются, у них есть понимание, что качество кода — это важно.
Егор: А сколько у тебя сейчас людей в команде?
Тагир: Я думаю, человек восемь.
Егор: А вы с удалёнными программистами работаете? Или все сидят в офисе в Новосибирске?
Тагир: У нас несколько офисов: большой офис разработки в Санкт-Петербурге, есть офис в Мюнхене, и в Новосибирске, собственно, у нас маленький офис, у нас там примерно тридцать человек.
Егор: А вот эти восемь, они где?
Тагир: По факту, вся команда распределена. То есть у нас есть кто-то в Мюнхене, несколько человек в Санкт-Петербурге, несколько человек в Новосибирске и один человек удалённый, который, насколько я понимаю, в офисах вообще не сидит.
Егор: А ты сидишь в офисе? Или ты дома работаешь?
Тагир: Да, я сижу в офисе, потому что у меня в офисе более комфортные условия. Мне в принципе нравится ходить в офис. Во-первых, мне недалеко, 20 минут от дома пешком, во-вторых, там всё-таки более рабочая обстановка, то есть дома дети…
Егор: Компания требует от тебя этого или ты можешь из дома работать?
Тагир: У нас не сильно приветствуется работать из дома, но к нашему офису пока нет таких серьёзных требований: просто потому что он маленький, он всё равно далеко, и там сидит по два-три человека из разных команд. То есть человек, который сидит в Новосибирском офисе, всё равно удалённо взаимодействует с основной командой, и особой разницы нет, как если бы он дома сидел. Поэтому к нам таких жёстких требований не предъявляют, но компания за то, чтобы люди сидели в офисе, общались, обменивались знаниями.
Егор: А ты лично за что больше? Как тебе удобнее? Работать с удалёнными людьми, или чтобы все сидели рядом с тобой?
Тагир: Я не знаю, у меня нет особой позиции на эту тему. В принципе, если бы все сидели в одном офисе, может быть, это было бы несколько продуктивнее, но в современном мире есть нормальные способы как бы снизить проблему удалённости — видеоконференции, скринкасты, любые технические решения. И эта проблема не сильно выпирает, скажем так.
Егор: А ты бы хотел работать в другом месте, например? Поехать в другую страну? Немножко такой вопрос о твоих личных планах. Новосибирск тебе кажется местом, где стоит провести следующие 10 лет жизни, или ты думаешь о каком-то перемещении?
Тагир: Я по своей натуре домосед и, в принципе, меня вполне устраивает Новосибирск. Сейчас у меня нет планов куда-то переезжать из Новосибирска.
Активность в open source
Егор: А технически тебе хватает сложности задач, которые вы решаете, для твоих амбиций? Раньше ты занимался своим опенсорсным проектом, а сейчас больше находишься в корпорации. Тебя эта ситуация устраивает? Правильно понимаю, что сейчас у тебя нет своих опенсорс-продуктов, которые ты бы поддерживал?
Тагир: В некотором смысле мой опенсорс-продукт — IntelliJ IDEA.
Егор: Но он не твой, он же всё-таки принадлежит компании.
Тагир: Он, естественно, не мой, да. Но я считаю, что мой вклад в продукт достаточно видимый, и я не маленький винтик в огромной корпоративной системе. Например, я могу увидеть, что Java-разработчик делает в IDEA, и радостно подумать: «Да, он пользуется кодом, который я написал».
То есть амбициозность в плане воздействия на мир Java-разработки вполне покрывается. Каждый участник нашей команды может сделать что-то заметное, чем люди будут пользоваться, и это будет хорошо.
В плане сложности задач тоже. Бывают задачи интересные, сложные и некоторые вполне наукоёмкие, с которыми нужно посидеть. Есть задачи, которыми можно заняться, но они, возможно, даже выше моего текущего уровня, мне придётся посидеть, поизучать теорию, возможно, почитать научные статьи. Если у меня будет прямо рвение как-то эволюционировать, узнать что-то такое новое о программировании, то такие задачи вполне есть.
Егор: А какая судьба этого StreamEx твоего? Что с ним сейчас?
Тагир: StreamEx находится в состоянии вялотекущей поддержки, но я считаю, что это более-менее законченная библиотека. Иногда думают, что либо люди пишут программу, либо она заброшена и всеми забыта. Я считаю, что бывают программы, которые написаны. И StreamEx как раз в таком состоянии, когда это законченная программа, она делает то, что надо, и новые фичи в ней не сильно нужны. Там есть некоторые текущие проблемы, но они совершенно мелкие, и я их иногда решаю.
Егор: А ты их решаешь в рабочее время или по выходным?
Тагир: Когда как, по настроению. У нас в этом плане тоже нет строгих требований, у нас есть эта система 20%-х проектов. То есть, если я делаю что-то, что или промоутит нашу компанию, или в целом совершает вклад в программирование, чем-то помогает нашим разработчикам или просто помогает в рамках программирования, то никто не будет против, если я на это потрачу небольшую часть рабочего времени.
Егор: То есть вам разрешено в опенсорс контрибьютить в рамках рабочего времени 20%, если не больше, правильно я услышал?
Тагир: Больше 20% не стоит, но в принципе да, на это можно тратить время. Например, я иногда делаю коммит в Java, в OpenJDK, и спокойно на тех же стендапах в компании говорю: «Вот сегодня я делал фичу для OpenJDK», — и это нормально воспринимается.
Конференции
Егор: А как часто сейчас ты выступаешь на конференциях? Я тебя встречаю достаточно регулярно, но не знаю точно, какое у тебя расписание. Сколько выступлений ты делаешь в год?
Тагир: Где-то выступления три-четыре.
Егор: А для чего тебе это нужно?
Тагир: Скорее это просто удовольствие. Хотя сейчас мне уже кажется, что что-то много выступаю, может быть, буду реже. Потому что всё-таки требуется довольно много усилий, чтобы подготовить хороший доклад.
Это удовольствие, потому что, по большому счёту, это общение. Ты приезжаешь на конференцию с докладом, и твой доклад — это тема для разговора: потом подходят люди и продолжают с тобой разговаривать на эту тему. Можно от них что-то интересное узнать, можно им что-то сказать.
Егор: JPoint — это твоя одна их любимых конференций? Как ты её оцениваешь?
Тагир: Да. Во-первых, JPoint — это была первая конференция, на которую я поехал в 2015 году. Сперва поехал просто как участник, и для меня это был «глоток свежего воздуха», потому что я не знал, что есть сколько людей, которые делают такие совершенно интересные сногсшибательные вещи. Я там познакомился с некоторыми спикерами, с некоторыми интересными участниками. И после этого у меня возникла идея, что я могу и свои доклады делать, мне тоже есть, что сказать людям. И с 2015 года я каждый год приезжаю на JPoint, пятый год уже.
Егор: Спасибо, у меня вопросы кончились.
Скоро в словах Тагира «приезжаю на JPoint уже пятый год» пора будет инкрементировать переменную. В мае он снова приедет в Москву — и расскажет, «заменят ли компьютеры программистов» (ему, делающему анализ кода в IDE всё умнее, здесь наверняка есть о чём сказать).
В общем, говоря словами самого Тагира, в мае он снова получит удовольствие от общения. Если вы тоже хотите получить удовольствие от общения с ним и другими спикерами/участниками — вся актуальная информация о конференции есть на сайте, там как раз появились первые описания докладов, в том числе и к выступлению Тагира.
Автор: Евгений Трифонов
