«IT — це досить бідна індустрія» — інтерв'ю з Дмитром Нестеруком з JetBrains

Всім привіт. Це знову «Без слайдів», і сьогодні у мене для вас інтерв'ю з Дмитром Нестеруком, технічним євангелістом компанії JetBrains. Дмитра я знаю досить давно і, не приховую, сам дуже довго чекав моменту, коли ми нарешті поїдемо на студію і запишемося. Аж надто багато запитань у мене до нього накопичилося.



Ми більше години розмовляли з Дмитром, але не встигли торкнутися навіть половини тим, які хотілося б обговорити. Що Дмитро встиг розповісти мені:
  • технічний євангеліст відрізняється від Developer Advocate
  • Як працює євангелізм у JetBrains
  • Про сприйнятті світу справжніми гиками
  • Чому IT — це бідна індустрія
  • Про маржу і інвестиції російських аутсорсерів
  • Про те, які enterprise рішення ганьблять індустрію і чому
  • Наскільки далека JetBrains від свого простого споживача
  • Про те, як індустрія відеоігор змогла «виростити» під себе цілий сектор заліза
  • Що зараз діється на ринку відеокарт
  • Що ще можуть придумати компанії, для того, щоб програми працювали швидше
  • Про те, як буде виживати ReSharper і про нову IDE на 64 біта


Ось відео, а під катом, як зазвичай, текстова версія цього інтерв'ю.

(на одинадцятій хвилині ні звуку. Знаємо, чиним.)


Про технічних євангелістів vs. Technology 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 світі він, напевно, такий самий відомий Адвокат.

— Розумієш, це в якомусь сенсі шоу-бізнес. Природно, ти повертаєшся додому і пишеш купу коду, дебажишь і копаешься у всьому цьому, але коли ти виходиш на публіку – так, це шоу-бізнес, наскільки добре ти можеш донести якусь тему.

Ще одна річ, яку я не згадав, що теж дуже важливо згадати – це походи до клієнтів. Тобто, ми, крім поїздок на якісь заходи, ми ще пишемо – небудь з потенційним, або за вже існуючим клієнтам. Ми говоримо: «Хлопців, хочете поспілкуватися? Ми прийдемо, ми вам можемо щось розповісти, ми можемо посидіти з блокнотом, записати ваші проблеми, подивитися, як ми можемо краще їх вирішити».

Ось, наприклад, ти приходиш в який-небудь хедж-фонд або інвестбанк – тобі потрібен чоловік, який говорить їхньою мовою. І це теж проблема. Тому що таких людей не знайти. У нас є сейлзи, ясна річ, але вони тобі скажуть, скільки це коштує, які ми можемо знижки для вас зробити. А тобі хочеться, щоб хтось живий, хто «Ось, дивись – у мене тут обраховується те-то і не працює то-то» і ми можемо прямо дивитися на цей код і щось з цим робити. Тобто, це теж частина роботи.

— Якщо спробувати за відсотками твого робочого часу це все розкласти – як у тебе виходить приблизно? У вас же, напевно, в команді це по-різному, так?

— Слухай, насправді, все дуже не однорідне в тому сенсі, що дійсно є заходи, на які ми просто будемо їздити кожен рік практично, і то іноді ми робимо перерви. Є заходи, які рік від року вражають уяву. Припустимо, ти знаєш, що там буде 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».

Найголовніше, що у свій час, коли я працював, я відчував приблизно ті ж проблеми, тобто ти працюєш розробником, а тобі компанія не може поставити нормальний комп. Компанія ставить комп, де 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, які зараз ось я купив, — це навушники з жахливою якістю. Але вони вливають стільки в маркетинг, і ти знаєш, що всі спортивні і голлівудські зірки в цих навушниках. І цей поганий товар, завдяки маркетингу, продається!

Наскільки далека 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, у нас, наприклад, є BOSS.

До речі, це дуже хороший приклад. BOSS – це компанія, яка робить сумнівну за якістю аудіо. Але вони, наприклад, роблять краще в світі навушники з активним шумозаглушенням, тобто батарейка бере шум літака і в протифазі його тобі у вуха посилає, і це шикарна річ. Незважаючи на те, що якість звуку у тебе втрачається, зате у тебе йде ізоляція від шуму. І це прекрасно. Зрештою вся ця дискусія зводиться до того, що ми заручники ринку, ринок поводиться ось так, а ми за ним йдемо.

Так, відеокарти — це унікальне рішення, тому що людям захотілося грати, робити 3D… Вливання величезних грошей в R&D… Знаєш, студентом і школярем я купував ці карти за шалені гроші, і мої гроші вливалися тому в R&D компанії-виробника, які потім дозволили розростися цієї індустрії. І зараз ми маємо графічні карти без відеовиходи, які використовуються просто для обчислення.

Що зараз діється на ринку відеокарт
— Ні у NVidia CUDA ні APU AMD я не можу назвати популярними рішеннями. Наскільки масштабні взагалі ці технології? Або це все-таки доля гиків?

— Природно, що це доля гиків. Якщо це було б масове рішення, то ми б зараз не обговорювали їх як криза відсутності. Тобто в GPU розрослося зараз кількість ноутов, але з іншого ти можеш купити гігантський трикілограмовий труну, в якому буде окрема відеокарта. І ти можеш купити що-небудь легше, де будуть вбудований відеочіп від Intel.

— А Intel до речі дають API для обчислення на їх вбудованому відеочіпі?

— Не знаю ні про що таке. Не впевнений, що там працює CUDA. Хоча все ж зрушення в індустрії є. Дуже цікаві зрушення у Intel — вони купили Altera і хочуть на серверах забабахати FPGA.

— Там мова йшла про те, що в Intel є історія: у тебе є процесор, у тебе є юзкейс конкретний: сервер, який виконує деяку конкретну роботу. І ти розумієш, що у нього є одне конкретне вузьке місце. Ідея в тому, що якщо якихось блоків не вистачає, якщо вони вузьке місце, то давайте ми їх на льоту зробимо, щоб це вузьке місце розширити. Серверний процесор і так коштує тисячі доларів, так давайте ще за сто баксів щось корисне додамо. Це розумна ідея.

— Так, наприклад, індустрія ігор влила гроші в GPU, фінансова індустрія влила якісь гроші в FPGA, а FPGA, як розумієш, штука, яка дорожче в розробці раз в сто. Тобто, це дуже дорого для створення якихось рішень, але й на це знайшлася попит у високочастотній торгівлі. Ідея в тому, щоб розібрати потік ТСР/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 було ціле мертвонароджене покоління.

— П'ята серія? Після четвертої відразу шоста йде.

— Воно, так. Воно десь з'явилося у вигляді двоядерних рішень.

— Там є пара процесорів буквально.

— Це дуже добре показує, що відбувається в індустрії. Був провал з протягом року, коли хто-то профукав ціле покоління процесорів. Ні 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 часом продукти випускаються інерційно, а не в якомусь зрозумілою ключі.Зараз ось вони вирішили показати світу, які вони опенсорсные, які кросплатформенные.

— Я думаю, що це бізнес-рішення. Вони ж бачать, що все пішло в Android, 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 очевидною стратегії. І це лякає, тому що не знаєш, у що тобі вкладатися, а в що не вкладатися.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.