Всем привет. Это снова «Без слайдов», и сегодня у меня для вас интервью с Дмитрием Нестеруком aka mezastel, техническим евангелистом компании JetBrains. Дмитрия я знаю довольно давно и, не скрою, сам очень долго ждал момента, когда мы наконец поедем на студию и запишемся. Уж больно много вопросов у меня к нему накопилось.
Мы больше часа беседовали с Дмитрием, но не успели затронуть даже половины тем, которые хотелось обсудить. Что Дмитрий успел рассказать мне:
Вот видео, а под катом, как обычно, текстовая версия этого интервью.
(на одиннадцатой минуте нет звука, к сожалению.)
— Дима, у меня к тебе такой вопрос – кто такой технический евангелист? Какие у него обязанности? Что он делает?
— Прежде всего, я должен сказать, что мы отказались от термина «технический евангелист». Мы перешли на другой термин — Developer Advocate, потому что евангелизм так или иначе у некоторых людей в голове сильно связан с какими-то религиозными направлениями. И вообще «евангелие» – «как мы несём благую весть» – это слишком претенциозно, я бы сказал. Это типа – вот, мы пришли вас спасать от плохих практик разработки, поэтому – Developer Advocate. То есть, человек, который отстаивает некие принципы хорошей разработки, допустим, через, в том числе, и инструментарий. Поэтому это человек, который занимается тем, что делает доклады на конференциях, работает на стенде на конференциях.
То есть, есть конференция – на ней можно поставить стенд и там сотрудники компаний будут показывать, рассказывать, давать всякие брошюрки и интересные подарки, и просто общаться с пользователями. Потому что одно дело, когда мы общаемся с пользователями через интернет, и другое дело, что иногда хочется вживую получить фидбек. И некоторым людям хочется видеть живых разработчиков JetBrains, чтобы подойти и сказать – «Вот, ребята, смотрите – у меня такая проблема, вы её не решаете – давайте прямо сейчас, здесь, на конференции её обсудим». И это, мне кажется, здорово.
Помимо этого мы делаем некие маркетинговые материалы – в частности, скринкасты, вебинары…
— Блоги.
— Блоги, опять же, да. То есть, с одной стороны мы действительно описываем фичи наших продуктов, но у нас сейчас уклон идёт в то, чтобы делать общие технологические вещи. Если вот посмотреть на мои вебинары – например, последний – там мы не делаем такого, что «Вот, смотрите: вот наш продукт и вот наши фичи, мы сейчас вам по полочкам разложим, что там есть». То есть, такие вещи мы делаем просто скринкастами, а фичи продукта мы показываем в ходе какой-то тематической беседы. Например, давайте обсудим современный С++, какие там языковые фичи — и вот в фоне используется наш редактор, какие-то наши фичи, возможно, но мы как бы даже не упоминаем…
— В общем, понятно, что это некий трюк, эта техника называется product placement и известна ещё со времён первых фильмов о Джеймсе Бонде. То есть, 50 лет.
— Нюанс заключается в том, что пользователи, по сути, не хотят маркетинга. Многие компании не понимают, что если ты делаешь конференцию или event, полностью состоящий из маркетинга, то у людей будет какое-то отвращение. Вот мы так не делаем. Поэтому все доклады, которые я подаю на конференции – они все просто тематические. Есть конференция по С++ – я рассказываю, как делать что-то интересное на С++. А product placement – да, он есть в фоне и он никому не мешает. То есть, если я сделал что-то с, допустим, CLion, но если вы хотите использовать Eclipse, то – вперёд, никаких проблем.
— Ну понятно. Как по ощущению – евангелизм в JetBrains – он работает или не работает? Он помогает компании или нет?
Дело в том, что мы не единственные, кто занимается евангелизмом. Евангелизмом, например, занимается Microsoft и наши подходы кардинально разные, потому что у Microsoft более формальный подход – то есть, они нанимают стороннюю компанию, которая потом занимается тем, что она обзванивает потенциальных пользователей, неважно студенты это или бизнес, и спрашивает их: «Ребята, мы сделали мероприятие. У вас повысилось желание поставить Windows 10?».
Эти метрики – это KPI и эти метрики, фактически, делают бонусы евангелистам и т.д. Понятное дело, что у Microsoft в России, поскольку, в основном евангелизм, то у них команда больше и всё это систематизировано.
У нас команда человек шесть, по масштабам JetBrains — микроскопическая. И у нас никаких KPI толком нет. То есть, мы сами для себя понимаем, что мы сделали офигенно, а что мы сделали обычно. То есть, если, допустим, человек зарелизил какую-то офигенную вещь, которую весь мир заметил – что-то такое крутое сделал, то мы понимаем, что — вот, смотри, это achievement. Нам не нужно сторонней валидации, потому что продажи продажами – то есть, у нас нет таких метрик, что «Вот, смотрите – мы сделали event и после него продалось столько-то лицензий». Мы в таком ключе не думаем, мы просто делаем всё, что мы можем.
Те же скринкасты нужны, потому что у тебя есть продукт и люди хотят знать, что за фичи в нем есть. Они могут сухо страничку почитать или могут посмотреть видео. То есть, мы знаем, что есть скринкасты, что есть в них потребность, мы можем смотреть статистику просмотров. Но понять что вот эти конкретные скринкасты привели напрямую к продажам — очень трудно. Математически очень сложно показать и мы этим не занимаемся. У нас есть понимание того, что это нужно, поэтому мы это делаем и стараемся делать хорошо. И все.
— То есть, фактически, это на уровне внутреннего ощущения?
— По сути дела, да. То есть, мы сами для себя видим, когда что-то получается хорошо. Когда какая-то вещь, условно говоря, выстреливает. Например, ты делаешь вебинар, и на него записывается столько людей, что тебе приходится делать второй такой же. Вот это хороший критерий. Опять же, да, естественно, что и мы, евангелисты, и менеджеры по маркетингу тех или иных команд – мы всё-таки смотрим на продажи, мы смотрим на скачивание – мы держим руку на пульсе. В том смысле, что если где-то нужно поднажать – то мы, может, поднажмём. Но вот такой прямой привязки к каким-то метрикам, что «Вот, смотри, я напродавал через евангелизм больше, чем ты» — такого нет.
— Это хорошо или плохо?
— Мне кажется, что это хорошо. Потому что через KPI можно делать всякие нехорошие вещи. То есть, ты можешь, например, иметь евангелиста по продукту, который не очень коммерчески успешен и, согласно KPI, ему будут меньше бонусы – потому что продукт меньше успешен, соответственно, и ты меньше получаешь. Вот у нас нет такого и, на самом деле, у нас продукты продаются по-разному – есть очень успешные, есть не такие успешные. И есть, продукты, которые евангелисты покрывают – есть продукты, на которых, к сожалению, евангелистов пока нет. Как я уже сказал, команда очень маленькая, а продуктов много.
— Почему компания не хочет её расширять?
— Дело в том, что поиск евангелистов – это очень тяжёлый процесс. Потому что тебе нужен человек, который: во-первых, технически компетентен – в том, смысле, что у него уже есть опыт разработки и, на самом деле, мы настаиваем, чтобы человек продолжал писать код. Понимаешь, во многих компаниях, не называя имён, евангелисты – это люди, которым дают слайды и они их рассказывают. И всё.
А нам нужно, чтобы человек был и технически подкован – чтобы на любой вопрос ответил (то есть, если ты делаешь, допустим, рассказ про С++, то ты должен знать С++, ты должен на нём писать). И одновременно мы хотим, чтобы у человека были навыки общения, навыки коммуникации, чтобы он был готов летать по миру постоянно. И что-то рассказывать или просто общаться. И это сложно. Это реально сложная задача, потому что таких людей не так много.
— Вот я знаю Баруха Садогурского, и он говорит, что термин «Developer Advocate» вы стырили у них. Он шутил, что ему религия не позволяет называться евангелистом и по этому поводу он Developer Advocate. А сейчас такое название вашей профессии действительно стало трендом. Барух большой молодец. В Java мире он, наверное, такой самый известный Advocate.
— Понимаешь, это в каком-то смысле шоу-бизнес. Естественно, ты возвращаешься домой и пишешь кучу кода, дебажишь и копаешься во всём этом, но когда ты выходишь на публику – да, это шоу-бизнес, насколько хорошо ты можешь донести какую-то тему.
Ещё одна вещь, которую я не упомянул, которую тоже очень важно упомянуть – это походы к клиентам. То есть, мы, помимо поездок на какие-то мероприятия, мы ещё пишем – либо по потенциальным, либо по уже существующим клиентам. Мы говорим: «Ребят, хотите пообщаться? Мы придём, мы вам можем что-то рассказать, мы можем посидеть с блокнотом, записать ваши проблемы, посмотреть, как мы можем их лучше решить».
Вот, например, ты приходишь в какой-нибудь хедж-фонд или инвестбанк – тебе нужен человек, который говорит на их языке. И это тоже проблема. Потому что таких людей не найти. У нас есть сейлзы, понятное дело, но они тебе скажут, сколько это стоит, какие мы можем скидки для вас сделать. А тебе хочется, чтобы кто-то живой, кто «Вот, смотри – у меня тут обсчитывается то-то и не работает то-то» и мы можем прямо смотреть на этот код и что-то с этим делать. То есть, это тоже часть работы.
— Если попытаться по процентам твоего рабочего времени это всё разложить – как у тебя примерно получается? У вас же, наверное, в команде это по-разному, да?
— Слушай, на самом деле, всё очень не однородно в том смысле, что действительно есть мероприятия, на которые мы просто будем ездить каждый год практически, и то иногда мы делаем перерывы. Есть мероприятия, которые год от года поражают воображение. Допустим, ты знаешь, что там будет 20 000 человек на 3 дня и поэтому лучше не пропускать этот ивент. Поэтому в этом есть некая регулярность.
Ещё есть регулярность, конечно, в релизах – то есть, когда происходит какой-то релиз, то ты должен подготовить материалы для этого релиза. Например, скринкасты, которые описывают все фичи, потом покусочно как-то, блок-посты какие-то, но помимо этого есть очень много просто случайных вещей, причём инициатива не наказуема.
Я, например, делаю просто иногда вебинары – мне хочется поговорить про генеративное искусство. То, как программа генерирует – это реально такой маленький бизнес, который мы с моим сыном делаем. Генерировать случайные картинки, потом их в рамочку со стеклом и все дела. Вот, и я про это рассказываю. Делаю вебинар, например. То есть, у нас много таких спонтанных активностей – мне кажется, это тоже хорошо, потому что, с одной стороны, это привлекает людей к JetBrains, с другой стороны, там никакого втирания продукта – вообще ничего не такого.
— Ты понимаешь, что ты… Только не бей меня и не тыкай в меня ножом. Что ты абсолютный гик. То есть, человек, который с сыном занимается компьютерным искусством – его другим словом не назвать.
— Я тебе скажу больше – я обучаю сына программированию на FPGA, поэтому…
— То есть, твой сын тоже гик!
— Не знаю, в таком возрасте ещё рано говорить про гиков.
— Этот термин вообще сам по себе странный… У тебя есть ощущение, что ты воспринимаешь мир — и индустрию, и профессию, и отрасль — не так, как люди вокруг тебя в том же JetBrains, например?
— Это есть. И это, я бы сказал, было всегда, потому что я, когда только начал работать в IT-индустрии, когда я всё-таки решил не писать диссертацию, а пойти работать – я попал в очень странное место. В место, где, скажем так, мало кого интересовало вот это вот The Art of Programming.
— Это было в Петербурге?
— Да в Питере.
— Я знаю даже, что это за место – мы не будем его называть.
— Не будем. И, соответственно… Я бы не сказал, что я тогда был более гиком – просто я читал все книги, мне хотелось всё знать и, соответственно, я быстро вырос, но у меня быстро создалось впечатление, что просто никого вокруг ничто не интересует как на уровне софта, так и на уровне железа, а меня интересовало всё и сразу. То есть, соответственно, ощущение того, что IT, на самом деле, не такое гиковое, как могло было бы быть – оно до сих пор у меня есть. Потому что у нас есть некие конкретные люди, которые прямо прутся от технологии и им хочется всё знать, в том числе заниматься вещами экзотическими FPGA, XeonPhi, CUDA и т.д. Но большинству людей ничего этого не нужно. Большинству людей нужна просто зарплата в конце месяца. И всё.
— Пусть это нашим слушателям и читателям покажется снобской позицией, но в целом я с тобой соглашусь. У меня есть такое ощущение, что для многих IT — это просто способ существования такой. Это не увлечение и не хобби… Это же очень грустно. Если говорить более глобально – в мире огромное количество людей, которые занимаются тем, чем они не очень хотят на самом деле заниматься. Я вот только не знаю, насколько это именно для IT характерно или это вообще для мира?
— На самом деле, если говорить про своё неудовольствие жизнью, скажем так – я считаю, что IT ещё нормальная индустрия в этом плане. Например, у нас нет сильных физических нагрузок.
— И в нашей индустрии кое-что платят, всё-таки.
— Да, кое-что платят. То есть, если посмотреть на средние заработные платы по миру для программистов – это 80 000 $, то есть, на это как-то можно жить. В России — в два с половиной раза меньше, но всё равно на это можно существовать. Поэтому естественно, что частный самолёт, наверное, нет, но для нормальной машины, квартиры, дачи – этого вполне хватает. Поэтому я никого не виню, я не говорю что плохо, когда люди идут в IT за стабильным доходом.
Другое дело, что в глобальном разрезе IT — это достаточно бедная индустрия. Как-то я был в гостях у подкаста «Разбор полетов» и честно сказал в эфире, что айтишник, то есть программист типичный – это даже не средний класс. Это рабочий класс, это некая функциональная должность, потому что сама индустрия IT по большому счету не является системообразующей. Она обслуживает другие индустрии — ритейл, банки, инвест-компании…
— Любой бизнес.
— Любой бизнес. Она обслуживает бизнес так же, как бизнес обслуживает аудит, как бизнес обслуживает бухгалтерия и все такое.
— То есть типичный кейс – это снизить издержки за счет внедрения некой автоматизации в каком-то бизнесе?
— Да.
— Меня, конечно, зацепил сейчас момент, насчет того, что мы бедная индустрия. Если сейчас какому-нибудь программисту сказать, что ИТ – это бедная индустрия, то, скорее всего, он тебя не поймет. Ты можешь раскрыть немножко эту тему?
— ИТ – бедная индустрия по той причине, например, что большинство разработчиков не могут по-хорошему позволить себе результат своего собственного труда. У нас появляются очень интересные технологии, из тех технологий, которые спасают душу индустрии, например, я бы назвал появление SSD, потому что до SSD работа с диском была просто мучительной операцией если у вас какой-то random access, а не просто линейные операции — все, смерть. Поскольку мы делаем IDE, для нас это больная тема, потому что разработчик без SSD он просто будет страдать.
Соответственно, когда я делаю доклад по эффективной разработке, я рассказываю про то, как внедрять более серьезные, чем SSD, технологии. А потом ко мне подходит директор какой-нибудь аутсорсинговой компании и говорит: «Знаешь, у нас нет денег, на то, чтобы разработчикам поставить SSD».
Cамое главное, что в свое время когда я работал, я ощущал примерно те же проблемы, т.е. ты работаешь разработчиком, а тебе компания не может поставить нормальный комп. Компания ставит комп, где 4 гигабайта оперативки. Или ты приходишь на работу, и тебе дают один экран. Я хочу, например, шесть, ну или хотя бы три. А на меня смотрят как на идиота. А я смотрю на эту вот индустрию, как на идиотскую индустрию в обратную сторону, потому что понимаю, что второй монитор — это не такая дорогая вещь.
— Я в свое время попал на работу в компанию Oracle. Прекрасная компания, но мне тоже дали один 19-дюймовый монитор. Но я просто взял и принес еще один свой, купил.
— Разработчики так и делают.
— Да проблема в том что, мне кажется, я был один такой. Т.е. всех остальных полностью все устраивало.
— Да. Менталитет людей он уже настроен такой, что вот, что нам дядя дал…
— Не, я не один такой был. Был еще один чувак, который был моим ментором, он тоже правильный чувак на самом деле.
— Я видел, как люди заменяли диски на SSD.
— Или памяти доставляли.
– Сейчас, допустим, в JetBrains таких косяков нет, но если ты выйдешь за пределы JetBrains или еще нескольких хороших компаний и пойдешь по аутсорсам… Я бывал в местах достаточно ужасных. Именно не работал, а бывал. Там народ сидит в развалившемся заводе, у них у всех трубчатые мониторы…
— Когда это было?
— Это было году в 2008, может в 2010… Но понимаешь, SSD и мониторы – это верхушка айсберга. Мы говорим про SSD, мы не говорим про PCIe-based SSD-носители, мы не говорим про FusionIO-носители, мы не говорим про всякие экзотические…
— Не, ну PCIe и M2 – уже идут в индустрию.
— Если зайти сейчас в любую компанию и спросить, кто использует М2…
— Да кто хотя бы SSD использует? Я думаю, что уже на этом этапе мы закончим наше «исследование».
— А на самом деле, вещи, которыми я занимаюсь, т.е., например, использование GPU, Xeon Phi, FPGA — это вещи, которые давно существуют, ты можешь пойти на рынок и их купить. Но ИТ-индустрия, она либо делает вид, что они не релевантны, что их вообще не нужно рассматривать, либо она говорит, что это дорого. Она просто говорит, ну вот смотри, разработчику платим две тысячи долларов в месяц. А ты предлагаешь за две тысячи или за пять тысяч долларов купить какой-то девайс, который, типа, ускорит нам жизнь, но мы не очень понимаем, как он нам позволит больше зарабатывать.
— Наверное, я совершенно не понимаю индустрию. Типичная маржа для российских аутсорсеров — это 30%. И это очень высококонкурентный бизнес. И правда в том, что если ты начнешь инвестировать в мониторы и SSD, то у тебя маржа упадет и ты проиграешь конкуренцию.
— Мне тоже кажется, что это просто плохой бизнес. Тут нужно подчеркнуть такую вещь, что по идее, аутсорсу важна стоимость инженерного часа. И если у них появилось оборудование, которое уменьшает количество этих инженерных часов, то непонятно, что это им дает. Да, они зарелизят быстрее, продукт возможно. Но они получат меньше денег.
— Они быстрее сделают это продукт и, значит, им надо будет искать нового клиента.
— Это один пример. Другой пример: есть компания-монополист. Ей плевать, разработка идет два года или двадцать лет. Потому что ее устройства все равно будут покупать. Соответственно, как ты думаешь, какой у нее стимул делать что-то постоянно?
— Никакого.
— Ноль, абсолютно. Поэтому у меня такие претензии к IT. Потому что IT — это индустрия, которая лукавит. Она говорит, что «вот смотрите, мы все улучшаем»
.
— «Новейшая нанотехнология.»
— Да, но с другой стороны тебе может начальник сказать: «слушай, вот конечно ты мне крутую штуку показал, но, блин, давай как-нибудь вы пока без нее». И это не какие-то выдуманные истории, это реальные истории. Компании, например, качественную IDE просто не хотят покупать, потому что им дорого. Хотя на самом деле, если посмотреть на ценник в разрезе тех же зарплат…
Но ты правильно сказал про маржу, маржа 30% — это, знаешь ли, хорошая маржа. Это скорее маржа аутсорсера, который работает «в черную», ему платят долларовым налом… Более реалистичная маржа для какого-нибудь крупного «белого» аутсорсера — 10-15%. И тогда инвестиции в IDE будут выедать из маржи…
— Мне кажется в России это бы никогда не работало. Потому что если тебе скажут, мол, чувак, ты бизнес сейчас будешь делать с маржой 10% — он скажет «да иди ты нафиг!». У нас инфляция выше…
— Возможно, в крупном, массовом аутсорсе 20% — это приемлемая сумма. Т.е да конечно люди хотят себе большую прибыль и сразу и это понятно.
— Я просто вообще не понимаю, может ты мне объяснишь… Мне кажется, что бизнес этот — очень сложный. Я имею в виду аутсорс, или то, что сейчас называется Service Company. Например, есть, крупная компания Luxoft. Они довольно прикольные, они научились довольно интересные вещи эффективно делать. Agile-процессы давно у них выстроены просто лучше всех…
— Иначе у них никто не закажет.
— Да. В этом смысле они дико крутые и в этом месте они являются двигателем индустрии. У меня ощущение что движение возникает тогда, когда есть некие ограничения, которые на тебя накладываются. В этом случае рынок труда, рынок заказов и все, что угодно – все начинает развиваться. Но, к сожалению, у них развивается история, связанная с процессами с эффективностью коммуникации только за счет давления рынка, а при этом технологическая составляющая просто просаживается.
— И в этом гигантская проблема, потому что люди видят, что их доход зависит от других вещей, и это парадоксально. И очень грустно. Мы действительно находимся в такой ситуации, когда самые новейшие технологии нужны лишь для рыночной эффективности, только для процента, который там их для чего-то действительно использует. Т.е закупит какой-нибудь Fusion IO, и все свои сервера выкинет, оставив всего десяток. А остальным все это не актуально. Это на самом деле грустно.
Но, с другой стороны, это рынок и против него не попрешь. Понимаешь, у нас есть такая идеология, что программисты любят разработку не из-за денег, а из-за того, что девелопмент — это, типа, офигенно интересно. Действительно, технологии, которые я упоминал — очень интересны. И сами по себе они — это прогресс. Но, если люди с ними не работают, то… как вы стимулируете разработчиков? То есть, им же должно быть интересно, они должны куда-то двигаться. Но к сожалению, вот именно в аппаратной сфере и сфере эффективного использования технологий есть большие проблемы.
— Знаешь еще, когда ты говоришь о том, чего мы не можем себе позволить, мне на ум приходят в первую очередь разные дорогие Enterprise-решения.
— Дорогие Enterprise-решения — это позор нашей индустрии. Потому что если ты посмотришь на решение командной разработки от IBM, то они бессмысленны и беспощадны. Они тебе будут стоить тысячу долларов на разработчика в год. Это одновременно и дорого и плохо.
С другой стороны, крупный Enterprise другому крупному Enterpris-у продаст такое решение вместо того, чтобы иметь что-то маленькое, легковесное и качественное. Поэтому я толком никогда не был фанатом крупного Enterprise. Но не надо смешивать Enterprise с какими-то аппаратными технологиями, с действительно прогрессивными вещами. Потому что помимо того, что индустрия делает интересные вещи для разработки, у нас есть параллельный мир, в котором люди плевать на это хотят при этом все равно продают свои процессы разработки и сопутствующие технологии. И кто-то это покупает. И это не просто иллюзия, а действительно вполне себе рынок.
Другое дело, что мы, как люди, которые заботятся об эффективности и о том, чтобы действительно что-то сделать— мы этим, толком, не занимаемся и даже порой не видим. Компания в которой я начинал работать она использовала Rational ClearCase, она использовала Rational ClearQuest, которые сейчас IBM-овскими стали. И это тихий ужас. Качество этого софта было ниже плинтуса. Оно настолько плохое, что непонятно, кто и как его писал. Продается оно за бешеные деньги, но очень плохо работает. Возникает вопрос: «а как такое вообще возможно? Кто это допустил? Как вообще это попало на рынок и как это кому-то продалось?».
— Это некомпетенция? Это какой-то коррупционный сговор?
— Ну, что-то вроде. Но по ощущениям, это действительно что-то вроде сговора, не знаю, коррупционного или нет… Может это просто блестящий маркетинг, потому что у нас даже если шагнуть за пределы IT, у нас есть прекрасные примеры абсолютно отвратительных товаров, которые выезжают на прекрасном маркетинге.
Вот если взять например наушники Beats, которые сейчас Apple купил, — это наушники с ужасным качеством. Но они вливают столько в маркетинг, и ты знаешь, что все спортивные и голливудские звезды в этих наушниках. И этот плохой товар, благодаря маркетингу, продается!
— Ты затронул тему качественных и некачественных инструментов. Попробую такой простой, но не очевидный заход сделать. Ты говоришь о том, что мы, айтишные компании, не можем себе позволить нормальные айтишные решения. Ты пытался что-то сделать с этим в JetBrains? Ты пытался эту мысль до кого-то донести или нет? И, если пытался, то в каком ключе? Вопрос такой: можно ли как-то трансформировать существующую вашу линейку продуктов, с учетом вещей, о которых говоришь ты?
— Я бы сказал, что нужно разделять эти вещи. Мы сейчас говорим об инструментах разработки и о том, как мы готовы ускорить процесс или сделать более глубокий анализ. Что мы можем сделать? У нас естественное ограничение — это железо, которое стоит у тех, кто пользуется нашими решениями. Поэтому влиять нужно на них, а не на нас.
— Вот смотри, вот вы сидите в JetBrains, у вас по два монитора, у вас хорошие «жирные» компьютеры. А теперь представь себе человека, который сидит за слабеньким железом с одним 19-дюймовым монитором и пытается в ReSharper что-то сделать. У него «отжирается» вся память и тормозит все, что можно. У вас есть хоть что-то для него? Вы понимаете этого вашего конечного пользователя? Ведь он бесконечно далек от вас!
— Идет постоянный процесс по оптимизации. Оптимизации использования памяти, оптимизация производительности. Помимо ReSharper, у нас есть свои инструменты для профилирования. Мы пытаемся сделать все возможное. Естественно, это борьба с рантаймом, борьба с GC, и тут непонятно, что делать.
Вопрос, который ты задал, он более глобальный, в том смысле, что если бы задать вопрос так: «Почему вы не поддерживаете GPU?» Это хороший вопрос, потому что, по идее, если мы посмотрим на срез софта, который есть вообще в мире, очень мало софта поддерживает GPU. Есть Adobe и есть какие-то решения, которые используют CUDА. И тут можно было бы что-то сделать, но, опять-же, это очень нестабильный подход.
x86 — он везде. Вот ты написал свою Java- или .NET-программу… Под x86 у тебя не будет никакой векторизации, вот всего этого продвинутого…
— Это не совсем так. Скажем, в Java точно в простых случаях это все есть. Какое-нибудь сложение целых чисел в цикле — JIT-компилятор шикарно с этим справляется.
— Это только в простых случаях. Говоря глобально, этот вопрос — как эффективно амортизировать по максимуму железо — он очень актуален. Например, у меня ноутбук, там дискретная отдельная большущая графическая карта, с которой я, в основном, ничего не делаю. Я бы с удовольствием дал ей возможность сделать что-то полезное
Отчасти, это все происходит по тем же причинам, по которым, очень тяжело, допустим, SIMD поддерживать. Потому что SIMD, то есть, большие регистры на CPU, и возможность работать с ними — они эволюционируют во времени. В старых процессорах они такие, потом они становятся больше, больше и ты не знаешь под какой стандарт писать, потому что это все не проходит. Это compatible в том смысле, что если ты скомпилировал программу под AVX, а на компьютере нет AVX – программа просто падает, потому что ты пытаешься выполнить инструкцию, которой на твоем процессоре нет.
— На самом деле, это решается в Runtime. Современный Runtime просто спрашивает процессор, мол, чувак, у тебя есть AVX или нету? JIT-компилятор этим и хорош, что он сам спросит у Runtime: «у тебя есть или у тебя нет?» и в зависимости от этого примет то или иное решение оптимизации.
— Да, компилятор за тебя может сделать какие-то выводы насчет векторизации только если он может посмотреть на свой цикл и однозначно понять, что там никаких зацепок по данным нет. А если он не может этого понять, у тебя все будет идти через обычные регистры, и все.
— Как вообще в .NET обстоит дело с векторизацией?
— Ее нет. Ее сейчас делают для нового RuyJIT. Получилось довольно интересно, потому что Mono, линуксовая реализация .NET, давно уже сделали Mono.Simd — это такой Explicit API для векторизации. Конечно, это не JIT, который тебе все автоматически векторизует. Это именно Explicit штука, все нужно делать руками— оперировать векторами напрямую. Естественно, есть понимание того, что это, в принципе, надо.
— Иными словами, в Mono есть API, который заставляет Mono Runtime делать векторные операции?
— Да.
— Но это извращение, это явно не то, что нужно.
— А непонятно: мы далеко не всегда знаем, что на самом деле нужно…
— Почему я, как разработчик, должен это руками делать? Логичным будет разделить здесь ответственность. Для того, чтобы мне понять, что какое-то место в моем коде тормозит, мне надо профилировать, понять, что именно там можно развязать, и переписать это с помощью API, о котором говоришь… Но это дополнительные и трудные довольно шаги.
— Я, честно скажу, не сторонник автовекторизации и вообще автоматических решений, потому что они работают только на тривиальных примерах. То есть, если ты параллелишь цикл, то он прекрасно распараллелится — твой плюсовый компилятор просто перепишет на OpenMP, и все будет прекрасно. А вот если у тебя что-то посложнее, допустим, параллельная обработка не массива, а дерева — тут все, труба. Весь твой подход развалился.
— Нужно заменить одну конструкцию на другую, семантически эквивалентную, которая обладает лучшей производительностью.
— Я тебе приведу такой пример. Ну, вот есть у нас SIMD, мы можем два массива из четырех чисел быстренько сложить, в регистрах получить результат. Представь, что я хочу использовать SIMD для поиска подстроки. У меня есть гигантский массив именно букв, а буква, допустим утрированно, это два байта. Автоматическая векторизация тут неприменима в принципе, потому что мне нужно брать массив одного типа, но рассматривать его как массив другого типа и использовать SIMD не просто для конструкций типа add, а использовать более сложные механизмы сравнения для того, чтобы сравнивать по четыре или по восемь символов сразу.
— Очевидное решение, как мне кажется, это просто считать за букву сочетание некоторое. То есть это автоматически одну задачу сводит к другой. Это, вроде, несложно делается.
— Но ты это будешь делать руками, это не будет автоматически сделано. И это уже решения неочевидные. На самом деле, вот одна вещь, которая мне нравится, —суперкомпиляция. Это механизм, который пытается выводить идеальный набор инструкций для определенного input и output. И это очень интересно. Берешь какую-нибудь задачу, которую я описал, скармливаешь ее суперкомпилятору, он тебе может выдать на выходе непредсказуемую, неожиданную вещь, но внезапно она работает очень эффективно…
Знаешь, вот я описал только что задачу, а там он может каких-нибудь хитрых сдвигов наделать, причем и в x86 и, в том числе, во всяких там SSE и AVX-инструкциях. Там есть инструкции, которые очень сложные, какой-нибудь хитрый сдвиг…
— Я такое видел в элементарных вещах, например, в простом сложении.
— На интеллектуальном уровне сложно понять, а зачем эта инструкция вообще была сделана. Если ты, какой-нибудь такой подход используешь, — ты получаешь гигантский выигрыш. Но тут уже мы немножко отъезжаем от темы человеческого, потому что это уже более эмпирическое решение.
— Такого довольно много во всяких компиляторах современных, потому что отсюда эта история и берется: если человек или компьютер каким-то хитрым путем понял, что некая хитрая конструкция работает быстрее, чем наивная – то давайте это просто применим и будем этим пользоваться.
—Компилятор хорош, когда он может однозначно понять, что происходит. И если ты просто суммируешь циклы, то ты можешь с тем же успехом брать и делать все это на том же GPU, потому что это задачи, которые очевидно параллельны. А когда много задач, то не настолько все очевидно, система сама не поймет. Но возвращаясь к разработке, я бы сказал, что очень сложно все это как-то применять. Понимаешь, вот разбор исходного кода – это просто большое количество объектно-ориентированных структур. Они не имеют какой-то однородной формы, их нельзя просто взять, скормить на GPU. К тому же, напомню, что GPU не может просто брать текст из X86 и исполнять, оно может некое подмножество математики делать на каком-то там массиве данных. Соответственно, это подход сложный.
Другое дело, что есть много мест, где было бы неплохо получать GPU-ускорение при кодировании видео. Хотелось бы, чтобы везде все было GPU-accelerated, и последняя версия Adobe Media Encoder, часть Creative Suite, которая кодирует видео, она честно пишет, что она использует GPU и там какие-то подвижки заметны. Приятно, что хоть кто-то использует.
— Сжатие. Всем нужно ZIP.
— Да, но ситуация, на самом деле с использованием GPU достаточно плачевная все-таки. У нас просто, может, навыков нет, может, нет желания, в это влезать. У нас, как у индустрии в целом.
— А ты не думал о том, что это некие ограничения, которые просто legacy? У нас есть перед носом поразительный пример, когда целая индустрия спровоцировала рост целого сектора железного. Я говорю про игры и видеокарты. Это вообще уникальный случай, когда клиентский спрос так потрясающе двигал технологию.
— А ты заметил, что в свое время было ощущение того, что со звуком будет то же самое? Потому что тоже появлялись дискретные звуковые карты…
— Причем они все говорили, что вот, на дефолтной звук-то поганый, а вот на нашей карте звук правильный.
— Ты шел в магазин и покупал не просто звуковую карту, ты покупал звуковую карту плюс отдельный внешний усилитель, который с этой звуковой карты получал цифровые сигналы и потом на 5+1 все это раскидывал…
— И стоило это все долларов 300 минимум.
— Все это недешево, да. И было ощущение того, что это будет отдельное развитие. Но нюанс заключается в том, что люди поняли, что есть некая точка насыщения. MP3 с битрейтом 128 – это точка насыщения для большинства людей.
Соответственно вот тот пример, который я тебе привел с Доктором Дре и Beats — это хороший пример, который показывает, что возможно, людям-то и не нужно приличное качество музыки. У нас осталось ниша Hi-Fi, или Head-Fi ниша. Но она очень специфична, потому что там люди тратят гигантские суммы на усилители, наушники и так далее. Но большинство людей, если и различают как-то качество звука, им просто не нужен вот этот interference, у нас, например, есть BOSE.
Кстати, это очень хороший пример. BOSE – это компания, которая тоже делает сомнительное по качеству аудио. Но они, например, делают лучше в мире наушники с активным шумоподавлением, т.е. батарейка берет шум самолета и в противофазе его тебе в уши посылает, и это шикарная вещь. Несмотря на то, что качество звука у тебя теряется, зато у тебя идет изоляция от шума. И это прекрасно. В конечном счете вся эта дискуссия сводится к тому, что мы заложники рынка, рынок себя ведет вот так, а мы за ним идем.
Да, видеокарты — это уникальное решение, потому что людям захотелось играть, делать 3D… Вливание огромных денег в R&D… Знаешь, студентом и школьником я покупал эти карты за безумные какие-то деньги, и мои деньги вливались назад в R&D компании-производителя, которые потом позволили разрастись этой индустрии. И сейчас мы имеем графические карты без видеовыхода, которые используются просто для вычисления.
— Ни CUDA у NVidia ни APU у AMD я не могу назвать популярными решениями. Насколько масштабны вообще эти технологии? Или это все-таки удел гиков?
— Естественно, что это удел гиков. Если это было бы массовое решение, то мы бы сейчас не обсуждали их как кризис отсутствия. То есть в GPU разрослось сейчас количество ноутов, но с другой ты можешь купить гигантский трехкилограммовый гроб, в котором будет отдельная видеокарта. И ты можешь купить, что-нибудь полегче, где будут встроенный видеочип от Intel.
— А Intel кстати дают API для вычисления на их встроенном видеочипе?
— Не знаю ни о чем таком. Не уверен, что там работает CUDA. Хотя все же подвижки в индустрии есть. Очень интересные подвижки у Intel — они купили Altera и хотят на серверах забабахать FPGA.
— Там речь шла про то, что у Intel есть история: у тебя есть процессор, у тебя есть юзкейс конкретный: сервер, который выполняет некоторую конкретную работу. И ты понимаешь, что у него есть одно конкретное узкое место. Идея в том, что если каких-то блоков не хватает, если они — узкое место, то давайте мы их на лету сделаем, чтобы это узкое место расширить. Серверный процессор и так стоит тысячи долларов, так давайте еще за сто баксов что-то полезное добавим. Это разумная идея.
— Да, например, индустрия игр влила деньги в GPU, финансовая индустрия влила какие-то деньги в FPGA, а FPGA, как понимаешь, штука, которая дороже в разработке раз в сто. То есть, это очень дорого для создания каких-то решений, но и на это нашелся спрос в высокочастотной торговле. Идея в том, чтобы разобрать поток TСP/IP и чего-то с ним сделать. Например, сделать табличку заказов прямо в железе.
Туда влили деньги, только не консьюмеры, а индустрия. Еще у нас есть индустрия, которая производит видеокарты. И есть финансовые институты, которые хотят срезать сколько-то микросекунд. И они готовы влить любые деньги, потому что это принесет им миллиарды. В этом плане индустрия накачалась, но она не стала мейнстримом. В магазине ты не сможешь купить плату FPGA общего назначения и воткнуть её себе в компьютер, потому что не понятно, что с ней потом делать.
— Я правильно понимаю что мы опять говорим о дорогих решениях, которые позволить себе могут, условно говоря, только банковые структуры или какие-то финансовые структуры?
— По разработке для FPGA — да.
— Ну сама плата может стоить не супер-дорого.
— Сама по себе она будет не дешевая, но это не безумные расходы. Безумные расходы — это суметь заставить это устройство делать то, что тебе нужно. У нас нет аналога обычного магазина для таких решений. Мы говорим: «Потребитель, слушай, есть плата. На ней есть 25 каких-нибудь FPGA. Если ты её себе поставишь, то твои игры будут еще круче». Хороший контрпример — это PhysX. А PhysX — это NVidia, и там есть мини-технология, которая привела к тому, что было время, когда люди ставили в компьютер и AMD-шную карту, которая считалась лучше для игр, и параллельно ставили карту NVidia. Windows поддерживает параллельно девайсы, а NVidia сделала подлянку — ты не можешь использовать PhysX и AMD. Но тут люди взбунтовались, и пришлось все откатить.
— Я помню, это кажется было лет 10 назад.
— Нет, может быть 5-6.
— Думаешь? То есть, это были времена второго Half-Life…
— Нет, ты путаешь, потому что использование нескольких графических карт появилось только в Windows7 или Windows Vista. До этого это вообще было не возможно, а сейчас можешь понатыкать их в комп и будет все прекрасно.
Но в целом, это неразрешимая проблема. Если Xeon Phi взять, то да — офигенная новейшая, но непонятно, что от него выиграет даже не обычный пользователь, а что от него получит IT-шный enterprise?
— Помню, что приглашал тебя лекцию нам читать на эту тему, а я потом темой заинтересовался. У Одноклассников было пару митингов с Intel. В Одноклассниках много всяких разных сервисов и инженеры думали, куда можно Xeon Phi пристроить. Но не нашли такой подсистемы.
— Смотри, с Xeon Phi какая вещь… У тебя есть 60 или 80, в зависимости от модели, медленных ядер, которые имеют аппаратную многопоточность.
— Медленные — это уровня Pentium 4.
— Да. И они имеют 512 битный вектор, который ты, чтобы амортизировать эту карту, должен использовать. На большинстве карт, которые сейчас у людей стоят, вектор — 256 бит. Суть в том, что хотя Xeon Phi позиционируется как «считалка», но сравнения показывают, что все-таки он еще не дотягивает до Tesla. Нюанс в другом: если у тебя есть GPU, то каждое ядро твоего девайса должно делать одну и ту же задачу. У тебя есть хороший массив данных, и каждое ядро должно делать одну и ту же задачу. Если же ядра выполняют разные задачи, то ты теряешь многопоточность.
На Xeon Phi такого нет: там каждое ядро, что хочет, то и делает. И нюанс Xeon Phi в том, что это де-факто x86. Соответственно, ты можешь пересобрать свой плюсовый код под Xeon Phi, запустить его там, и каждое ядро может заниматься чем-то своим. И это уникальная возможность, что меня это удивляет.
Смотри, у нас Intel постоянно говорит, что «у нас 80-ядерный процессор почти готов. Вот мы сейчас вам сделаем хорошо…» Они постоянно несут такую пургу. И ничего не происходит. У нас по-прежнему стандартные процессоры с 4 ядрами. Главное, они хоть что-то делают в контексте одной конкретной коробки, не выходя на уровень кластеров. И Xeon Phi, как мне кажется, — это интересное программно-аппаратное решение для интеграции. Если ты хочешь кому-то поставить сервер непрерывной интеграции или еще какой-нибудь back-end штуку и чтобы performance был нормальный — ты делаешь его на Xeon Phi и все у тебя становится хорошо. Xeon Phi помогает раскидывать задачи на все ядра и делает это одновременно, другое дело, что ядра сами по себе не такие быстрые.
— Вопрос — в стоимости этого решения.
— Да, вопрос в стоимости. Но если смотреть цены на Tesla и Xeon Phi, то они несравнимы.
— То есть соотношение доллар на единицу производительности не одинаковое?
— Конечно, Tesla все еще выигрывает.
— А Xeon Phi — это развивающаяся технология?
— Непонятно, потому что несколько решений Intel выпустили, а потом у них была распродажа. Возможно, на этом все и закончится, мы реально не знаем. Это темная лошадка, потому что Intel — они всегда много обещают. И опять же, с Intel есть огромная проблема, о которой никто не говорит — целое поколение мобильных процессоров фактически пропущено. Если ты сейчас пойдешь на сайт Lenovo и прочтешь, с какими процессорами она продает свои топовые модели, то это те же процессоры, которые были ровно год назад, потому что у Intel было целое мертворожденное поколениe.
— Пятая серия? После четвертой сразу шестая идет.
— Оно, да. Оно где-то появилось в виде двухъядерных решений.
— Там есть пара процессоров буквально.
— Это очень хорошо показывает, что происходит в индустрии. Был провал с течение года, когда кто-то профукал целое поколение процессоров. Ни AMD ничего не сделала, ни индустрия не взбунтовалась. У всех все прекрасно.
— Проблема проста: лет 5 назад была анонсирована стратегия «Тик-Так». И в прошлом году Intel просто перестал в неё успевать, у них цикл разработки потихоньку растет, и они просто не уложились в двухлетний цикл.
— У меня такое впечатление, что Intel уже все равно. Вот они пропустили год — и их никто на рынке не накажет! Они де-факто монополисты. Мне в этот год нужен был комп, и у меня не было выбора — я покупаю Haswell, потому что я заложник этой истории. Я иду в магазин и все.
— А с другой стороны, мы тут сидим, а у меня вон в рюкзаке штука, которая считает миллиардов и десятки миллиардов операций в секунду. Это же фантастика!
— С одной стороны, фантастика, а с другой стороны, нам постоянно хочется больше, больше и больше.
— Может быть, мы просто зажрались? Привыкли к этому? Мы ничего не делаем, а наши программы начинают работать быстрее?
— Этот free lunch давно кончился. Идея того, что не нужно оптимизировать для multicore потому что мы подождем, и выйдут новые процессоры, давно закончилось, и появилась новая эпоха многоядерности.
— Все говорили, что free lunch is over, все это стали понимать довольно давно, в классе серверных решений multicore давно существовал. Вышел в 2004-2005 году первый AMD двухъядерный, тогда они были законодателем моды. Вроде как все начали говорить: «Давайте освоим многопоточность». И такое ощущение, что к сегодняшнему дню более-менее научились.
— Научились. Но мы еще не получаем такого гигантского бенефита, потому что, если стандарт у нас все еще 4 ядра, то лучшее, что мы получим это ускорение в 3-4 раза.
— Я так понимаю, что вся история с энергоэффективностью нужна была, чтобы научиться количество ядер наращивать. Но, похоже, что не выстрелило.
— Прокол заключается в том, что наша экосистема не масштабируемая. Ты можешь воткнуть один процессор, на котором сколько-то ядер в твою плату. Ты не можешь воткнуть еще один процессор в плату, потому что там просто нет места.
— В серверный — можешь.
— Да, в серверный можно воткнуть еще второй процессор, но у нас нет такого линейного масштабирования. Соответственно, если ты хочешь в контексте одной машины наращивать мощность, ты будешь использовать Xeon Phi, потому что это твой единственный шаг — втыкать компьютер в компьютер.
Я бы еще отметил тот факт, что люди более-менее поняли, что нельзя наращивать требования к железу до бесконечности. Посмотри на игры. Было время, когда новая игра требовала новое железо. Сейчас уже не так: сейчас ты можешь играть в последний StarCraft на железе пятилетней давности.
— HD появилось, наконец-то высокое качество.
— Было время, когда новый софт выжирал у тебя по экспоненте ресурсы. Сейчас такого меньше происходит. Сейчас есть решения вроде Visual Studio, которые еще пытаются отжирать гигагерцы и гигабайты. Но Visual Studio тоже успокоилась, она поняла, что нельзя отъедать у людей ресурсы бесконечно. Слава богу, Visual Studio — 32-битный процесс, она лимитирована в этом плане.
— Как ReSharper будет в этой реальности выживать? Ведь клиентские проекты становятся все сложнее, а 32 бита – это, в том числе, ограничение по памяти. Что делать? Out-of-Process?
— Это по сути дела единственный вариант. Ты больше ничего не сможешь сделать.
— А у Microsoft нет в планах переписать студию на 64 бита?
— У них есть Visual Studio Code, типа мы сейчас с чистого листа начнем писать новую IDE и посмотрим, что там будет.
— И она 64 бита сразу?
— Вроде да. Было бы странно, если бы она не была 64 bit, потому что, это был бы выстрел себе в ногу. Проблема заключается в том, что с крупными компаниями типа Microsoft или Intel мы никогда не знаем, какие у них планы, не знаем, куда они хотят двигаться.
Вот есть Visual Studio Code. Хотим ли мы делать ReSharper для него? Непонятно, потому что Visual Studio Code – это отдельная тема, ее стратегия непонятна, и самое главное, ладно бы ее кто-то знал в Microsoft. Но создается ощущение, что даже в Microsoft порой продукты выпускаются инерционно, а не в каком-то понятном ключе.Сейчас вот они решили показать миру, какие они опенсорсные, какие кросплатформенные.
— Я думаю, что это бизнес-решение. Они же видят, что все ушло в Андроид, iOS и они, просто не сделав этого, рынок проиграют.
— Парадокс в том, что эти действия и те анонсы, которые были на недавнем Connect — непонятна сама их стратегия. У них же есть своя мобильная операционная система Windows Phone, у которой микроскопически маленький рынок, и они могли бы продолжать его развивать, но они еще лезут в эту тему с Андроидом и iOS. Но лезут или не лезут пока не понятно: то у них что-то выходит, то все задерживают. Такое ощущение, что у Microsoft нет какой-то направленной стратегии. У них каждый отдел что-то свое пилит, но иногда это вещи, о которых нам извне не дают никакой информации, куда там все идет.
Мы, как их клиенты, не можем адаптироваться в свою очередь. Мы не можем сказать, что мы завтра портируем ReSharper на Visual Studio Сode, потому что мы уверены, что Visual Studio Code будет офигенным решением. Visual Studio Сode могут убить так же, как и Silverlight.
— То есть для вас это огромные риски и вы ничего не можете с этим сделать? Каждый раз это такая игра: инвестировать или не инвестировать?
— Мы зависимы от Microsoft. У нас были такие кейсы, что Microsoft в последние минуты делает что-нибудь такое, что у нас в ReSharper код просто становится красным, и это анонсируется за день до релиза. Мы уже не успеваем вписаться. С этим ничего не сделать, потому что у Microsoft свои цели, которыми они не особо готовы делиться с партнерами.
— Но есть же очевидные сдвиги, например, другая модель анонсов Visual Studio. Если вы раньше работали как партнер, получали приватные билды, то сейчас билды публичные, и вы все как члены коммьюнити можете взять. Значит все-таки есть некое движение навстречу?
— Движение навстречу есть, но непонятна мотивация, непонятно, что на самом деле происходит. Microsoft действительно повернулась лицом к Open Source или их просто рынок силой вынуждает и они понимают, что сдают позиции, поэтому они идут во всех направлениях? Еще вопрос — потянут ли они это?
У нас пока .NET развивается в плане поддержки Mac OS и Linux. Вопрос в том, допилят ли они его? Потому что нет никакой гарантии, что они его дотянут до того состояния, когда можно какой-нибудь back-end перенести на Linux, чтобы он там работал идентично и с тем же перфомансом. Если это возможно, то это прекрасно, но тут у меня вопрос такой: «А где в этом деньги для Microsoft?». Уже нет своего Linux, чтобы на нем гнать .NET. На чем они деньги сделают?
— Cloud, мне кажется. Про это все говорят.
— Сейчас история такая, что ты скачиваешь Visual Studio Code для того, чтобы писать на нем под ASP.NET и в конце тебе захочется все это захостить в Windows Azure. Да, хорошая интересная история. Но я напомню, что сейчас ASP.NET не в первых рядах хотелок у тех, кто пишет Web.
Вопрос в том, что Microsoft мы все равно воспринимаем, как некий бизнес, который делает деньги точно так же, как JetBrains и другие компании. По крайней мере, в контексте JetBrains понятно: «Мы делаем хорошо разработчикам, получаем за это деньги». История на этом закончилась, она очень прямолинейная.
У Microsoft все немного не так, потому что у них все базируется на том, вы, юзеры, хотите операционку, чтобы на этой операционке что-то гнать. Последние телодвижения, в том числе Windows 10, они непонятные. Я на одном из компьютеров проапгрейдился до Windows 10 и я очень недоволен тем, как User Experience деградировал. Ты раньше писал название программы, оно тебе находило, сейчас почему-то не находит.
Это все странные подвижки. Есть впечатление, что Microsoft не монолитен, в отличие от Apple. В Apple еще ощущается единая стратегия, а в Microsoft несколько отделов, которые делают каждый свое. И потом что-то получится, что-то просочится наружу. Платформа .NET и язык C# – это основной успех. C# — это ИМХО лучший язык общего назначения.
Проблема в том, что мы не ощущаем у Microsoft очевидной стратегии. И это пугает, потому что не знаешь, во что тебе вкладываться, а во что не вкладываться.
P.S.: Лично пообщаться с Дмитрием можно будет совсем скоро — на конференции DotNext в Москве. Он почти весь день будет на стенде JetBrains и выступит с двумя докладами: про написание ботов и про ReSharper 10.
Мы больше часа беседовали с Дмитрием, но не успели затронуть даже половины тем, которые хотелось обсудить. Что Дмитрий успел рассказать мне:
- Чем технический евангелист отличается от Developer Advocate
- Как работает евангелизм в JetBrains
- О восприятии мира настоящими гиками
- Почему IT — это бедная индустрия
- Про маржу и инвестиции российских аутсорсеров
- Про то, какие enterprise решения позорят индустрию и почему
- Насколько далека JetBrains от своего простого потребителя
- Об том, как индустрия видеоигр смогла «вырастить» под себя целый сектор железа
- Что сейчас творится на рынке видеокарт
- Что еще могут придумать компании, для того, чтобы программы работали быстрее
- О том, как будет выживать ReSharper и о 64-битных IDE от Microsoft
Вот видео, а под катом, как обычно, текстовая версия этого интервью.
(на одиннадцатой минуте нет звука, к сожалению.)
Technology Evangelist vs. Developer Advocate
— Дима, у меня к тебе такой вопрос – кто такой технический евангелист? Какие у него обязанности? Что он делает?
— Прежде всего, я должен сказать, что мы отказались от термина «технический евангелист». Мы перешли на другой термин — Developer Advocate, потому что евангелизм так или иначе у некоторых людей в голове сильно связан с какими-то религиозными направлениями. И вообще «евангелие» – «как мы несём благую весть» – это слишком претенциозно, я бы сказал. Это типа – вот, мы пришли вас спасать от плохих практик разработки, поэтому – Developer Advocate. То есть, человек, который отстаивает некие принципы хорошей разработки, допустим, через, в том числе, и инструментарий. Поэтому это человек, который занимается тем, что делает доклады на конференциях, работает на стенде на конференциях.
То есть, есть конференция – на ней можно поставить стенд и там сотрудники компаний будут показывать, рассказывать, давать всякие брошюрки и интересные подарки, и просто общаться с пользователями. Потому что одно дело, когда мы общаемся с пользователями через интернет, и другое дело, что иногда хочется вживую получить фидбек. И некоторым людям хочется видеть живых разработчиков JetBrains, чтобы подойти и сказать – «Вот, ребята, смотрите – у меня такая проблема, вы её не решаете – давайте прямо сейчас, здесь, на конференции её обсудим». И это, мне кажется, здорово.
Помимо этого мы делаем некие маркетинговые материалы – в частности, скринкасты, вебинары…
— Блоги.
— Блоги, опять же, да. То есть, с одной стороны мы действительно описываем фичи наших продуктов, но у нас сейчас уклон идёт в то, чтобы делать общие технологические вещи. Если вот посмотреть на мои вебинары – например, последний – там мы не делаем такого, что «Вот, смотрите: вот наш продукт и вот наши фичи, мы сейчас вам по полочкам разложим, что там есть». То есть, такие вещи мы делаем просто скринкастами, а фичи продукта мы показываем в ходе какой-то тематической беседы. Например, давайте обсудим современный С++, какие там языковые фичи — и вот в фоне используется наш редактор, какие-то наши фичи, возможно, но мы как бы даже не упоминаем…
— В общем, понятно, что это некий трюк, эта техника называется product placement и известна ещё со времён первых фильмов о Джеймсе Бонде. То есть, 50 лет.
— Нюанс заключается в том, что пользователи, по сути, не хотят маркетинга. Многие компании не понимают, что если ты делаешь конференцию или event, полностью состоящий из маркетинга, то у людей будет какое-то отвращение. Вот мы так не делаем. Поэтому все доклады, которые я подаю на конференции – они все просто тематические. Есть конференция по С++ – я рассказываю, как делать что-то интересное на С++. А product placement – да, он есть в фоне и он никому не мешает. То есть, если я сделал что-то с, допустим, CLion, но если вы хотите использовать Eclipse, то – вперёд, никаких проблем.
Как работает евангелизм в JetBrains
— Ну понятно. Как по ощущению – евангелизм в JetBrains – он работает или не работает? Он помогает компании или нет?
Дело в том, что мы не единственные, кто занимается евангелизмом. Евангелизмом, например, занимается Microsoft и наши подходы кардинально разные, потому что у Microsoft более формальный подход – то есть, они нанимают стороннюю компанию, которая потом занимается тем, что она обзванивает потенциальных пользователей, неважно студенты это или бизнес, и спрашивает их: «Ребята, мы сделали мероприятие. У вас повысилось желание поставить Windows 10?».
Эти метрики – это KPI и эти метрики, фактически, делают бонусы евангелистам и т.д. Понятное дело, что у Microsoft в России, поскольку, в основном евангелизм, то у них команда больше и всё это систематизировано.
У нас команда человек шесть, по масштабам JetBrains — микроскопическая. И у нас никаких KPI толком нет. То есть, мы сами для себя понимаем, что мы сделали офигенно, а что мы сделали обычно. То есть, если, допустим, человек зарелизил какую-то офигенную вещь, которую весь мир заметил – что-то такое крутое сделал, то мы понимаем, что — вот, смотри, это achievement. Нам не нужно сторонней валидации, потому что продажи продажами – то есть, у нас нет таких метрик, что «Вот, смотрите – мы сделали event и после него продалось столько-то лицензий». Мы в таком ключе не думаем, мы просто делаем всё, что мы можем.
Те же скринкасты нужны, потому что у тебя есть продукт и люди хотят знать, что за фичи в нем есть. Они могут сухо страничку почитать или могут посмотреть видео. То есть, мы знаем, что есть скринкасты, что есть в них потребность, мы можем смотреть статистику просмотров. Но понять что вот эти конкретные скринкасты привели напрямую к продажам — очень трудно. Математически очень сложно показать и мы этим не занимаемся. У нас есть понимание того, что это нужно, поэтому мы это делаем и стараемся делать хорошо. И все.
— То есть, фактически, это на уровне внутреннего ощущения?
— По сути дела, да. То есть, мы сами для себя видим, когда что-то получается хорошо. Когда какая-то вещь, условно говоря, выстреливает. Например, ты делаешь вебинар, и на него записывается столько людей, что тебе приходится делать второй такой же. Вот это хороший критерий. Опять же, да, естественно, что и мы, евангелисты, и менеджеры по маркетингу тех или иных команд – мы всё-таки смотрим на продажи, мы смотрим на скачивание – мы держим руку на пульсе. В том смысле, что если где-то нужно поднажать – то мы, может, поднажмём. Но вот такой прямой привязки к каким-то метрикам, что «Вот, смотри, я напродавал через евангелизм больше, чем ты» — такого нет.
— Это хорошо или плохо?
— Мне кажется, что это хорошо. Потому что через KPI можно делать всякие нехорошие вещи. То есть, ты можешь, например, иметь евангелиста по продукту, который не очень коммерчески успешен и, согласно KPI, ему будут меньше бонусы – потому что продукт меньше успешен, соответственно, и ты меньше получаешь. Вот у нас нет такого и, на самом деле, у нас продукты продаются по-разному – есть очень успешные, есть не такие успешные. И есть, продукты, которые евангелисты покрывают – есть продукты, на которых, к сожалению, евангелистов пока нет. Как я уже сказал, команда очень маленькая, а продуктов много.
— Почему компания не хочет её расширять?
— Дело в том, что поиск евангелистов – это очень тяжёлый процесс. Потому что тебе нужен человек, который: во-первых, технически компетентен – в том, смысле, что у него уже есть опыт разработки и, на самом деле, мы настаиваем, чтобы человек продолжал писать код. Понимаешь, во многих компаниях, не называя имён, евангелисты – это люди, которым дают слайды и они их рассказывают. И всё.
А нам нужно, чтобы человек был и технически подкован – чтобы на любой вопрос ответил (то есть, если ты делаешь, допустим, рассказ про С++, то ты должен знать С++, ты должен на нём писать). И одновременно мы хотим, чтобы у человека были навыки общения, навыки коммуникации, чтобы он был готов летать по миру постоянно. И что-то рассказывать или просто общаться. И это сложно. Это реально сложная задача, потому что таких людей не так много.
— Вот я знаю Баруха Садогурского, и он говорит, что термин «Developer Advocate» вы стырили у них. Он шутил, что ему религия не позволяет называться евангелистом и по этому поводу он Developer Advocate. А сейчас такое название вашей профессии действительно стало трендом. Барух большой молодец. В Java мире он, наверное, такой самый известный Advocate.
— Понимаешь, это в каком-то смысле шоу-бизнес. Естественно, ты возвращаешься домой и пишешь кучу кода, дебажишь и копаешься во всём этом, но когда ты выходишь на публику – да, это шоу-бизнес, насколько хорошо ты можешь донести какую-то тему.
Ещё одна вещь, которую я не упомянул, которую тоже очень важно упомянуть – это походы к клиентам. То есть, мы, помимо поездок на какие-то мероприятия, мы ещё пишем – либо по потенциальным, либо по уже существующим клиентам. Мы говорим: «Ребят, хотите пообщаться? Мы придём, мы вам можем что-то рассказать, мы можем посидеть с блокнотом, записать ваши проблемы, посмотреть, как мы можем их лучше решить».
Вот, например, ты приходишь в какой-нибудь хедж-фонд или инвестбанк – тебе нужен человек, который говорит на их языке. И это тоже проблема. Потому что таких людей не найти. У нас есть сейлзы, понятное дело, но они тебе скажут, сколько это стоит, какие мы можем скидки для вас сделать. А тебе хочется, чтобы кто-то живой, кто «Вот, смотри – у меня тут обсчитывается то-то и не работает то-то» и мы можем прямо смотреть на этот код и что-то с этим делать. То есть, это тоже часть работы.
— Если попытаться по процентам твоего рабочего времени это всё разложить – как у тебя примерно получается? У вас же, наверное, в команде это по-разному, да?
— Слушай, на самом деле, всё очень не однородно в том смысле, что действительно есть мероприятия, на которые мы просто будем ездить каждый год практически, и то иногда мы делаем перерывы. Есть мероприятия, которые год от года поражают воображение. Допустим, ты знаешь, что там будет 20 000 человек на 3 дня и поэтому лучше не пропускать этот ивент. Поэтому в этом есть некая регулярность.
Ещё есть регулярность, конечно, в релизах – то есть, когда происходит какой-то релиз, то ты должен подготовить материалы для этого релиза. Например, скринкасты, которые описывают все фичи, потом покусочно как-то, блок-посты какие-то, но помимо этого есть очень много просто случайных вещей, причём инициатива не наказуема.
Я, например, делаю просто иногда вебинары – мне хочется поговорить про генеративное искусство. То, как программа генерирует – это реально такой маленький бизнес, который мы с моим сыном делаем. Генерировать случайные картинки, потом их в рамочку со стеклом и все дела. Вот, и я про это рассказываю. Делаю вебинар, например. То есть, у нас много таких спонтанных активностей – мне кажется, это тоже хорошо, потому что, с одной стороны, это привлекает людей к JetBrains, с другой стороны, там никакого втирания продукта – вообще ничего не такого.
— Ты понимаешь, что ты… Только не бей меня и не тыкай в меня ножом. Что ты абсолютный гик. То есть, человек, который с сыном занимается компьютерным искусством – его другим словом не назвать.
— Я тебе скажу больше – я обучаю сына программированию на FPGA, поэтому…
— То есть, твой сын тоже гик!
— Не знаю, в таком возрасте ещё рано говорить про гиков.
О восприятии мира настоящими Гиками
— Этот термин вообще сам по себе странный… У тебя есть ощущение, что ты воспринимаешь мир — и индустрию, и профессию, и отрасль — не так, как люди вокруг тебя в том же JetBrains, например?
— Это есть. И это, я бы сказал, было всегда, потому что я, когда только начал работать в IT-индустрии, когда я всё-таки решил не писать диссертацию, а пойти работать – я попал в очень странное место. В место, где, скажем так, мало кого интересовало вот это вот The Art of Programming.
— Это было в Петербурге?
— Да в Питере.
— Я знаю даже, что это за место – мы не будем его называть.
— Не будем. И, соответственно… Я бы не сказал, что я тогда был более гиком – просто я читал все книги, мне хотелось всё знать и, соответственно, я быстро вырос, но у меня быстро создалось впечатление, что просто никого вокруг ничто не интересует как на уровне софта, так и на уровне железа, а меня интересовало всё и сразу. То есть, соответственно, ощущение того, что IT, на самом деле, не такое гиковое, как могло было бы быть – оно до сих пор у меня есть. Потому что у нас есть некие конкретные люди, которые прямо прутся от технологии и им хочется всё знать, в том числе заниматься вещами экзотическими FPGA, XeonPhi, CUDA и т.д. Но большинству людей ничего этого не нужно. Большинству людей нужна просто зарплата в конце месяца. И всё.
— Пусть это нашим слушателям и читателям покажется снобской позицией, но в целом я с тобой соглашусь. У меня есть такое ощущение, что для многих IT — это просто способ существования такой. Это не увлечение и не хобби… Это же очень грустно. Если говорить более глобально – в мире огромное количество людей, которые занимаются тем, чем они не очень хотят на самом деле заниматься. Я вот только не знаю, насколько это именно для IT характерно или это вообще для мира?
— На самом деле, если говорить про своё неудовольствие жизнью, скажем так – я считаю, что IT ещё нормальная индустрия в этом плане. Например, у нас нет сильных физических нагрузок.
Почему IT — это бедная индустрия
— И в нашей индустрии кое-что платят, всё-таки.
— Да, кое-что платят. То есть, если посмотреть на средние заработные платы по миру для программистов – это 80 000 $, то есть, на это как-то можно жить. В России — в два с половиной раза меньше, но всё равно на это можно существовать. Поэтому естественно, что частный самолёт, наверное, нет, но для нормальной машины, квартиры, дачи – этого вполне хватает. Поэтому я никого не виню, я не говорю что плохо, когда люди идут в IT за стабильным доходом.
Другое дело, что в глобальном разрезе IT — это достаточно бедная индустрия. Как-то я был в гостях у подкаста «Разбор полетов» и честно сказал в эфире, что айтишник, то есть программист типичный – это даже не средний класс. Это рабочий класс, это некая функциональная должность, потому что сама индустрия IT по большому счету не является системообразующей. Она обслуживает другие индустрии — ритейл, банки, инвест-компании…
— Любой бизнес.
— Любой бизнес. Она обслуживает бизнес так же, как бизнес обслуживает аудит, как бизнес обслуживает бухгалтерия и все такое.
— То есть типичный кейс – это снизить издержки за счет внедрения некой автоматизации в каком-то бизнесе?
— Да.
— Меня, конечно, зацепил сейчас момент, насчет того, что мы бедная индустрия. Если сейчас какому-нибудь программисту сказать, что ИТ – это бедная индустрия, то, скорее всего, он тебя не поймет. Ты можешь раскрыть немножко эту тему?
— ИТ – бедная индустрия по той причине, например, что большинство разработчиков не могут по-хорошему позволить себе результат своего собственного труда. У нас появляются очень интересные технологии, из тех технологий, которые спасают душу индустрии, например, я бы назвал появление SSD, потому что до SSD работа с диском была просто мучительной операцией если у вас какой-то random access, а не просто линейные операции — все, смерть. Поскольку мы делаем IDE, для нас это больная тема, потому что разработчик без SSD он просто будет страдать.
Соответственно, когда я делаю доклад по эффективной разработке, я рассказываю про то, как внедрять более серьезные, чем SSD, технологии. А потом ко мне подходит директор какой-нибудь аутсорсинговой компании и говорит: «Знаешь, у нас нет денег, на то, чтобы разработчикам поставить SSD».
Cамое главное, что в свое время когда я работал, я ощущал примерно те же проблемы, т.е. ты работаешь разработчиком, а тебе компания не может поставить нормальный комп. Компания ставит комп, где 4 гигабайта оперативки. Или ты приходишь на работу, и тебе дают один экран. Я хочу, например, шесть, ну или хотя бы три. А на меня смотрят как на идиота. А я смотрю на эту вот индустрию, как на идиотскую индустрию в обратную сторону, потому что понимаю, что второй монитор — это не такая дорогая вещь.
— Я в свое время попал на работу в компанию Oracle. Прекрасная компания, но мне тоже дали один 19-дюймовый монитор. Но я просто взял и принес еще один свой, купил.
— Разработчики так и делают.
— Да проблема в том что, мне кажется, я был один такой. Т.е. всех остальных полностью все устраивало.
— Да. Менталитет людей он уже настроен такой, что вот, что нам дядя дал…
— Не, я не один такой был. Был еще один чувак, который был моим ментором, он тоже правильный чувак на самом деле.
— Я видел, как люди заменяли диски на SSD.
— Или памяти доставляли.
– Сейчас, допустим, в JetBrains таких косяков нет, но если ты выйдешь за пределы JetBrains или еще нескольких хороших компаний и пойдешь по аутсорсам… Я бывал в местах достаточно ужасных. Именно не работал, а бывал. Там народ сидит в развалившемся заводе, у них у всех трубчатые мониторы…
— Когда это было?
— Это было году в 2008, может в 2010… Но понимаешь, SSD и мониторы – это верхушка айсберга. Мы говорим про SSD, мы не говорим про PCIe-based SSD-носители, мы не говорим про FusionIO-носители, мы не говорим про всякие экзотические…
— Не, ну PCIe и M2 – уже идут в индустрию.
— Если зайти сейчас в любую компанию и спросить, кто использует М2…
— Да кто хотя бы SSD использует? Я думаю, что уже на этом этапе мы закончим наше «исследование».
— А на самом деле, вещи, которыми я занимаюсь, т.е., например, использование GPU, Xeon Phi, FPGA — это вещи, которые давно существуют, ты можешь пойти на рынок и их купить. Но ИТ-индустрия, она либо делает вид, что они не релевантны, что их вообще не нужно рассматривать, либо она говорит, что это дорого. Она просто говорит, ну вот смотри, разработчику платим две тысячи долларов в месяц. А ты предлагаешь за две тысячи или за пять тысяч долларов купить какой-то девайс, который, типа, ускорит нам жизнь, но мы не очень понимаем, как он нам позволит больше зарабатывать.
Про маржу и инвестиции аутсорсеров
— Наверное, я совершенно не понимаю индустрию. Типичная маржа для российских аутсорсеров — это 30%. И это очень высококонкурентный бизнес. И правда в том, что если ты начнешь инвестировать в мониторы и SSD, то у тебя маржа упадет и ты проиграешь конкуренцию.
— Мне тоже кажется, что это просто плохой бизнес. Тут нужно подчеркнуть такую вещь, что по идее, аутсорсу важна стоимость инженерного часа. И если у них появилось оборудование, которое уменьшает количество этих инженерных часов, то непонятно, что это им дает. Да, они зарелизят быстрее, продукт возможно. Но они получат меньше денег.
— Они быстрее сделают это продукт и, значит, им надо будет искать нового клиента.
— Это один пример. Другой пример: есть компания-монополист. Ей плевать, разработка идет два года или двадцать лет. Потому что ее устройства все равно будут покупать. Соответственно, как ты думаешь, какой у нее стимул делать что-то постоянно?
— Никакого.
— Ноль, абсолютно. Поэтому у меня такие претензии к IT. Потому что IT — это индустрия, которая лукавит. Она говорит, что «вот смотрите, мы все улучшаем»
.
— «Новейшая нанотехнология.»
— Да, но с другой стороны тебе может начальник сказать: «слушай, вот конечно ты мне крутую штуку показал, но, блин, давай как-нибудь вы пока без нее». И это не какие-то выдуманные истории, это реальные истории. Компании, например, качественную IDE просто не хотят покупать, потому что им дорого. Хотя на самом деле, если посмотреть на ценник в разрезе тех же зарплат…
Но ты правильно сказал про маржу, маржа 30% — это, знаешь ли, хорошая маржа. Это скорее маржа аутсорсера, который работает «в черную», ему платят долларовым налом… Более реалистичная маржа для какого-нибудь крупного «белого» аутсорсера — 10-15%. И тогда инвестиции в IDE будут выедать из маржи…
— Мне кажется в России это бы никогда не работало. Потому что если тебе скажут, мол, чувак, ты бизнес сейчас будешь делать с маржой 10% — он скажет «да иди ты нафиг!». У нас инфляция выше…
— Возможно, в крупном, массовом аутсорсе 20% — это приемлемая сумма. Т.е да конечно люди хотят себе большую прибыль и сразу и это понятно.
— Я просто вообще не понимаю, может ты мне объяснишь… Мне кажется, что бизнес этот — очень сложный. Я имею в виду аутсорс, или то, что сейчас называется Service Company. Например, есть, крупная компания Luxoft. Они довольно прикольные, они научились довольно интересные вещи эффективно делать. Agile-процессы давно у них выстроены просто лучше всех…
— Иначе у них никто не закажет.
— Да. В этом смысле они дико крутые и в этом месте они являются двигателем индустрии. У меня ощущение что движение возникает тогда, когда есть некие ограничения, которые на тебя накладываются. В этом случае рынок труда, рынок заказов и все, что угодно – все начинает развиваться. Но, к сожалению, у них развивается история, связанная с процессами с эффективностью коммуникации только за счет давления рынка, а при этом технологическая составляющая просто просаживается.
— И в этом гигантская проблема, потому что люди видят, что их доход зависит от других вещей, и это парадоксально. И очень грустно. Мы действительно находимся в такой ситуации, когда самые новейшие технологии нужны лишь для рыночной эффективности, только для процента, который там их для чего-то действительно использует. Т.е закупит какой-нибудь Fusion IO, и все свои сервера выкинет, оставив всего десяток. А остальным все это не актуально. Это на самом деле грустно.
Но, с другой стороны, это рынок и против него не попрешь. Понимаешь, у нас есть такая идеология, что программисты любят разработку не из-за денег, а из-за того, что девелопмент — это, типа, офигенно интересно. Действительно, технологии, которые я упоминал — очень интересны. И сами по себе они — это прогресс. Но, если люди с ними не работают, то… как вы стимулируете разработчиков? То есть, им же должно быть интересно, они должны куда-то двигаться. Но к сожалению, вот именно в аппаратной сфере и сфере эффективного использования технологий есть большие проблемы.
Про то, какие enterprise решения позорят индустрию и почему
— Знаешь еще, когда ты говоришь о том, чего мы не можем себе позволить, мне на ум приходят в первую очередь разные дорогие Enterprise-решения.
— Дорогие Enterprise-решения — это позор нашей индустрии. Потому что если ты посмотришь на решение командной разработки от IBM, то они бессмысленны и беспощадны. Они тебе будут стоить тысячу долларов на разработчика в год. Это одновременно и дорого и плохо.
С другой стороны, крупный Enterprise другому крупному Enterpris-у продаст такое решение вместо того, чтобы иметь что-то маленькое, легковесное и качественное. Поэтому я толком никогда не был фанатом крупного Enterprise. Но не надо смешивать Enterprise с какими-то аппаратными технологиями, с действительно прогрессивными вещами. Потому что помимо того, что индустрия делает интересные вещи для разработки, у нас есть параллельный мир, в котором люди плевать на это хотят при этом все равно продают свои процессы разработки и сопутствующие технологии. И кто-то это покупает. И это не просто иллюзия, а действительно вполне себе рынок.
Другое дело, что мы, как люди, которые заботятся об эффективности и о том, чтобы действительно что-то сделать— мы этим, толком, не занимаемся и даже порой не видим. Компания в которой я начинал работать она использовала Rational ClearCase, она использовала Rational ClearQuest, которые сейчас IBM-овскими стали. И это тихий ужас. Качество этого софта было ниже плинтуса. Оно настолько плохое, что непонятно, кто и как его писал. Продается оно за бешеные деньги, но очень плохо работает. Возникает вопрос: «а как такое вообще возможно? Кто это допустил? Как вообще это попало на рынок и как это кому-то продалось?».
— Это некомпетенция? Это какой-то коррупционный сговор?
— Ну, что-то вроде. Но по ощущениям, это действительно что-то вроде сговора, не знаю, коррупционного или нет… Может это просто блестящий маркетинг, потому что у нас даже если шагнуть за пределы IT, у нас есть прекрасные примеры абсолютно отвратительных товаров, которые выезжают на прекрасном маркетинге.
Вот если взять например наушники Beats, которые сейчас Apple купил, — это наушники с ужасным качеством. Но они вливают столько в маркетинг, и ты знаешь, что все спортивные и голливудские звезды в этих наушниках. И этот плохой товар, благодаря маркетингу, продается!
Насколько далека JetBrains от своего простого потребителя
— Ты затронул тему качественных и некачественных инструментов. Попробую такой простой, но не очевидный заход сделать. Ты говоришь о том, что мы, айтишные компании, не можем себе позволить нормальные айтишные решения. Ты пытался что-то сделать с этим в JetBrains? Ты пытался эту мысль до кого-то донести или нет? И, если пытался, то в каком ключе? Вопрос такой: можно ли как-то трансформировать существующую вашу линейку продуктов, с учетом вещей, о которых говоришь ты?
— Я бы сказал, что нужно разделять эти вещи. Мы сейчас говорим об инструментах разработки и о том, как мы готовы ускорить процесс или сделать более глубокий анализ. Что мы можем сделать? У нас естественное ограничение — это железо, которое стоит у тех, кто пользуется нашими решениями. Поэтому влиять нужно на них, а не на нас.
— Вот смотри, вот вы сидите в JetBrains, у вас по два монитора, у вас хорошие «жирные» компьютеры. А теперь представь себе человека, который сидит за слабеньким железом с одним 19-дюймовым монитором и пытается в ReSharper что-то сделать. У него «отжирается» вся память и тормозит все, что можно. У вас есть хоть что-то для него? Вы понимаете этого вашего конечного пользователя? Ведь он бесконечно далек от вас!
— Идет постоянный процесс по оптимизации. Оптимизации использования памяти, оптимизация производительности. Помимо ReSharper, у нас есть свои инструменты для профилирования. Мы пытаемся сделать все возможное. Естественно, это борьба с рантаймом, борьба с GC, и тут непонятно, что делать.
Вопрос, который ты задал, он более глобальный, в том смысле, что если бы задать вопрос так: «Почему вы не поддерживаете GPU?» Это хороший вопрос, потому что, по идее, если мы посмотрим на срез софта, который есть вообще в мире, очень мало софта поддерживает GPU. Есть Adobe и есть какие-то решения, которые используют CUDА. И тут можно было бы что-то сделать, но, опять-же, это очень нестабильный подход.
x86 — он везде. Вот ты написал свою Java- или .NET-программу… Под x86 у тебя не будет никакой векторизации, вот всего этого продвинутого…
— Это не совсем так. Скажем, в Java точно в простых случаях это все есть. Какое-нибудь сложение целых чисел в цикле — JIT-компилятор шикарно с этим справляется.
— Это только в простых случаях. Говоря глобально, этот вопрос — как эффективно амортизировать по максимуму железо — он очень актуален. Например, у меня ноутбук, там дискретная отдельная большущая графическая карта, с которой я, в основном, ничего не делаю. Я бы с удовольствием дал ей возможность сделать что-то полезное
Отчасти, это все происходит по тем же причинам, по которым, очень тяжело, допустим, SIMD поддерживать. Потому что SIMD, то есть, большие регистры на CPU, и возможность работать с ними — они эволюционируют во времени. В старых процессорах они такие, потом они становятся больше, больше и ты не знаешь под какой стандарт писать, потому что это все не проходит. Это compatible в том смысле, что если ты скомпилировал программу под AVX, а на компьютере нет AVX – программа просто падает, потому что ты пытаешься выполнить инструкцию, которой на твоем процессоре нет.
— На самом деле, это решается в Runtime. Современный Runtime просто спрашивает процессор, мол, чувак, у тебя есть AVX или нету? JIT-компилятор этим и хорош, что он сам спросит у Runtime: «у тебя есть или у тебя нет?» и в зависимости от этого примет то или иное решение оптимизации.
— Да, компилятор за тебя может сделать какие-то выводы насчет векторизации только если он может посмотреть на свой цикл и однозначно понять, что там никаких зацепок по данным нет. А если он не может этого понять, у тебя все будет идти через обычные регистры, и все.
— Как вообще в .NET обстоит дело с векторизацией?
— Ее нет. Ее сейчас делают для нового RuyJIT. Получилось довольно интересно, потому что Mono, линуксовая реализация .NET, давно уже сделали Mono.Simd — это такой Explicit API для векторизации. Конечно, это не JIT, который тебе все автоматически векторизует. Это именно Explicit штука, все нужно делать руками— оперировать векторами напрямую. Естественно, есть понимание того, что это, в принципе, надо.
— Иными словами, в Mono есть API, который заставляет Mono Runtime делать векторные операции?
— Да.
— Но это извращение, это явно не то, что нужно.
— А непонятно: мы далеко не всегда знаем, что на самом деле нужно…
— Почему я, как разработчик, должен это руками делать? Логичным будет разделить здесь ответственность. Для того, чтобы мне понять, что какое-то место в моем коде тормозит, мне надо профилировать, понять, что именно там можно развязать, и переписать это с помощью API, о котором говоришь… Но это дополнительные и трудные довольно шаги.
— Я, честно скажу, не сторонник автовекторизации и вообще автоматических решений, потому что они работают только на тривиальных примерах. То есть, если ты параллелишь цикл, то он прекрасно распараллелится — твой плюсовый компилятор просто перепишет на OpenMP, и все будет прекрасно. А вот если у тебя что-то посложнее, допустим, параллельная обработка не массива, а дерева — тут все, труба. Весь твой подход развалился.
— Нужно заменить одну конструкцию на другую, семантически эквивалентную, которая обладает лучшей производительностью.
— Я тебе приведу такой пример. Ну, вот есть у нас SIMD, мы можем два массива из четырех чисел быстренько сложить, в регистрах получить результат. Представь, что я хочу использовать SIMD для поиска подстроки. У меня есть гигантский массив именно букв, а буква, допустим утрированно, это два байта. Автоматическая векторизация тут неприменима в принципе, потому что мне нужно брать массив одного типа, но рассматривать его как массив другого типа и использовать SIMD не просто для конструкций типа add, а использовать более сложные механизмы сравнения для того, чтобы сравнивать по четыре или по восемь символов сразу.
— Очевидное решение, как мне кажется, это просто считать за букву сочетание некоторое. То есть это автоматически одну задачу сводит к другой. Это, вроде, несложно делается.
— Но ты это будешь делать руками, это не будет автоматически сделано. И это уже решения неочевидные. На самом деле, вот одна вещь, которая мне нравится, —суперкомпиляция. Это механизм, который пытается выводить идеальный набор инструкций для определенного input и output. И это очень интересно. Берешь какую-нибудь задачу, которую я описал, скармливаешь ее суперкомпилятору, он тебе может выдать на выходе непредсказуемую, неожиданную вещь, но внезапно она работает очень эффективно…
Знаешь, вот я описал только что задачу, а там он может каких-нибудь хитрых сдвигов наделать, причем и в x86 и, в том числе, во всяких там SSE и AVX-инструкциях. Там есть инструкции, которые очень сложные, какой-нибудь хитрый сдвиг…
— Я такое видел в элементарных вещах, например, в простом сложении.
— На интеллектуальном уровне сложно понять, а зачем эта инструкция вообще была сделана. Если ты, какой-нибудь такой подход используешь, — ты получаешь гигантский выигрыш. Но тут уже мы немножко отъезжаем от темы человеческого, потому что это уже более эмпирическое решение.
— Такого довольно много во всяких компиляторах современных, потому что отсюда эта история и берется: если человек или компьютер каким-то хитрым путем понял, что некая хитрая конструкция работает быстрее, чем наивная – то давайте это просто применим и будем этим пользоваться.
—Компилятор хорош, когда он может однозначно понять, что происходит. И если ты просто суммируешь циклы, то ты можешь с тем же успехом брать и делать все это на том же GPU, потому что это задачи, которые очевидно параллельны. А когда много задач, то не настолько все очевидно, система сама не поймет. Но возвращаясь к разработке, я бы сказал, что очень сложно все это как-то применять. Понимаешь, вот разбор исходного кода – это просто большое количество объектно-ориентированных структур. Они не имеют какой-то однородной формы, их нельзя просто взять, скормить на GPU. К тому же, напомню, что GPU не может просто брать текст из X86 и исполнять, оно может некое подмножество математики делать на каком-то там массиве данных. Соответственно, это подход сложный.
Другое дело, что есть много мест, где было бы неплохо получать GPU-ускорение при кодировании видео. Хотелось бы, чтобы везде все было GPU-accelerated, и последняя версия Adobe Media Encoder, часть Creative Suite, которая кодирует видео, она честно пишет, что она использует GPU и там какие-то подвижки заметны. Приятно, что хоть кто-то использует.
— Сжатие. Всем нужно ZIP.
— Да, но ситуация, на самом деле с использованием GPU достаточно плачевная все-таки. У нас просто, может, навыков нет, может, нет желания, в это влезать. У нас, как у индустрии в целом.
О том, как индустрия видеоигр смогла «вырастить» под себя целый сектор железа
— А ты не думал о том, что это некие ограничения, которые просто legacy? У нас есть перед носом поразительный пример, когда целая индустрия спровоцировала рост целого сектора железного. Я говорю про игры и видеокарты. Это вообще уникальный случай, когда клиентский спрос так потрясающе двигал технологию.
— А ты заметил, что в свое время было ощущение того, что со звуком будет то же самое? Потому что тоже появлялись дискретные звуковые карты…
— Причем они все говорили, что вот, на дефолтной звук-то поганый, а вот на нашей карте звук правильный.
— Ты шел в магазин и покупал не просто звуковую карту, ты покупал звуковую карту плюс отдельный внешний усилитель, который с этой звуковой карты получал цифровые сигналы и потом на 5+1 все это раскидывал…
— И стоило это все долларов 300 минимум.
— Все это недешево, да. И было ощущение того, что это будет отдельное развитие. Но нюанс заключается в том, что люди поняли, что есть некая точка насыщения. MP3 с битрейтом 128 – это точка насыщения для большинства людей.
Соответственно вот тот пример, который я тебе привел с Доктором Дре и Beats — это хороший пример, который показывает, что возможно, людям-то и не нужно приличное качество музыки. У нас осталось ниша Hi-Fi, или Head-Fi ниша. Но она очень специфична, потому что там люди тратят гигантские суммы на усилители, наушники и так далее. Но большинство людей, если и различают как-то качество звука, им просто не нужен вот этот interference, у нас, например, есть BOSE.
Кстати, это очень хороший пример. BOSE – это компания, которая тоже делает сомнительное по качеству аудио. Но они, например, делают лучше в мире наушники с активным шумоподавлением, т.е. батарейка берет шум самолета и в противофазе его тебе в уши посылает, и это шикарная вещь. Несмотря на то, что качество звука у тебя теряется, зато у тебя идет изоляция от шума. И это прекрасно. В конечном счете вся эта дискуссия сводится к тому, что мы заложники рынка, рынок себя ведет вот так, а мы за ним идем.
Да, видеокарты — это уникальное решение, потому что людям захотелось играть, делать 3D… Вливание огромных денег в R&D… Знаешь, студентом и школьником я покупал эти карты за безумные какие-то деньги, и мои деньги вливались назад в R&D компании-производителя, которые потом позволили разрастись этой индустрии. И сейчас мы имеем графические карты без видеовыхода, которые используются просто для вычисления.
Что сейчас творится на рынке видеокарт
— Ни CUDA у NVidia ни APU у AMD я не могу назвать популярными решениями. Насколько масштабны вообще эти технологии? Или это все-таки удел гиков?
— Естественно, что это удел гиков. Если это было бы массовое решение, то мы бы сейчас не обсуждали их как кризис отсутствия. То есть в GPU разрослось сейчас количество ноутов, но с другой ты можешь купить гигантский трехкилограммовый гроб, в котором будет отдельная видеокарта. И ты можешь купить, что-нибудь полегче, где будут встроенный видеочип от Intel.
— А Intel кстати дают API для вычисления на их встроенном видеочипе?
— Не знаю ни о чем таком. Не уверен, что там работает CUDA. Хотя все же подвижки в индустрии есть. Очень интересные подвижки у Intel — они купили Altera и хотят на серверах забабахать FPGA.
— Там речь шла про то, что у Intel есть история: у тебя есть процессор, у тебя есть юзкейс конкретный: сервер, который выполняет некоторую конкретную работу. И ты понимаешь, что у него есть одно конкретное узкое место. Идея в том, что если каких-то блоков не хватает, если они — узкое место, то давайте мы их на лету сделаем, чтобы это узкое место расширить. Серверный процессор и так стоит тысячи долларов, так давайте еще за сто баксов что-то полезное добавим. Это разумная идея.
— Да, например, индустрия игр влила деньги в GPU, финансовая индустрия влила какие-то деньги в FPGA, а FPGA, как понимаешь, штука, которая дороже в разработке раз в сто. То есть, это очень дорого для создания каких-то решений, но и на это нашелся спрос в высокочастотной торговле. Идея в том, чтобы разобрать поток TСP/IP и чего-то с ним сделать. Например, сделать табличку заказов прямо в железе.
Туда влили деньги, только не консьюмеры, а индустрия. Еще у нас есть индустрия, которая производит видеокарты. И есть финансовые институты, которые хотят срезать сколько-то микросекунд. И они готовы влить любые деньги, потому что это принесет им миллиарды. В этом плане индустрия накачалась, но она не стала мейнстримом. В магазине ты не сможешь купить плату FPGA общего назначения и воткнуть её себе в компьютер, потому что не понятно, что с ней потом делать.
— Я правильно понимаю что мы опять говорим о дорогих решениях, которые позволить себе могут, условно говоря, только банковые структуры или какие-то финансовые структуры?
— По разработке для FPGA — да.
— Ну сама плата может стоить не супер-дорого.
— Сама по себе она будет не дешевая, но это не безумные расходы. Безумные расходы — это суметь заставить это устройство делать то, что тебе нужно. У нас нет аналога обычного магазина для таких решений. Мы говорим: «Потребитель, слушай, есть плата. На ней есть 25 каких-нибудь FPGA. Если ты её себе поставишь, то твои игры будут еще круче». Хороший контрпример — это PhysX. А PhysX — это NVidia, и там есть мини-технология, которая привела к тому, что было время, когда люди ставили в компьютер и AMD-шную карту, которая считалась лучше для игр, и параллельно ставили карту NVidia. Windows поддерживает параллельно девайсы, а NVidia сделала подлянку — ты не можешь использовать PhysX и AMD. Но тут люди взбунтовались, и пришлось все откатить.
— Я помню, это кажется было лет 10 назад.
— Нет, может быть 5-6.
— Думаешь? То есть, это были времена второго Half-Life…
— Нет, ты путаешь, потому что использование нескольких графических карт появилось только в Windows7 или Windows Vista. До этого это вообще было не возможно, а сейчас можешь понатыкать их в комп и будет все прекрасно.
Но в целом, это неразрешимая проблема. Если Xeon Phi взять, то да — офигенная новейшая, но непонятно, что от него выиграет даже не обычный пользователь, а что от него получит IT-шный enterprise?
— Помню, что приглашал тебя лекцию нам читать на эту тему, а я потом темой заинтересовался. У Одноклассников было пару митингов с Intel. В Одноклассниках много всяких разных сервисов и инженеры думали, куда можно Xeon Phi пристроить. Но не нашли такой подсистемы.
— Смотри, с Xeon Phi какая вещь… У тебя есть 60 или 80, в зависимости от модели, медленных ядер, которые имеют аппаратную многопоточность.
— Медленные — это уровня Pentium 4.
— Да. И они имеют 512 битный вектор, который ты, чтобы амортизировать эту карту, должен использовать. На большинстве карт, которые сейчас у людей стоят, вектор — 256 бит. Суть в том, что хотя Xeon Phi позиционируется как «считалка», но сравнения показывают, что все-таки он еще не дотягивает до Tesla. Нюанс в другом: если у тебя есть GPU, то каждое ядро твоего девайса должно делать одну и ту же задачу. У тебя есть хороший массив данных, и каждое ядро должно делать одну и ту же задачу. Если же ядра выполняют разные задачи, то ты теряешь многопоточность.
На Xeon Phi такого нет: там каждое ядро, что хочет, то и делает. И нюанс Xeon Phi в том, что это де-факто x86. Соответственно, ты можешь пересобрать свой плюсовый код под Xeon Phi, запустить его там, и каждое ядро может заниматься чем-то своим. И это уникальная возможность, что меня это удивляет.
Смотри, у нас Intel постоянно говорит, что «у нас 80-ядерный процессор почти готов. Вот мы сейчас вам сделаем хорошо…» Они постоянно несут такую пургу. И ничего не происходит. У нас по-прежнему стандартные процессоры с 4 ядрами. Главное, они хоть что-то делают в контексте одной конкретной коробки, не выходя на уровень кластеров. И Xeon Phi, как мне кажется, — это интересное программно-аппаратное решение для интеграции. Если ты хочешь кому-то поставить сервер непрерывной интеграции или еще какой-нибудь back-end штуку и чтобы performance был нормальный — ты делаешь его на Xeon Phi и все у тебя становится хорошо. Xeon Phi помогает раскидывать задачи на все ядра и делает это одновременно, другое дело, что ядра сами по себе не такие быстрые.
— Вопрос — в стоимости этого решения.
— Да, вопрос в стоимости. Но если смотреть цены на Tesla и Xeon Phi, то они несравнимы.
— То есть соотношение доллар на единицу производительности не одинаковое?
— Конечно, Tesla все еще выигрывает.
— А Xeon Phi — это развивающаяся технология?
— Непонятно, потому что несколько решений Intel выпустили, а потом у них была распродажа. Возможно, на этом все и закончится, мы реально не знаем. Это темная лошадка, потому что Intel — они всегда много обещают. И опять же, с Intel есть огромная проблема, о которой никто не говорит — целое поколение мобильных процессоров фактически пропущено. Если ты сейчас пойдешь на сайт Lenovo и прочтешь, с какими процессорами она продает свои топовые модели, то это те же процессоры, которые были ровно год назад, потому что у Intel было целое мертворожденное поколениe.
— Пятая серия? После четвертой сразу шестая идет.
— Оно, да. Оно где-то появилось в виде двухъядерных решений.
— Там есть пара процессоров буквально.
— Это очень хорошо показывает, что происходит в индустрии. Был провал с течение года, когда кто-то профукал целое поколение процессоров. Ни AMD ничего не сделала, ни индустрия не взбунтовалась. У всех все прекрасно.
— Проблема проста: лет 5 назад была анонсирована стратегия «Тик-Так». И в прошлом году Intel просто перестал в неё успевать, у них цикл разработки потихоньку растет, и они просто не уложились в двухлетний цикл.
— У меня такое впечатление, что Intel уже все равно. Вот они пропустили год — и их никто на рынке не накажет! Они де-факто монополисты. Мне в этот год нужен был комп, и у меня не было выбора — я покупаю Haswell, потому что я заложник этой истории. Я иду в магазин и все.
— А с другой стороны, мы тут сидим, а у меня вон в рюкзаке штука, которая считает миллиардов и десятки миллиардов операций в секунду. Это же фантастика!
— С одной стороны, фантастика, а с другой стороны, нам постоянно хочется больше, больше и больше.
Что еще могут придумать компании, для того, чтобы программы работали быстрее
— Может быть, мы просто зажрались? Привыкли к этому? Мы ничего не делаем, а наши программы начинают работать быстрее?
— Этот free lunch давно кончился. Идея того, что не нужно оптимизировать для multicore потому что мы подождем, и выйдут новые процессоры, давно закончилось, и появилась новая эпоха многоядерности.
— Все говорили, что free lunch is over, все это стали понимать довольно давно, в классе серверных решений multicore давно существовал. Вышел в 2004-2005 году первый AMD двухъядерный, тогда они были законодателем моды. Вроде как все начали говорить: «Давайте освоим многопоточность». И такое ощущение, что к сегодняшнему дню более-менее научились.
— Научились. Но мы еще не получаем такого гигантского бенефита, потому что, если стандарт у нас все еще 4 ядра, то лучшее, что мы получим это ускорение в 3-4 раза.
— Я так понимаю, что вся история с энергоэффективностью нужна была, чтобы научиться количество ядер наращивать. Но, похоже, что не выстрелило.
— Прокол заключается в том, что наша экосистема не масштабируемая. Ты можешь воткнуть один процессор, на котором сколько-то ядер в твою плату. Ты не можешь воткнуть еще один процессор в плату, потому что там просто нет места.
— В серверный — можешь.
— Да, в серверный можно воткнуть еще второй процессор, но у нас нет такого линейного масштабирования. Соответственно, если ты хочешь в контексте одной машины наращивать мощность, ты будешь использовать Xeon Phi, потому что это твой единственный шаг — втыкать компьютер в компьютер.
Я бы еще отметил тот факт, что люди более-менее поняли, что нельзя наращивать требования к железу до бесконечности. Посмотри на игры. Было время, когда новая игра требовала новое железо. Сейчас уже не так: сейчас ты можешь играть в последний StarCraft на железе пятилетней давности.
— HD появилось, наконец-то высокое качество.
— Было время, когда новый софт выжирал у тебя по экспоненте ресурсы. Сейчас такого меньше происходит. Сейчас есть решения вроде Visual Studio, которые еще пытаются отжирать гигагерцы и гигабайты. Но Visual Studio тоже успокоилась, она поняла, что нельзя отъедать у людей ресурсы бесконечно. Слава богу, Visual Studio — 32-битный процесс, она лимитирована в этом плане.
О том, как будет выживать ReSharper и о Visual Studio 64 bit
— Как ReSharper будет в этой реальности выживать? Ведь клиентские проекты становятся все сложнее, а 32 бита – это, в том числе, ограничение по памяти. Что делать? Out-of-Process?
— Это по сути дела единственный вариант. Ты больше ничего не сможешь сделать.
— А у Microsoft нет в планах переписать студию на 64 бита?
— У них есть Visual Studio Code, типа мы сейчас с чистого листа начнем писать новую IDE и посмотрим, что там будет.
— И она 64 бита сразу?
— Вроде да. Было бы странно, если бы она не была 64 bit, потому что, это был бы выстрел себе в ногу. Проблема заключается в том, что с крупными компаниями типа Microsoft или Intel мы никогда не знаем, какие у них планы, не знаем, куда они хотят двигаться.
Вот есть Visual Studio Code. Хотим ли мы делать ReSharper для него? Непонятно, потому что Visual Studio Code – это отдельная тема, ее стратегия непонятна, и самое главное, ладно бы ее кто-то знал в Microsoft. Но создается ощущение, что даже в Microsoft порой продукты выпускаются инерционно, а не в каком-то понятном ключе.Сейчас вот они решили показать миру, какие они опенсорсные, какие кросплатформенные.
— Я думаю, что это бизнес-решение. Они же видят, что все ушло в Андроид, iOS и они, просто не сделав этого, рынок проиграют.
— Парадокс в том, что эти действия и те анонсы, которые были на недавнем Connect — непонятна сама их стратегия. У них же есть своя мобильная операционная система Windows Phone, у которой микроскопически маленький рынок, и они могли бы продолжать его развивать, но они еще лезут в эту тему с Андроидом и iOS. Но лезут или не лезут пока не понятно: то у них что-то выходит, то все задерживают. Такое ощущение, что у Microsoft нет какой-то направленной стратегии. У них каждый отдел что-то свое пилит, но иногда это вещи, о которых нам извне не дают никакой информации, куда там все идет.
Мы, как их клиенты, не можем адаптироваться в свою очередь. Мы не можем сказать, что мы завтра портируем ReSharper на Visual Studio Сode, потому что мы уверены, что Visual Studio Code будет офигенным решением. Visual Studio Сode могут убить так же, как и Silverlight.
— То есть для вас это огромные риски и вы ничего не можете с этим сделать? Каждый раз это такая игра: инвестировать или не инвестировать?
— Мы зависимы от Microsoft. У нас были такие кейсы, что Microsoft в последние минуты делает что-нибудь такое, что у нас в ReSharper код просто становится красным, и это анонсируется за день до релиза. Мы уже не успеваем вписаться. С этим ничего не сделать, потому что у Microsoft свои цели, которыми они не особо готовы делиться с партнерами.
— Но есть же очевидные сдвиги, например, другая модель анонсов Visual Studio. Если вы раньше работали как партнер, получали приватные билды, то сейчас билды публичные, и вы все как члены коммьюнити можете взять. Значит все-таки есть некое движение навстречу?
— Движение навстречу есть, но непонятна мотивация, непонятно, что на самом деле происходит. Microsoft действительно повернулась лицом к Open Source или их просто рынок силой вынуждает и они понимают, что сдают позиции, поэтому они идут во всех направлениях? Еще вопрос — потянут ли они это?
У нас пока .NET развивается в плане поддержки Mac OS и Linux. Вопрос в том, допилят ли они его? Потому что нет никакой гарантии, что они его дотянут до того состояния, когда можно какой-нибудь back-end перенести на Linux, чтобы он там работал идентично и с тем же перфомансом. Если это возможно, то это прекрасно, но тут у меня вопрос такой: «А где в этом деньги для Microsoft?». Уже нет своего Linux, чтобы на нем гнать .NET. На чем они деньги сделают?
— Cloud, мне кажется. Про это все говорят.
— Сейчас история такая, что ты скачиваешь Visual Studio Code для того, чтобы писать на нем под ASP.NET и в конце тебе захочется все это захостить в Windows Azure. Да, хорошая интересная история. Но я напомню, что сейчас ASP.NET не в первых рядах хотелок у тех, кто пишет Web.
Вопрос в том, что Microsoft мы все равно воспринимаем, как некий бизнес, который делает деньги точно так же, как JetBrains и другие компании. По крайней мере, в контексте JetBrains понятно: «Мы делаем хорошо разработчикам, получаем за это деньги». История на этом закончилась, она очень прямолинейная.
У Microsoft все немного не так, потому что у них все базируется на том, вы, юзеры, хотите операционку, чтобы на этой операционке что-то гнать. Последние телодвижения, в том числе Windows 10, они непонятные. Я на одном из компьютеров проапгрейдился до Windows 10 и я очень недоволен тем, как User Experience деградировал. Ты раньше писал название программы, оно тебе находило, сейчас почему-то не находит.
Это все странные подвижки. Есть впечатление, что Microsoft не монолитен, в отличие от Apple. В Apple еще ощущается единая стратегия, а в Microsoft несколько отделов, которые делают каждый свое. И потом что-то получится, что-то просочится наружу. Платформа .NET и язык C# – это основной успех. C# — это ИМХО лучший язык общего назначения.
Проблема в том, что мы не ощущаем у Microsoft очевидной стратегии. И это пугает, потому что не знаешь, во что тебе вкладываться, а во что не вкладываться.
P.S.: Лично пообщаться с Дмитрием можно будет совсем скоро — на конференции DotNext в Москве. Он почти весь день будет на стенде JetBrains и выступит с двумя докладами: про написание ботов и про ReSharper 10.
