Хабрахабр

«Там надо знать и веб-стек, и C++»: интервью с Алексеем Козятинским о разработке Chrome DevTools и не только

А как выглядит разработка самих Chrome DevTools? Как разрабатывать с помощью Chrome DevTools, всем известно. Алексей Козятинский ранее работал в Google и занимался именно этим, а теперь перешёл в Netflix, но от прежней деятельности далеко не ушёл.

Насколько реально для обычного разработчика не из Google законтрибьютить что-то полезное в DevTools? Чем именно он занимается сейчас? Какие компьютеры используют инженеры Chrome?

И по такому случаю его подробно расспросили двое участников программного комитета HolyJS: Дмитрий DmitryMakhnev Махнёв и Алексей zolotyh Золотых.
Дмитрий Махнёв: Расскажи немного о себе. У нас сейчас идёт конференция HolyJS 2019 Piter, где Алексей уже выступил с новым докладом «Протокол Chrome DevTools» (запись можно увидеть в бесплатной трансляции). Где, как, откуда, чем занимаешься сейчас?

В основном делал JavaScript-отладчик и всё, что связано с JavaScript, Node и всем, что можно представить вообще вокруг JavaScript. Алексей Козятинский: Вернусь чуть-чуть назад и расскажу, что более четырёх лет занимался Chrome DevTools в компании Google. И сюда я пришёл делать очень простую вещь: у них есть свой собственный внутренний веб-движок со своим странным собственным JavaScript’ом. Сейчас же я работаю в другой компании, которая называется Netflix. И, соответственно, моя цель была — сделать эти инструменты.
Она до сих пор актуальна, я что-то делаю и отвечаю абсолютно за всё: за бэкенд этого дела, за то, чтобы фронтенд DevTools нормально работал. И ко всему этому делу необходимы свои собственные крутые инструменты, которые можно назвать «Chrome DevTools». Чтобы не было так, что мы форкнемся, навсегда разойдёмся и потеряем результат работы моих классных коллег из Google. И при этом наша цель — работать таким образом, что я продолжаю контрибьютить в Chrome DevTools, апстримить все патчи, какие только можно. Так что я продолжаю делать то же самое, что и раньше — Chrome DevTools.

Дмитрий: Клёво.

Во-первых, почему попыток? Алексей Золотых: В твоей биографии на сайте HolyJS есть такая формулировка: «Возглавлял большинство попыток компании улучшить жизнь разработчиков, начиная с асинхронных стеков и заканчивая новым модным Query Objects». И во-вторых, можешь подробнее рассказать — это, наверное, больше про Google?

Очень хороший вопрос. Алексей: Начнём со слова «попытки». Изначально это было слово «efforts». И у меня есть на него ответ. Почему я решил перевести слово «effort» как «попытка»? Так как я последние несколько лет живу и работаю в Калифорнии, меня подвёл перевод. Это, безусловно, были «попытки», потому что мы что-то пытались сделать, но это были успешные попытки, большую их часть мы завершали. Наверное, это всё-таки не «попытка».

А async debugging — это то, что нам нужно доделать в Chrome DevTools. Но в то же самое время Query Objects — это было что-то маленькое, о чём можно почитать в Твиттере или на Медиуме, и это то, что мы доделали. Ты пробуешь одно решение — слушаешь пользователей, они приходят к тебе и говорят: «Ничего не понимаю, что здесь происходит, можете, пожалуйста, что-то с этим сделать?» Ты пробуешь по-другому, пытаешься сделать что-то ещё, и так, шаг за шагом что-то получается. Мы это начали делать, пытались несколько раз, потому что это нетривиальная вещь. Но важно сказать, что большинство попыток были успешными.

Я пришёл туда когда-то стажёром. В компании Google я провёл большую часть своей разработческой жизни. Придя туда, я был обречён заниматься Chrome DevTools: у меня не было другого выбора, потому что я пришёл стажёром в команду Chrome DevTools. Это было ещё в замечательные времена, когда в Петербурге был офис компании Google. У нас есть крутой API, который позволяет взять весь JavaScript-код, как-то его обработать, вернуть обратно и сказать Chrome, чтобы он вместо пришедшего нам JavaScript выполнил другой JavaScript». Мне сказали: «Вот тебе очень простой стажёрский проект.

Я помню, что об AST-деревьях был отличный доклад на HolyJS. У нас был такой API, и на его основе можно было построить AST-дерево. И это был такой интернский проект, он у меня всё ещё лежит где-то на GitHub. Надо было распарсить AST-дерево и заинструментировать код таким образом, чтобы померить время исполнения, а на самом деле написать инструментирующий профайлер. Мне было очень грустно в тот день, потому что это был API, на котором был построен весь проект — «удали его». Он очень давно не работает в Chrome, потому что API, который он использовал, меня же самого попросили выпилить — его было сложно поддерживать. Из стажёров через три месяца я перешёл в инженеры — остался в Google и начал заниматься всем, что связано с JavaScript. И я его удалил. А потом постепенно так получилось, что основная часть команды инструментов, связанная с JavaScript, покинула команду по некоторым причинам, и мне оставили на откуп практически весь JavaScript. Начинал с чего-то очень простого: мне надо было починить console.log(). В тот момент было очень страшно, но я собрался и постепенно начал что-то делать, что-то понимать.

Сейчас у нас уже async/await, появились arrow function’ы во всех возможных фреймворках, поэтому нам понадобились inline breakpoint’ы (без них стало никак) — и многие такие маленькие улучшения я делал, делал, делал. В то же самое время развивался JavaScript, как мы знаем, там появились асинки, промисы. Async-стеки вылились в большую работу, это async-модель, которая описывает асинхронность в JavaScript’е очень простым языком.

У меня там очень много патчей. И так как нельзя работать в Chrome DevTools над фронтендом JavaScript и ничего не знать о движке V8, в процессе всей этой работы мне постепенно пришлось всё больше и больше контрибьютить в V8. Это, конечно, было логично сделать с самого начала, но исторически он был не там. В какой-то момент мы перенесли бэкенд JavaScript из кода Chrome в код V8. И мы это сделали, в этом проекте я был не самым главным, но я активно помогал тем, кто его делал. В то самое время у нас появился Node, надо было как-то его поддерживать, и мы решили, что если мы умеем дебажить V8, а Node вроде бы использует V8, почему бы нам не сделать поддержку Node у нас? Этим всем я и занимался в Google около пяти лет.

Дмитрий: Что ты считаешь из этого самым крутым и сложным?

И последним был интересный проект, который мы делали. Алексей: Запоминается лучше всего почему-то последнее. Если вам хочется потестировать новые фичи JavaScript (на тот момент это был BigInt), вы просто печатаете в консоли, сразу видите результат, и вам не надо нажимать «Enter» и засорять вашу консоль миллиардом результатов. Это сейчас в консоли Chrome DevTools, когда вы что-то печатаете, вы можете видеть вживую результат выполнения того, что вы печатаете. Нам было очень важно, чтобы при жадном выполнении всех ваших выражений мы не разрушали состояние вашей программы, иначе все наши пользователи очень сильно расстроились бы. И сделать это правильно — сложней, чем кажется. И это было сложно, долго и никто до нас этого не делал, нет больше подобных JavaScript’овых движков. И для того, чтобы это сделать, нам пришлось взять JavaScript, взять V8 и добавить в него такую возможность: выполнить любое выражение, но гарантировать, что оно не изменит состояние вашей программы. Может быть, в Java есть (потому что в Java, как мы знаем, есть всё), но я не уверен. Я не уверен, что вообще есть такие движки. И на тот момент мы это сделали.

И это был отдельный effort: выяснилось, что код Chrome сам по себе не любит, когда в случайный момент времени JavaScript заканчивается, в таком случае он любит сказать: «М-ме…», — и крешнуться. Это был очень долгий процесс, который вовлёк в себя много разных команд, потому что нам важно было не только выполнить без «побочных эффектов», но и гарантировать, что если вы вдруг начнёте выполнять бесконечный цикл while (true), то вы не подвесите всё на свете, потому что поток JavaScript всё-таки один. И это мы тоже сделали. Это пришлось починить.

Google патентует не для того, чтобы потом за вами гоняться, а, как и большинство других компаний (кроме старого Oracle, наверное), чтобы в случае чего защищаться, если вдруг к ним кто-то придёт и скажет: «Чуваки, вы сделали Google-поиск, это плохо, у нас есть патенты». Проект этой работы вылился в то, что Google даже получил патент. Google скажет: «А у нас вот здесь есть такой патент на JavaScript debugger». И те чуваки будут почему-то одновременно делать JavaScript debugger. Google выдаёт маленький кусочек пазла, когда вы получаете патент. Ну, патентные адвокаты лучше знают, что там происходит, но мы запатентовали, это было весело. И это было очень интересно, потому что никто это раньше не делал, и у нас получилось это сделать. Он очень прикольный.

Дмитрий: А казалось бы, просто в консольке что-то выводится.

Цитата чья-то была о том, что любая хорошо сделанная технология неотличима от магии. Алексей: Да-да, это всё очень «просто», конечно.

А что из того, что очень хотелось сделать, не удалось сделать? Дмитрий: Ну да, интересно. Более мощное? Что-то ещё?

Всегда хочется всё сделать, и никогда не хватает времени. Алексей: Это очень опасный вопрос. Это async-модель, и async debugging всё-таки надо было допилить, конечно же, и сделать её более очевидной для пользователя, сделать ещё некоторые шаги. Хотелось бы, конечно, доделать вещи, которые мы начали, но я не доделал. Например, вы остановились на исключении и знаете, как это исправить, сразу исправляете прямо там, сохраняете файл, и всё дальше работает, а исключения как будто и не было — всё пофиксили вживую. Не уверен, что именно там делать, но из важного, что хотелось доделать: в V8 есть механизм, схожий с HotSwap в Java и с подобными технологиями, когда вы можете в вашей программе, которая прямо сейчас исполняется, взять кусочек кода и обновить наживую. Некоторые считают, что он может даже в некотором смысле заменять отладку, потому что вы постепенно пишете код маленькими кусочками, сразу видите, что происходит — отлаживать после этого практически не нужно. Это очень крутой инструмент.

Он был написан немножко в другом мире, в другой реальности — там был другой V8, там не было всех этих Ignition, TurboFan и всего прочего. И у нас очень давно, лет 9-10 назад, был код, который это делал. Ничего не было. Я не уверен, что там на тот момент даже Crankshaft был, это предыдущий компилятор в V8. Код был очень старый, он использовал какие-то очень старые внутренние утилиты V8, которые поддерживали только для этого кода, потому что на тот момент никто не хотел разобраться в этом коде и его переписать. И async/await тоже не было, конечно же.

Но он до сих пор очень часто говорит, что не может отредактировать ваш код, потому что там, например, не хватает поддержки генераторов. В какой-то момент я сел и переписал его, и он стал меньше крэшиться. А когда у нас появились async/await, каждая async/await-функция, на самом деле, сама по себе генератор. Когда писали этот код, встречался один генератор на миллион строчек кода в JavaScript. Поэтому, если вы попросите отредактировать код с async/await, вы разочаруетесь.

И это очень хотелось бы доделать. А так как это всё-таки инструменты для разработчиков и отладки, тут есть неприятная особенность: если при использовании инструмента он не работает два раза из десяти, им больше пользоваться не станут. Может быть, мы это доделаем, так как я сейчас, возможно, привнесу V8 на моё новое место работы и смогу за счёт этого продолжить работу над ним.

Дмитрий: Это могло бы работать исключительно во время отладки, или теоретически можно было бы и в каком-нибудь продакшне single page application менять частичку приложения?

Если на паузе, то у вас есть текущий stack trace, который уже есть и исполняется. Алексей: С точки зрения V8, в продакшне это менять проще, сложнее поменять, когда вы стоите на паузе. А когда у вас просто продакшн, вы можете дождаться момента, когда JavaScript закончился (будем надеяться, что у вас там нет while (true)), и в этот момент всё незаметно заменить. Надо как бы обновить этот код и заставить весь этот текущий стек, который ссылался на какие-то переменные в вашем коде, продолжить работу.

А основная сложность — это, конечно, заменить все ссылки, перезапустить все фреймы, перезапустить генераторы и так далее. И это значительно проще, потому что можно просто заменить код, не нужно обновлять все ссылки.

Там есть такая функция, когда отредактировал JavaScript и можно его как-то привязать к файловой системе, и то же самое со стилями. Алексей: У меня внезапно возник вопрос по поводу использования Chrome DevTools как IDE. А я человек ленивый, я люблю в одном месте, например, поправить. И у меня к нему очень много вопросов, потому что он не работает.

Важно сказать изначально, что Chrome DevTools никогда не были IDE, никогда не позиционировали себя как IDE. Алексей: Вопрос, видимо, в том, почему оно не работает. Chrome DevTools строился сначала как инструмент, а потом как редактор. IDE — это проект другого масштаба, он требует других усилий и больше людей. В отличие от IDE, которые появляются как редактор, а потом добавляют отладчик, плагинчики и так далее.

Вы меняете код, который вы видите внутри странички, вам необходимо понять, откуда этот код вообще появился в вашей страничке и аккуратненько его применить изменение обратно. При этом мы понимали, что нашим пользователям было бы очень приятно отредактировать и сохранить, было несколько попыток это сделать — сейчас, наверное, вторая или третья попытка… Но всё упирается в то, что в вебе, с учётом существования всех этих webpack, компиляторов CSS и всего прочего, очень нетривиальной задачей является применить изменения обратно.

Сейчас у всех webpack, Babel и так далее. Поэтому, с другой стороны, можно сказать, что можно просто сделать, чтобы работало для людей, у которых нет таких сложных конфигураций, но, к сожалению, это очень маленький процент наших пользователей. Для CSS и для SASS это было сделано каким-то магическим образом, и иногда, кажется, оно работает, я не пользовался. И они в одну сторону очень легко транспилируют и что-то делают, а чтобы в обратную сторону получить информацию — это проблема.

Вы можете использовать Visual Studio Code либо вашу любимую IDE (WebStorm или ещё что-то), поредактировать там код, а Chrome DevTools попробует применить эти изменения вживую. Изменится ли это в будущем, можно ещё спросить. И там уже сложно, но я всё ещё надеюсь, что на Node большая часть пакетов и модулей написана на чистом JavaScript без промежуточных шагов билда. Но на самом деле, у нас есть отдельный проект нашего фронтенда для Node, наверное, мы о нём ещё позже поговорим, там это работает чуть лучше, потому что, слава богу, в Node максимальный уровень транспиляции и компиляция TypeScript в JavaScript. Не ответил я на вопрос, но как мог.

Каких самых крутых вещей от него ожидать? Дмитрий: А как ты думаешь, как дальше будет развиваться Chrome DevTools в принципе?

В какой-то момент на Google I/O появился человек, который сделал очередной удобный инструмент для дизайнеров. Алексей: Это сложный вопрос. И оно добавляет прямо поверх вашей странички какие-то элементы, которые позволяют вам как дизайнеру проще всё редактировать и делать. Это расширение для Chrome, к сожалению, не помню название. Это и так уже достаточно удобный инструмент, который может, например, смотреть CSS и прочее, но всё ещё можно сделать значительно более идеальным и удобным. И были идеи, что Chrome DevTools может быть более удобным инструментом для дизайнеров. Их надо чинить, их много, и очень много времени уходит на то, чтобы просто сделать так, чтобы всё работало. Например, более удобное редактирование flex-свойств и прочие маленькие улучшения.
И ещё есть важная часть работы над Chrome DevTools: проект очень большой, у него очень много пользователей и большой поток багов, которые каждый может зафайлить на сайте crbug.com. Для отладки JavaScript live edit, о котором мы говорили, hotswap может быть хорошим следующим шагом дальше, но он может случиться, а может и нет, не знаю.

Но есть же другие браузеры — Safari, Edge пока ещё есть, Firefox опять же. Алексей: Chrome DevTools, мне кажется, объективно самое навороченное программное обеспечение для помощи веб-разработчикам. Есть что-то, что нравится, как клёво сделано? Есть какие-то инструменты, которые хотелось бы утянуть из других браузеров в Chrome DevTools?

Из интересного, что я там приметил в последнее время, помню, что в Safari была очень удобная консоль. Алексей: Разработчики Chrome DevTools регулярно смотрят на другие браузеры. Вы можете там выбрать объект, нажать «вправо» — он раскроется. Они очень красиво структурировали вывод в консоль, и добавили навигацию с помощью стрелочек по результатам. В итоге сейчас эта фича есть в Chrome DevTools. Это было чертовски удобно.

Это круто, у нас это частично есть, но не полностью. В Firefox из интересного в DevTool’ах, они, мне кажется, чуть лучше поддерживают визуальное редактирование всяких CSS-свойств — под этим я подразумеваю свойства типа flex и прочие, — они вам показывают грид прямо поверх странички, и можно всё это подвигать вверх-вниз. Если вам почему-то приходится писать WebAssembly-код, то они значительно лучше нас, потому что у нас ничего не было полгода назад, сейчас я не проверял. Firefox DevTools, я думаю, на данный момент имеет безусловно лучшую поддержку WebAssembly. Мне кажется, они в это инвестируют много сил.

Что до Safari… в каком-то смысле Chrome DevTools — это форк Web Inspector из Safari, поэтому всё самое лучшее, что у них было, мы забрали.

Наверное, только в Firefox есть Time Travel Debugging. Важное вспомнил! О нём я умолчал когда меня спрашивали про следующие большие шаги: звучит очень круто, очень монументально — до сих пор не верю в то, что это очень полезно. На Mac в Nightly-билдах Firefox’а вы можете побаловаться с Time Travel Debugging’ом. Но у них он есть, вы можете попробовать, если вам поможет — это будет новый интересный инструмент. Личная точка зрения.

Мои бывшие коллеги меня бы не простили, если бы я не спросил про одну вещь, которая нам была очень-очень-очень нужна. Дмитрий: Вот касаемо отдельных инструментов. Но если с ним начинал играться, то всё очень-очень сильно умирало, вплоть до крешей. Я даже не помню название, но был очень крутой (с точки зрения идеи и частично с точки зрения реализации) инструмент, который показывал композитные слои, которые получились от CSS.

Когда вот эта штука вернётся и будет работать хорошо и стабильно? По своему опыту могу сказать, что бывает очень важно на больших проектах сесть с такой штукой и отловить действительно жёсткие проблемы, когда композитные слои друг на друга понаезжали и всё получилось очень плохо. Может быть, самому можно по этому поводу чуть-чуть попробовать подпилить? И вообще, к кому идти за ней?

К кому идти? Алексей: Начну с конца. Все эти feature request’ы, безусловно, читают: не факт, что делают, но читают. Это, опять же, crbug.com, там завести feature request. Можно написать в твиттере: есть аккаунт Chrome DevTools, есть аккаунты всяких инженеров из Chrome DevTools, например, Пола Айриша. И это иногда оказывает некоторое влияние на то, что мы делаем дальше. Пишите, жалуйтесь и, надеюсь, вы будете услышаны.

Если вы очень серьёзно настроены, то это можно осилить, люди будут счастливы, и команда Chrome DevTools будет счастлива, но это сложно. Попилить самому такую вещь, как композитные слои, можно, но очень высокий порог входа — вам придётся потратить бесконечное количество времени, чтобы понять, как это работает в Chrome. А во-вторых, проект всё-таки огромный, и чтобы хотя бы понять, где копать, без какого-то инсайда, без человека, который вам поможет… Не знаю, очень круто, если у вас получится. Потому что, во-первых, вам нужно очень мощное железо, чтобы иметь возможность просто собрать Chrome и поиграть с ним.

🙂 Дмитрий: И потом возьмут в Google?

У нас был когда-то инструмент, назывался layers panel, по-моему. Алексей: Если вы потом захотите пойти в Google и добавите это в резюме, безусловно, это будет хорошим подспорьем. Потому что это очень продвинутый инструмент, безусловно, нужный, но думаю, что большая часть людей с композитными слоями не сталкивалась. Его судьба была сложная, потому что требовалось много сил для поддержки, а количество пользователей исторически было низким. По крайней мере, я не сталкивался, тут лёгкая предвзятость.

Нажмите Cmd/Ctrl + Shift + P, наберите Show layers — этот инструмент может помочь. Куда его спрятали? Это где-то есть, это всё ещё не удалили. Discoverability некоторых фич в Chrome DevTools — это то, что, безусловно, требует большой работы и исправлений. Она крутая, но всегда хочется делать фичи, которые крутые, полезные и ими может пользоваться большое количество людей. Но могут удалить в любой момент, потому что надо как-то эту фичу переделать.

Дмитрий: У этой штуки такой прикол, что, когда она тебе становится нужна, это уже прям совсем вилы.

Алексей: Это я согласен.

Там такой инструментарий нужен. Дмитрий: Например, когда у тебя случаются проблемы на главной странице какой-нибудь маленькой социальной сети. Да, я согласен, проблема не распространённая.

Что сталкивался с такой проблемой и пытался её решить. Алексей: Ты можешь рассказать об этом на HolyJS.

Ну, сам инструмент тоже чуть-чуть трогал. Дмитрий: Я чуть-чуть сбоку, так сказать, из-за плеча смотрел и чувствовал, что происходит. Как-то так и было. Это как раз про то, что ты говорил: один раз что-то упадёт, и ты в это больше не очень-то веришь.

По двум причинам. Алексей: Ты упомянул, что если я захочу что-то разрабатывать в Chrome, то, скорее всего, у меня не получится. И второе — это очень высокий порог входа. Первая — железо, у меня не такой уж мощный ноутбук. Но всё-таки что-то можно сделать, чтобы помочь команде?

Я имел в виду именно про композитные слои, вся эта композитная логика в Chrome очень сложная. Алексей: Не всё так плохо. Но если вы хотите сделать что-то, что проще с точки зрения кода Chrome, это может получиться.

И, соответственно, вы можете сделать что-то в Chrome DevTools, такие патчи вообще очень приветствуются. Если вы откроете на GitHub проект Chrome DevTools (это зеркало нашего фронтенда), там есть небольшая инструкция, как вы можете локально собрать DevTool’овый фронтенд без необходимости собирать Chrome, что сэкономит вам безумные часы времени на вашем компьютере. Либо вы хотите добавить что-то простое. Иногда бывает, что сначала фиксят какие-то простые баги, что-то, что вам мешает и раздражает. Например, не так давно человек добавил редактор cookies.

Он не использует никакие фреймворки, он написан на JavaScript’е, на таком очень ванильном базовом CSS, и HTML там тоже практически нет. И подобные вещи можно делать, DevTool’овый фронтенд, с этой точки зрения, относительно простой. Единственная проблема, что какой-то фреймворк там всё-таки есть, и он свой собственный, доморощенный, поэтому придётся потратить некоторое время. Такой настоящий single-page application.

Есть сайт cs.chromium.org, и на нём удобный поиск по коду. Но в принципе лучший подход — смотреть на что-то подобное тому, что вы хотите сделать (например, такая же кнопочка где-то есть), искать это в коде Chrome, смотреть, как это сделано, и творчески перерабатывать.

Среди наших багов, к сожалению, нет раздела «хороший первый баг», но в других компонентах Chrome есть такая вещь, как good first bug — надо поискать такой лейбл найдёте некоторые баги, которые считаются хорошими для только что пришедших разработчиков.

Я не говорю, что попроще, он тоже очень сложный, потому что это виртуальная машина. Альтернативная возможность, которая у вас есть, если вы хотите поработать над JavaScript — V8 проект чуть поменьше, чем весь Chrome. Либо наоборот, если вас что-то раздражает в поддержке Node, вы делаете это для Node, а потом портируете в Chrome. Но там вы тоже можете поделать что-то для дебаггинга и, когда вы будете делать что-то там, у вас сразу открывается возможность сразу сделать что-то не только для Chrome, но и для Node. И, соответственно, сразу делаете счастливыми в два раза больше пользователей.

Если вам очень сильно хочется закопаться в Chrome, это тоже можно делать, но каким-то образом вам нужно найти очень быстрый компьютер, иначе вы просто будете 15 часов собирать Chrome. Поэтому можно начинать с этого, пробовать в V8 что-то чинить, пробовать что-то делать в DevTool’овом фронтенде отдельно.

Дмитрий: А на каких машинах вообще работают те разработчики, которые пишут Chrome?

Там стоят последние Xeon, 64 или 128 ядер — это бесконечное безумие. Алексей: На достаточно уникальных, Lenovo делает специальные рабочие станции, которые в Google специально для инженеров Chrome отдельно добиваются оперативной памятью и всем прочим. И хотя я молод, но на моём первом компьютере оперативной памяти было меньше. Я помню, на процессоре кеш первого уровня был 32 мегабайта. И я помню, что GTA 2 отлично работала на моём первом компьютере.

И эти машины стоят каких-то огромных денег — компания Google позволяет вам заказывать железо и не платить за него, но когда вы заказываете, Google всегда показывает, сколько он на вас потратил. В общем, там какое-то безумие творится. У Chrome есть распределённый компилятор для C++, но иногда компилировать локально на таком компьютере оказывается быстрее. Там абсолютно безумные числа, и это крайне производительные машины, у последнего поколения этих машин получается интересный профит. То есть распределённость даром не нужна, когда у вас есть под боком такая рабочая станция.

Алексей: Зато из дома не поработаешь.

У меня был какой-то плагин, который позволяет удобно синхронизировать код между разными машинами по SSH. Алексей: Дома я справлялся с этим тем, что по SSH подключался к своей машине и код туда-сюда гонял, не помню, с помощью чего. На Mac’е, конечно, люди собирают, это как-то работает, с распределёнными компиляторами это всё ещё работает более-менее, но распределённый компилятор закрытый, он не опенсорс, к сожалению. И я писал на своём Mac, потом заходил в терминал и запускал команду: «Скомпилируй этот код и прогони тесты».

Интересно, такой комп дороже самолёта? Дмитрий: Сурово.

Я недавно смотрел стоимость Cessna, это такой очень популярный самолёт, и он даже подержанный в 17 раз дороже. Алексей: Не-не, сильно дешевле самолёта. Всего плюс-минус 17 компьютеров команды Chrome DevTools.

Точнее, пореальнее, с точки зрения работы. Дмитрий: Окей, давай к чему-то, может быть, попроще. Ты уже упоминал, что, разрабатывая Chrome DevTools, приходится чуть-чуть затрагивать V8 и Node. По-моему, недавно ты презентовал ndb (или какую-то его часть), ты один из его контрибьюторов. Это была какая-то рабочая задача или личная инициатива? Как ты оказался рядом с ndb, и почему ты решил сделать что-то для Node?

У нас в Chrome DevTools поддержка Node появилась достаточно давно. Алексей: ndb — проект с очень тяжёлой судьбой. Потом появился dedicated — это отдельный фронтенд для Node. И она была изначально припрятана: Node запускался и говорил вам перейти на магический URL, вы переходили, открывался фронтенд. Вы её открываете, и этот фронтенд автоматически коннектится ко всем нодам, которые вы запускаете локально. И вы можете сейчас зайти на chrome://inspect, там будет такая синяя ссылка «open dedicated frontend», что-то в духе этого. И возникла идея внутри команды, что, наверное, это слишком сложно — лишние шаги. Это как-то работало, но пользователей было мало, и было непонятно, почему. И value, которое мы приносим пользователям по сравнению с теми шагами, которые надо преодолеть, не соответствует.

И в этом случае решили сделать что-то, что вы можете установить с помощью npm — «npm install -g ndb» — и чтобы это просто был дебаггер. Поэтому было решено увеличить то, что мы даём пользователям, и уменьшить порог входа. На данный момент он работает с Chrome, который у вас установлен из коробки. Изначально он требовал скачивания всего Chrome, и это был достаточно большой пакет. Вы устанавливаете и запускаете этот фронтенд. И поэтому там 2,6 мегабайта кода Chrome DevTools вместе с картинками. Это с точки зрения простоты установки.

И ndb решил эту проблему. Помимо того, хотелось привнести какое-то value: до этого нельзя было дебажить child-процессы, что было большой проблемой для людей, у которых они есть.

И в отзывах, которые мне больше всего понравились, люди были счастливы от того, что кто-то начал делать дебаггер для Node, не начиная с редактора, а начиная с тулов. Проект изначально позиционировался так, что это будет такой очень дружественный к экосистеме Node дебаггер для Node.

И он достаточно неплох. Потому что всё-таки есть Visual Studio Code, который позволяет дебажить Node. А тут удобный инструмент заточенный для Node. Но это всё-таки IDE и это страшный комбайн, который переваривает ещё и Python, и всё остальное, что только можно. Я склонен думать так: Chrome DevTools — инструменты для веба, ndb — инструменты для Node.

Думали, незаметненько там запустим, а в итоге это оказалось через 15 минут на Hacker News и собрало какое-то бесконечное число звёзд. Сделали, запустили, хотели незаметно запустить на Google Chrome Labs — у нас есть специальный GitHub-репозиторий для таких экспериментальных проектов, которые вообще никому не должны быть интересны. И иногда это работает и работает неплохо. Несмотря на то, что ничего не работало (и до сих пор не работает, я должен это признать), люди как-то лайкают и им нравится.

Удивительным образом выяснилось, что писать на Node на Windows, Linux и Mac, когда вам надо активно взаимодействовать с файловой системой — очень сложно, файловая система медленная, файловая система полна всяких странных ограничений. Проект оказался с тяжёлой судьбой, потому что выяснилось, что писать на Node сложно.

Но всё-таки там это реализовано таким образом, что в этот момент оно просто падает, нет никакой возможности быть более гибким. Ну не странных, наверное, вполне логично, что вы не можете подписываться на изменения в больше, чем n файлов. Там началось веселье. И ещё есть стандартные проблемы с тем, что в environment-переменных Windows нельзя передавать пробелы, а в Linux — можно, и так далее. И так как ещё не было под рукой Windows-машины, это превратилось в какой-то кошмар.

Проектом кто-то пользуется, я иногда им пользуюсь, и мне очень нравится, когда он работает. Мы победили большую часть багов, но их всё ещё очень много. А по поводу того, как это всё родилось — просто родилась внутри команды идея, что надо сделать лучше поддержку Node, и выяснилось, что на тот момент я был лучшим человеком, который может это сделать. Надо похвалить то, что сам сделал. Но самый главный результат ndb, на самом деле, это Carlo. Я, конечно, контрибьютор в этот проект, но мне кажется, я единственный контрибьютор в этот проект на данный момент. На данный момент он очень далёк от Electron по возможностям и медленнее его, но это некий взгляд на то, как можно сделать Electron иначе. Carlo — это очень своеобразный ответ Electron.

Дмитрий: Это та штука от Google, которая использует твой текущий Chrome?

Там это сделали впервые и, соответственно, код из ndb. Алексей: Да, она появилась из ndb.

А чтобы комфортно работать над Chrome DevTools, делать штуки, которые ты делал, какой нужен набор скиллов? Дмитрий: Прикольно, инсайды. И, вообще, как попасть в такую команду?

Есть путь стажёром. Алексей: Как работать в Chrome DevTools? До этого я никогда не видел язык и был, видимо, из той категории людей, которые думают, что вот есть Java, а в JavaScript, наверное, что-то похожее должно быть. Он такой, с лайфхаком, потому что, когда я пришёл в команду Chrome DevTools, это был первый день, когда я написал первую строчку на JavaScript. Ну ладно, всё не так плохо было.

Вы должны быть веб-девелопером. А правильный набор скиллов: вы должны знать веб-стек, конечно же. Потому что хороший, крепкий инженер Chrome DevTools обычно владеет и бэкендом, и фронтендом. Но помимо этого, вы должны быть очень специфическим специалистом, и вам надо знать C++. Ваши шансы попасть в команду Chrome DevTools значительно выше, если вы почему-то знаете и C++, и веб-стек. У нас есть, конечно, и чисто фронтенд-разработчики и чисто бэкенд-разработчики, но всегда лучше, когды вы знаете и то, и другое.

Но, к сожалению, не учится! Я значительно лучше знаю C++, сейчас я знаю JavaScript, но вот CSS… Я помню ещё доклад с HolyJS, где говорилось, что CSS — это технология, которую учить не обязательно, она сама выучится. Неожиданно.

Если вы знаете что-то одно, вас, скорее всего, рассмотрят, если вы хотите. Соответственно, если вы знаете и C++, и веб-стек, вас возьмут. Можете податься на обычного software-инженера и потом, когда будете говорить с рекрутером, сказать: «Я всю жизнь мечтал писать Chrome DevTools». Не уверен, что есть вакансии именно на careers.google.com, можно посмотреть, может, там есть Chrome DevTools, но, скорее всего, там есть software engineer-вакансия, как обычно.

Если вдруг всё-таки захотелось. Дмитрий: На каком уровне нужно знать С++?

Ну, конечно же, метапрограммирование на шаблонах — это, возможно, не очень ценный навык, это не нужно знать. Алексей: Хороший вопрос по поводу уровня плюсов. Обычно это зло: в популярном промышленном коде большого опенсорс-проекта люди стараются этого избегать, просто потому что порог вхождения туда очень высок, а хочется, чтобы как можно больше людей могли что-то писать.

Чуть лучше, чем «Hello, world!», в общем. Соответственно, вам надо знать C++ на каком-то базовом уровне, классы понимать и так далее. Постепенно фичи от новых C++ приходят в код Chrome, но он всё ещё C++ 11, а новые фичи мы постепенно адоптим. И стандартную библиотеку знать не обязательно, потому что вам придётся выучить стандартную библиотеку, которая есть в Chrome. Нет ничего вроде требования знать Boost или конкретный фреймворк.

Мы знаем, что ты закончил серьёзную питерскую физико-математическую школу 239, насколько это помогает и насколько это надо? Дмитрий: Ещё по поводу навыков. Как мы обычно программируем single page application. Или всё-таки там задачи в основном логического уровня?

В твиттере регулярно появляются споры на тему того, нужен computer science-бэкграунд или не нужен. Алексей: Мне кажется, что после того, как вы переведёте это на английский, меня уволят, но я вынужден это сказать. Регулярно люди делятся на два лагеря: одни говорят — без этого никак, а другие говорят — да нафиг это нужно, тратить долгие годы.

В Google попасть будет сложнее, потому что собеседования в Google настроены на людей после университета. Безусловно, без этого можно жить и вы выживете. Вы можете их подготовить отдельно, конечно. И все эти алгоритмические задачки, которые вам большую часть жизни не нужны, у вас спросят на собеседовании. То есть computer science-бэкграунд вам очень сильно поможет пройти собеседование, а в работе…

И заложили очень хорошие фундаментальные знания, которые важны, на их основании вы можете быстрее учить что-то новое. Вот 239, на самом деле, больше была не про математику, а в принципе про подход к обучению, мне кажется, и это феноменальный опыт и там научили учиться. Это не проблема. У вас нет такого вопроса, что вот JavaScript — как его учить? JavaScript — это страшный микс, на самом деле. Вы знаете, что вы знаете a, b и c, в каждом из них есть часть JavaScript, и вы понимаете, что JavaScript это просто микс других концептов вместе.

В принципе, когда вам нужно поговорить о чём-то с коллегами, вам проще описать то, о чём вы говорите. Соответственно, фундаментальное образование и CS-бэкграунд позволяют вам быстрее учить всё новое, лучше понимать и ориентироваться. Поэтому это круто иметь, если у вас есть такая возможность, пойти получить хорошее computer science-образование — я только за, я считаю, что это must have, без этого никак. Вы можете понять то, что хочет до вас донести коллега, потому что вы знаете, о чём он говорит, более-менее. Но это люди, которые просто готовы сами очень серьёзно учиться. Но, безусловно, я знаю примеры, очень много успешных разработчиков, у которых его нет и они достаточно успешны.

Дмитрий: Получается, когда ты пишешь какую-нибудь отладку асинхронного JavaScript, там же всё-таки, наверное, присутствуют какие-то сложные алгоритмы и структуры данных?

Это всё присутствует, конечно, но мне кажется, что когда вам что-то нужно, вы, безусловно, можете найти на Stack Overflow, какую именно структуру данных вам нужно использовать, почитать о ней и за пару дней разобраться. Алексей: Да. А так да, когда async-стеки писали, нам нужно было свой маленький garbage collector написать. Просто если вы эту структуру проходили в университете, вам не нужна эта пара дней, вы просто сразу пишете.

Такой вопрос: а как ты сам учишься? Дмитрий: Прикольно. Что смотришь? Грубо говоря, что читаешь, про что читаешь? Именно для образования.

В основном сейчас я пытаюсь закрывать некоторые пробелы, CSS и так далее. Алексей: Хороший вопрос. Ресурс — это Google-поиск, просто ищу что-то и пытаюсь читать. На самом деле, у меня нет такого ресурса, который я могу всем посоветовать. Так получается, что я не могу сказать, что я активно уделяю этому время. Это очень неэффективный подход, я твёрдо уверен, что есть хорошие ресурсы, которые вы открываете и сразу находите то, что нужно, и не надо перелопачивать много информации. Я иногда смотрю разные видео лекции.

Там выходец из постсоветского пространства читает курс в Беркли как профессор. Последнее, что я смотрел — очередной курс про интеллект. ред.: хотя игры с геймерами Zest, soO и Stats мы не нашли) и так далее — это модный нынче Reinforcement Machine Learning. Очень интересно рассказывает обо всём современном в состоянии искусственного интеллекта, если вы слышали о победе в го, обо всех этих успехах DeepMind в игре в StarCraft (прим. Если бы это был бы youtube, там бы уже было 15 комментариев, что я не понимаю, о чём говорю. Сейчас специалисты по Reinforcement Machine Learning уже пошли писать комментарии.

Такого, что я трачу два часа в неделю на самообразование, у меня нет. В последнее время так получается, что просто работа-работа-работа, и в работе постоянно нужно какие-то маленькие нюансы выучить, понять и осознать, и ты их быстро учишь. Играю на гитаре, но это никак не помогает мне писать на CSS.

Алексей: Откуда ты знаешь?

На самом деле, есть разные теории. Алексей: Я не знаю, мне так кажется. Зная лучше английский, я могу читать больше статей и слушать больше подкастов и YouTube — и в итоге быстрее учить CSS. Говорят, что игра на гитаре позволяет быстрее учить другие языки. Но так, чтобы прямо учиться программировать, играя на гитаре — нет. Так что, возможно, связь есть.

А что ты думаешь про митапы и воркшопы в таком разрезе? Дмитрий: Прикольно. Насколько они полезны?

Я участвовал однажды в Node.js, когда мы помогали людям писать базовый код на Node. Алексей: Чтобы иметь хорошую точку зрения, нужно поучаствовать хотя бы больше, чем один раз. По крайней мере, как всегда, когда вы чему-то учитесь или что-то делаете, самое важное — это ваша целеустремлённость, на самом деле. И мне кажется, что прикольно. Это сложно. Безусловно, будет трудно, вы будете что-то не понимать и не понимать, что вы здесь делаете, но вам постоянно необходимо преодолевать непонимание и кидаться в эту гущу непонятных знаний и слов.

И на таком базовом уровне, мне кажется, это классно, потому что вы помогаете им преодолеть этот первый порог входа. И поэтому мне кажется, что такие базовые митапы и воркшопы для людей — «давайте законтрибьютим первый патч в Node.js» — полезны, потому что вот этот первый шаг, мне кажется, для людей, которые никогда ничего не контрибьютили в Node.js, очень сложный. Потом они столкнутся ещё с пятнадцатью другими порогами, и вам надо помочь им там тоже.

Наверное, ты был на большом количестве конференций. Дмитрий: Переходим к последним вопросам. Кто-то считает, что конференции только для нетворкинга, кто-то — только как доклады, это совсем крайние точки зрения. Без чего, по-твоему, конференция не может быть хорошей? А что для тебя максимально важно?

Я очень люблю те конференции, когда всё организовано настолько хорошо, что я не вспоминаю о существовании организационной части. Алексей: Мне кажется, что очень важной бывает организационная часть. Это всегда очень сильно выбивает из колеи, потому что если вы хотите что-то рассказывать, в моём случае я всегда очень сильно нервничаю и переживаю, а если ещё что-то не работает, мне хочется прямо там сразу же и пристрелить кого-нибудь. Потому что я пару раз был на конференциях, где проектор не работал, ещё что-то не работало. Организационная часть — это как DevTools: когда они работают — всё хорошо, никто никогда о ней не вспоминает и не замечает, а вот когда они не работают — это пожар. Поэтому организационная часть мне кажется очень важной.

Хорошо бы иметь крутые доклады, хорошо отобранные и разнообразные по тематике, потому что всегда приходят достаточно разные люди. И всё остальное тоже важно. И за счёт обмена опытом и разных перспектив на проблемы получать новые знания. Потому что, когда происходит нетворкинг, вы хотите общаться не только с людьми, которые пишут JavaScript-отладчик, а с людьми, которые пишут всё на свете. Соответственно, разнообразие людей, организация, крутые доклады — стандартный набор.

Бывают конференции, на которых есть сильный уклон в жизненное (diversity, как нам выучить CSS и так далее), но нет технических докладов. Очень круто, когда на конференции есть доклады на тему общих жизненных вопросов («не знаю, как CSS выучить наконец-то») и одновременно технических. Всегда нужен баланс. И слушаешь подряд три доклада на такие абстрактные темы, они важные для индустрии, но технической части не хватает. Но баланс — это вещь в восприятии очень персональная и личная, поэтому оставьте организацию. Вывод из этого — очень люблю сбалансированные конференции. Организация — вещь безусловная.

Дмитрий: И совсем финалочка: что ты ожидаешь от HolyJS?

Я жду, как всегда, классных докладов. Алексей: Я очень жду HolyJS, потому что в мае в Петербурге всегда очень здорово. Я жду, когда я снова встречусь со всеми этими классными докладчиками, которых я видел год назад, и жду встречи со всеми этими классными организаторами.

Дмитрий: Политкорректность не нужна, если что...

Для меня самое важное — подготовить хороший доклад. Алексей: Подготовить хороший доклад, на самом деле. Очень жду. Иначе волнение сильное появляется. Извините, пожалуйста, я просто оттуда. Очень люблю HolyJS именно в Петербурге, потому что очень крутая конференция и ещё Петербург в мае, это лучший город на земле, мне кажется. Очень политкорректное интервью. И в мае нету дождя, солнце, прекрасная погода, мосты разводят, белые ночи почти начались, а ещё такая классная конференция — идеальный момент. Что-то я перестарался в этот раз.

После окончания трансляции YouTube будет рендерить запись, и временно будет доступна только часть дня, но позднее она снова станет доступна целиком. Доклад «Протокол Chrome DevTools» (и не только его) можно увидеть в бесплатной трансляции HolyJS, куда попадают доклады из первого зала 24 мая.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть