Как разрабатывать с помощью Chrome DevTools, всем известно. А как выглядит разработка самих Chrome DevTools? Алексей Козятинский ранее работал в Google и занимался именно этим, а теперь перешёл в Netflix, но от прежней деятельности далеко не ушёл.
Чем именно он занимается сейчас? Насколько реально для обычного разработчика не из Google законтрибьютить что-то полезное в DevTools? Какие компьютеры используют инженеры Chrome?
У нас сейчас идёт конференция HolyJS 2019 Piter, где Алексей уже выступил с новым докладом «Протокол Chrome DevTools» (запись можно увидеть в бесплатной трансляции). И по такому случаю его подробно расспросили двое участников программного комитета HolyJS: Дмитрий DmitryMakhnev Махнёв и Алексей zolotyh Золотых.
Дмитрий Махнёв: Расскажи немного о себе. Где, как, откуда, чем занимаешься сейчас?
Алексей Козятинский: Вернусь чуть-чуть назад и расскажу, что более четырёх лет занимался Chrome DevTools в компании Google. В основном делал JavaScript-отладчик и всё, что связано с JavaScript, Node и всем, что можно представить вообще вокруг JavaScript. Сейчас же я работаю в другой компании, которая называется Netflix. И сюда я пришёл делать очень простую вещь: у них есть свой собственный внутренний веб-движок со своим странным собственным JavaScript’ом. И ко всему этому делу необходимы свои собственные крутые инструменты, которые можно назвать «Chrome DevTools». И, соответственно, моя цель была — сделать эти инструменты.
Она до сих пор актуальна, я что-то делаю и отвечаю абсолютно за всё: за бэкенд этого дела, за то, чтобы фронтенд DevTools нормально работал. И при этом наша цель — работать таким образом, что я продолжаю контрибьютить в Chrome DevTools, апстримить все патчи, какие только можно. Чтобы не было так, что мы форкнемся, навсегда разойдёмся и потеряем результат работы моих классных коллег из Google. Так что я продолжаю делать то же самое, что и раньше — Chrome DevTools.
Дмитрий: Клёво.
Алексей Золотых: В твоей биографии на сайте HolyJS есть такая формулировка: «Возглавлял большинство попыток компании улучшить жизнь разработчиков, начиная с асинхронных стеков и заканчивая новым модным Query Objects». Во-первых, почему попыток? И во-вторых, можешь подробнее рассказать — это, наверное, больше про Google?
Алексей: Начнём со слова «попытки». Очень хороший вопрос. И у меня есть на него ответ. Изначально это было слово «efforts». Так как я последние несколько лет живу и работаю в Калифорнии, меня подвёл перевод. Почему я решил перевести слово «effort» как «попытка»? Наверное, это всё-таки не «попытка». Это, безусловно, были «попытки», потому что мы что-то пытались сделать, но это были успешные попытки, большую их часть мы завершали.
Но в то же самое время Query Objects — это было что-то маленькое, о чём можно почитать в Твиттере или на Медиуме, и это то, что мы доделали. А async debugging — это то, что нам нужно доделать в Chrome DevTools. Мы это начали делать, пытались несколько раз, потому что это нетривиальная вещь. Ты пробуешь одно решение — слушаешь пользователей, они приходят к тебе и говорят: «Ничего не понимаю, что здесь происходит, можете, пожалуйста, что-то с этим сделать?» Ты пробуешь по-другому, пытаешься сделать что-то ещё, и так, шаг за шагом что-то получается. Но важно сказать, что большинство попыток были успешными.
В компании Google я провёл большую часть своей разработческой жизни. Я пришёл туда когда-то стажёром. Это было ещё в замечательные времена, когда в Петербурге был офис компании Google. Придя туда, я был обречён заниматься Chrome DevTools: у меня не было другого выбора, потому что я пришёл стажёром в команду Chrome DevTools. Мне сказали: «Вот тебе очень простой стажёрский проект. У нас есть крутой API, который позволяет взять весь JavaScript-код, как-то его обработать, вернуть обратно и сказать Chrome, чтобы он вместо пришедшего нам JavaScript выполнил другой JavaScript».
У нас был такой API, и на его основе можно было построить AST-дерево. Я помню, что об AST-деревьях был отличный доклад на HolyJS. Надо было распарсить AST-дерево и заинструментировать код таким образом, чтобы померить время исполнения, а на самом деле написать инструментирующий профайлер. И это был такой интернский проект, он у меня всё ещё лежит где-то на GitHub. Он очень давно не работает в Chrome, потому что API, который он использовал, меня же самого попросили выпилить — его было сложно поддерживать. Мне было очень грустно в тот день, потому что это был API, на котором был построен весь проект — «удали его». И я его удалил. Из стажёров через три месяца я перешёл в инженеры — остался в Google и начал заниматься всем, что связано с JavaScript. Начинал с чего-то очень простого: мне надо было починить console.log(). А потом постепенно так получилось, что основная часть команды инструментов, связанная с JavaScript, покинула команду по некоторым причинам, и мне оставили на откуп практически весь JavaScript. В тот момент было очень страшно, но я собрался и постепенно начал что-то делать, что-то понимать.
В то же самое время развивался JavaScript, как мы знаем, там появились асинки, промисы. Сейчас у нас уже async/await, появились arrow function’ы во всех возможных фреймворках, поэтому нам понадобились inline breakpoint’ы (без них стало никак) — и многие такие маленькие улучшения я делал, делал, делал. Async-стеки вылились в большую работу, это async-модель, которая описывает асинхронность в JavaScript’е очень простым языком.
И так как нельзя работать в Chrome DevTools над фронтендом JavaScript и ничего не знать о движке V8, в процессе всей этой работы мне постепенно пришлось всё больше и больше контрибьютить в V8. У меня там очень много патчей. В какой-то момент мы перенесли бэкенд JavaScript из кода Chrome в код V8. Это, конечно, было логично сделать с самого начала, но исторически он был не там. В то самое время у нас появился Node, надо было как-то его поддерживать, и мы решили, что если мы умеем дебажить V8, а Node вроде бы использует V8, почему бы нам не сделать поддержку Node у нас? И мы это сделали, в этом проекте я был не самым главным, но я активно помогал тем, кто его делал. Этим всем я и занимался в Google около пяти лет.
Дмитрий: Что ты считаешь из этого самым крутым и сложным?
Алексей: Запоминается лучше всего почему-то последнее. И последним был интересный проект, который мы делали. Это сейчас в консоли Chrome DevTools, когда вы что-то печатаете, вы можете видеть вживую результат выполнения того, что вы печатаете. Если вам хочется потестировать новые фичи JavaScript (на тот момент это был BigInt), вы просто печатаете в консоли, сразу видите результат, и вам не надо нажимать «Enter» и засорять вашу консоль миллиардом результатов. И сделать это правильно — сложней, чем кажется. Нам было очень важно, чтобы при жадном выполнении всех ваших выражений мы не разрушали состояние вашей программы, иначе все наши пользователи очень сильно расстроились бы. И для того, чтобы это сделать, нам пришлось взять JavaScript, взять V8 и добавить в него такую возможность: выполнить любое выражение, но гарантировать, что оно не изменит состояние вашей программы. И это было сложно, долго и никто до нас этого не делал, нет больше подобных JavaScript’овых движков. Я не уверен, что вообще есть такие движки. Может быть, в Java есть (потому что в Java, как мы знаем, есть всё), но я не уверен. И на тот момент мы это сделали.
Это был очень долгий процесс, который вовлёк в себя много разных команд, потому что нам важно было не только выполнить без «побочных эффектов», но и гарантировать, что если вы вдруг начнёте выполнять бесконечный цикл while (true), то вы не подвесите всё на свете, потому что поток JavaScript всё-таки один. И это был отдельный effort: выяснилось, что код Chrome сам по себе не любит, когда в случайный момент времени JavaScript заканчивается, в таком случае он любит сказать: «М-ме…», — и крешнуться. Это пришлось починить. И это мы тоже сделали.
Проект этой работы вылился в то, что Google даже получил патент. Google патентует не для того, чтобы потом за вами гоняться, а, как и большинство других компаний (кроме старого Oracle, наверное), чтобы в случае чего защищаться, если вдруг к ним кто-то придёт и скажет: «Чуваки, вы сделали Google-поиск, это плохо, у нас есть патенты». И те чуваки будут почему-то одновременно делать JavaScript debugger. Google скажет: «А у нас вот здесь есть такой патент на JavaScript debugger». Ну, патентные адвокаты лучше знают, что там происходит, но мы запатентовали, это было весело. Google выдаёт маленький кусочек пазла, когда вы получаете патент. Он очень прикольный. И это было очень интересно, потому что никто это раньше не делал, и у нас получилось это сделать.
Дмитрий: А казалось бы, просто в консольке что-то выводится.
Алексей: Да-да, это всё очень «просто», конечно. Цитата чья-то была о том, что любая хорошо сделанная технология неотличима от магии.
Дмитрий: Ну да, интересно. А что из того, что очень хотелось сделать, не удалось сделать? Что-то ещё? Более мощное?
Алексей: Это очень опасный вопрос. Всегда хочется всё сделать, и никогда не хватает времени. Хотелось бы, конечно, доделать вещи, которые мы начали, но я не доделал. Это async-модель, и async debugging всё-таки надо было допилить, конечно же, и сделать её более очевидной для пользователя, сделать ещё некоторые шаги. Не уверен, что именно там делать, но из важного, что хотелось доделать: в V8 есть механизм, схожий с HotSwap в Java и с подобными технологиями, когда вы можете в вашей программе, которая прямо сейчас исполняется, взять кусочек кода и обновить наживую. Например, вы остановились на исключении и знаете, как это исправить, сразу исправляете прямо там, сохраняете файл, и всё дальше работает, а исключения как будто и не было — всё пофиксили вживую. Это очень крутой инструмент. Некоторые считают, что он может даже в некотором смысле заменять отладку, потому что вы постепенно пишете код маленькими кусочками, сразу видите, что происходит — отлаживать после этого практически не нужно.
И у нас очень давно, лет 9-10 назад, был код, который это делал. Он был написан немножко в другом мире, в другой реальности — там был другой V8, там не было всех этих Ignition, TurboFan и всего прочего. Я не уверен, что там на тот момент даже Crankshaft был, это предыдущий компилятор в V8. Ничего не было. И async/await тоже не было, конечно же. Код был очень старый, он использовал какие-то очень старые внутренние утилиты V8, которые поддерживали только для этого кода, потому что на тот момент никто не хотел разобраться в этом коде и его переписать.
В какой-то момент я сел и переписал его, и он стал меньше крэшиться. Но он до сих пор очень часто говорит, что не может отредактировать ваш код, потому что там, например, не хватает поддержки генераторов. Когда писали этот код, встречался один генератор на миллион строчек кода в JavaScript. А когда у нас появились async/await, каждая async/await-функция, на самом деле, сама по себе генератор. Поэтому, если вы попросите отредактировать код с async/await, вы разочаруетесь.
А так как это всё-таки инструменты для разработчиков и отладки, тут есть неприятная особенность: если при использовании инструмента он не работает два раза из десяти, им больше пользоваться не станут. И это очень хотелось бы доделать. Может быть, мы это доделаем, так как я сейчас, возможно, привнесу V8 на моё новое место работы и смогу за счёт этого продолжить работу над ним.
Дмитрий: Это могло бы работать исключительно во время отладки, или теоретически можно было бы и в каком-нибудь продакшне single page application менять частичку приложения?
Алексей: С точки зрения V8, в продакшне это менять проще, сложнее поменять, когда вы стоите на паузе. Если на паузе, то у вас есть текущий stack trace, который уже есть и исполняется. Надо как бы обновить этот код и заставить весь этот текущий стек, который ссылался на какие-то переменные в вашем коде, продолжить работу. А когда у вас просто продакшн, вы можете дождаться момента, когда JavaScript закончился (будем надеяться, что у вас там нет while (true)), и в этот момент всё незаметно заменить.
И это значительно проще, потому что можно просто заменить код, не нужно обновлять все ссылки. А основная сложность — это, конечно, заменить все ссылки, перезапустить все фреймы, перезапустить генераторы и так далее.
Алексей: У меня внезапно возник вопрос по поводу использования Chrome DevTools как IDE. Там есть такая функция, когда отредактировал JavaScript и можно его как-то привязать к файловой системе, и то же самое со стилями. И у меня к нему очень много вопросов, потому что он не работает. А я человек ленивый, я люблю в одном месте, например, поправить.
Алексей: Вопрос, видимо, в том, почему оно не работает. Важно сказать изначально, что Chrome DevTools никогда не были IDE, никогда не позиционировали себя как IDE. IDE — это проект другого масштаба, он требует других усилий и больше людей. Chrome DevTools строился сначала как инструмент, а потом как редактор. В отличие от IDE, которые появляются как редактор, а потом добавляют отладчик, плагинчики и так далее.
При этом мы понимали, что нашим пользователям было бы очень приятно отредактировать и сохранить, было несколько попыток это сделать — сейчас, наверное, вторая или третья попытка… Но всё упирается в то, что в вебе, с учётом существования всех этих webpack, компиляторов CSS и всего прочего, очень нетривиальной задачей является применить изменения обратно. Вы меняете код, который вы видите внутри странички, вам необходимо понять, откуда этот код вообще появился в вашей страничке и аккуратненько его применить изменение обратно.
Поэтому, с другой стороны, можно сказать, что можно просто сделать, чтобы работало для людей, у которых нет таких сложных конфигураций, но, к сожалению, это очень маленький процент наших пользователей. Сейчас у всех webpack, Babel и так далее. И они в одну сторону очень легко транспилируют и что-то делают, а чтобы в обратную сторону получить информацию — это проблема. Для CSS и для SASS это было сделано каким-то магическим образом, и иногда, кажется, оно работает, я не пользовался.
Изменится ли это в будущем, можно ещё спросить. Вы можете использовать Visual Studio Code либо вашу любимую IDE (WebStorm или ещё что-то), поредактировать там код, а Chrome DevTools попробует применить эти изменения вживую. Но на самом деле, у нас есть отдельный проект нашего фронтенда для Node, наверное, мы о нём ещё позже поговорим, там это работает чуть лучше, потому что, слава богу, в Node максимальный уровень транспиляции и компиляция TypeScript в JavaScript. И там уже сложно, но я всё ещё надеюсь, что на Node большая часть пакетов и модулей написана на чистом JavaScript без промежуточных шагов билда. Не ответил я на вопрос, но как мог.
Дмитрий: А как ты думаешь, как дальше будет развиваться Chrome DevTools в принципе? Каких самых крутых вещей от него ожидать?
Алексей: Это сложный вопрос. В какой-то момент на Google I/O появился человек, который сделал очередной удобный инструмент для дизайнеров. Это расширение для Chrome, к сожалению, не помню название. И оно добавляет прямо поверх вашей странички какие-то элементы, которые позволяют вам как дизайнеру проще всё редактировать и делать. И были идеи, что Chrome DevTools может быть более удобным инструментом для дизайнеров. Это и так уже достаточно удобный инструмент, который может, например, смотреть CSS и прочее, но всё ещё можно сделать значительно более идеальным и удобным. Например, более удобное редактирование flex-свойств и прочие маленькие улучшения.
И ещё есть важная часть работы над Chrome DevTools: проект очень большой, у него очень много пользователей и большой поток багов, которые каждый может зафайлить на сайте crbug.com. Их надо чинить, их много, и очень много времени уходит на то, чтобы просто сделать так, чтобы всё работало. Для отладки JavaScript live edit, о котором мы говорили, hotswap может быть хорошим следующим шагом дальше, но он может случиться, а может и нет, не знаю.
Алексей: Chrome DevTools, мне кажется, объективно самое навороченное программное обеспечение для помощи веб-разработчикам. Но есть же другие браузеры — Safari, Edge пока ещё есть, Firefox опять же. Есть какие-то инструменты, которые хотелось бы утянуть из других браузеров в Chrome DevTools? Есть что-то, что нравится, как клёво сделано?
Алексей: Разработчики Chrome DevTools регулярно смотрят на другие браузеры. Из интересного, что я там приметил в последнее время, помню, что в Safari была очень удобная консоль. Они очень красиво структурировали вывод в консоль, и добавили навигацию с помощью стрелочек по результатам. Вы можете там выбрать объект, нажать «вправо» — он раскроется. Это было чертовски удобно. В итоге сейчас эта фича есть в Chrome DevTools.
В Firefox из интересного в DevTool’ах, они, мне кажется, чуть лучше поддерживают визуальное редактирование всяких CSS-свойств — под этим я подразумеваю свойства типа flex и прочие, — они вам показывают грид прямо поверх странички, и можно всё это подвигать вверх-вниз. Это круто, у нас это частично есть, но не полностью. Firefox DevTools, я думаю, на данный момент имеет безусловно лучшую поддержку WebAssembly. Если вам почему-то приходится писать WebAssembly-код, то они значительно лучше нас, потому что у нас ничего не было полгода назад, сейчас я не проверял. Мне кажется, они в это инвестируют много сил.
Что до Safari… в каком-то смысле Chrome DevTools — это форк Web Inspector из Safari, поэтому всё самое лучшее, что у них было, мы забрали.
Важное вспомнил! Наверное, только в Firefox есть Time Travel Debugging. На Mac в Nightly-билдах Firefox’а вы можете побаловаться с Time Travel Debugging’ом. О нём я умолчал когда меня спрашивали про следующие большие шаги: звучит очень круто, очень монументально — до сих пор не верю в то, что это очень полезно. Личная точка зрения. Но у них он есть, вы можете попробовать, если вам поможет — это будет новый интересный инструмент.
Дмитрий: Вот касаемо отдельных инструментов. Мои бывшие коллеги меня бы не простили, если бы я не спросил про одну вещь, которая нам была очень-очень-очень нужна. Я даже не помню название, но был очень крутой (с точки зрения идеи и частично с точки зрения реализации) инструмент, который показывал композитные слои, которые получились от CSS. Но если с ним начинал играться, то всё очень-очень сильно умирало, вплоть до крешей.
По своему опыту могу сказать, что бывает очень важно на больших проектах сесть с такой штукой и отловить действительно жёсткие проблемы, когда композитные слои друг на друга понаезжали и всё получилось очень плохо. Когда вот эта штука вернётся и будет работать хорошо и стабильно? И вообще, к кому идти за ней? Может быть, самому можно по этому поводу чуть-чуть попробовать подпилить?
Алексей: Начну с конца. К кому идти? Это, опять же, crbug.com, там завести feature request. Все эти feature request’ы, безусловно, читают: не факт, что делают, но читают. И это иногда оказывает некоторое влияние на то, что мы делаем дальше. Можно написать в твиттере: есть аккаунт Chrome DevTools, есть аккаунты всяких инженеров из Chrome DevTools, например, Пола Айриша. Пишите, жалуйтесь и, надеюсь, вы будете услышаны.
Попилить самому такую вещь, как композитные слои, можно, но очень высокий порог входа — вам придётся потратить бесконечное количество времени, чтобы понять, как это работает в Chrome. Если вы очень серьёзно настроены, то это можно осилить, люди будут счастливы, и команда Chrome DevTools будет счастлива, но это сложно. Потому что, во-первых, вам нужно очень мощное железо, чтобы иметь возможность просто собрать Chrome и поиграть с ним. А во-вторых, проект всё-таки огромный, и чтобы хотя бы понять, где копать, без какого-то инсайда, без человека, который вам поможет… Не знаю, очень круто, если у вас получится.
Дмитрий: И потом возьмут в Google? :)
Алексей: Если вы потом захотите пойти в Google и добавите это в резюме, безусловно, это будет хорошим подспорьем. У нас был когда-то инструмент, назывался layers panel, по-моему. Его судьба была сложная, потому что требовалось много сил для поддержки, а количество пользователей исторически было низким. Потому что это очень продвинутый инструмент, безусловно, нужный, но думаю, что большая часть людей с композитными слоями не сталкивалась. По крайней мере, я не сталкивался, тут лёгкая предвзятость.
Куда его спрятали? Нажмите Cmd/Ctrl + Shift + P, наберите Show layers — этот инструмент может помочь. Discoverability некоторых фич в Chrome DevTools — это то, что, безусловно, требует большой работы и исправлений. Это где-то есть, это всё ещё не удалили. Но могут удалить в любой момент, потому что надо как-то эту фичу переделать. Она крутая, но всегда хочется делать фичи, которые крутые, полезные и ими может пользоваться большое количество людей.
Дмитрий: У этой штуки такой прикол, что, когда она тебе становится нужна, это уже прям совсем вилы.
Алексей: Это я согласен.
Дмитрий: Например, когда у тебя случаются проблемы на главной странице какой-нибудь маленькой социальной сети. Там такой инструментарий нужен. Да, я согласен, проблема не распространённая.
Алексей: Ты можешь рассказать об этом на HolyJS. Что сталкивался с такой проблемой и пытался её решить.
Дмитрий: Я чуть-чуть сбоку, так сказать, из-за плеча смотрел и чувствовал, что происходит. Ну, сам инструмент тоже чуть-чуть трогал. Это как раз про то, что ты говорил: один раз что-то упадёт, и ты в это больше не очень-то веришь. Как-то так и было.
Алексей: Ты упомянул, что если я захочу что-то разрабатывать в Chrome, то, скорее всего, у меня не получится. По двум причинам. Первая — железо, у меня не такой уж мощный ноутбук. И второе — это очень высокий порог входа. Но всё-таки что-то можно сделать, чтобы помочь команде?
Алексей: Не всё так плохо. Я имел в виду именно про композитные слои, вся эта композитная логика в Chrome очень сложная. Но если вы хотите сделать что-то, что проще с точки зрения кода Chrome, это может получиться.
Если вы откроете на GitHub проект Chrome DevTools (это зеркало нашего фронтенда), там есть небольшая инструкция, как вы можете локально собрать DevTool’овый фронтенд без необходимости собирать Chrome, что сэкономит вам безумные часы времени на вашем компьютере. И, соответственно, вы можете сделать что-то в Chrome DevTools, такие патчи вообще очень приветствуются. Иногда бывает, что сначала фиксят какие-то простые баги, что-то, что вам мешает и раздражает. Либо вы хотите добавить что-то простое. Например, не так давно человек добавил редактор cookies.
И подобные вещи можно делать, DevTool’овый фронтенд, с этой точки зрения, относительно простой. Он не использует никакие фреймворки, он написан на JavaScript’е, на таком очень ванильном базовом CSS, и HTML там тоже практически нет. Такой настоящий single-page application. Единственная проблема, что какой-то фреймворк там всё-таки есть, и он свой собственный, доморощенный, поэтому придётся потратить некоторое время.
Но в принципе лучший подход — смотреть на что-то подобное тому, что вы хотите сделать (например, такая же кнопочка где-то есть), искать это в коде Chrome, смотреть, как это сделано, и творчески перерабатывать. Есть сайт cs.chromium.org, и на нём удобный поиск по коду.
Среди наших багов, к сожалению, нет раздела «хороший первый баг», но в других компонентах Chrome есть такая вещь, как good first bug — надо поискать такой лейбл найдёте некоторые баги, которые считаются хорошими для только что пришедших разработчиков.
Альтернативная возможность, которая у вас есть, если вы хотите поработать над JavaScript — V8 проект чуть поменьше, чем весь Chrome. Я не говорю, что попроще, он тоже очень сложный, потому что это виртуальная машина. Но там вы тоже можете поделать что-то для дебаггинга и, когда вы будете делать что-то там, у вас сразу открывается возможность сразу сделать что-то не только для Chrome, но и для Node. Либо наоборот, если вас что-то раздражает в поддержке Node, вы делаете это для Node, а потом портируете в Chrome. И, соответственно, сразу делаете счастливыми в два раза больше пользователей.
Поэтому можно начинать с этого, пробовать в V8 что-то чинить, пробовать что-то делать в DevTool’овом фронтенде отдельно. Если вам очень сильно хочется закопаться в Chrome, это тоже можно делать, но каким-то образом вам нужно найти очень быстрый компьютер, иначе вы просто будете 15 часов собирать Chrome.
Дмитрий: А на каких машинах вообще работают те разработчики, которые пишут Chrome?
Алексей: На достаточно уникальных, Lenovo делает специальные рабочие станции, которые в Google специально для инженеров Chrome отдельно добиваются оперативной памятью и всем прочим. Там стоят последние Xeon, 64 или 128 ядер — это бесконечное безумие. Я помню, на процессоре кеш первого уровня был 32 мегабайта. И хотя я молод, но на моём первом компьютере оперативной памяти было меньше. И я помню, что GTA 2 отлично работала на моём первом компьютере.
В общем, там какое-то безумие творится. И эти машины стоят каких-то огромных денег — компания Google позволяет вам заказывать железо и не платить за него, но когда вы заказываете, Google всегда показывает, сколько он на вас потратил. Там абсолютно безумные числа, и это крайне производительные машины, у последнего поколения этих машин получается интересный профит. У Chrome есть распределённый компилятор для C++, но иногда компилировать локально на таком компьютере оказывается быстрее. То есть распределённость даром не нужна, когда у вас есть под боком такая рабочая станция.
Алексей: Зато из дома не поработаешь.
Алексей: Дома я справлялся с этим тем, что по SSH подключался к своей машине и код туда-сюда гонял, не помню, с помощью чего. У меня был какой-то плагин, который позволяет удобно синхронизировать код между разными машинами по SSH. И я писал на своём Mac, потом заходил в терминал и запускал команду: «Скомпилируй этот код и прогони тесты». На Mac’е, конечно, люди собирают, это как-то работает, с распределёнными компиляторами это всё ещё работает более-менее, но распределённый компилятор закрытый, он не опенсорс, к сожалению.
Дмитрий: Сурово. Интересно, такой комп дороже самолёта?
Алексей: Не-не, сильно дешевле самолёта. Я недавно смотрел стоимость Cessna, это такой очень популярный самолёт, и он даже подержанный в 17 раз дороже. Всего плюс-минус 17 компьютеров команды Chrome DevTools.
Дмитрий: Окей, давай к чему-то, может быть, попроще. Точнее, пореальнее, с точки зрения работы. По-моему, недавно ты презентовал ndb (или какую-то его часть), ты один из его контрибьюторов. Ты уже упоминал, что, разрабатывая Chrome DevTools, приходится чуть-чуть затрагивать V8 и Node. Как ты оказался рядом с ndb, и почему ты решил сделать что-то для Node? Это была какая-то рабочая задача или личная инициатива?
Алексей: ndb — проект с очень тяжёлой судьбой. У нас в Chrome DevTools поддержка Node появилась достаточно давно. И она была изначально припрятана: Node запускался и говорил вам перейти на магический URL, вы переходили, открывался фронтенд. Потом появился dedicated — это отдельный фронтенд для Node. И вы можете сейчас зайти на chrome://inspect, там будет такая синяя ссылка «open dedicated frontend», что-то в духе этого. Вы её открываете, и этот фронтенд автоматически коннектится ко всем нодам, которые вы запускаете локально. Это как-то работало, но пользователей было мало, и было непонятно, почему. И возникла идея внутри команды, что, наверное, это слишком сложно — лишние шаги. И value, которое мы приносим пользователям по сравнению с теми шагами, которые надо преодолеть, не соответствует.
Поэтому было решено увеличить то, что мы даём пользователям, и уменьшить порог входа. И в этом случае решили сделать что-то, что вы можете установить с помощью npm — «npm install -g ndb» — и чтобы это просто был дебаггер. Изначально он требовал скачивания всего Chrome, и это был достаточно большой пакет. На данный момент он работает с Chrome, который у вас установлен из коробки. И поэтому там 2,6 мегабайта кода Chrome DevTools вместе с картинками. Вы устанавливаете и запускаете этот фронтенд. Это с точки зрения простоты установки.
Помимо того, хотелось привнести какое-то value: до этого нельзя было дебажить child-процессы, что было большой проблемой для людей, у которых они есть. И ndb решил эту проблему.
Проект изначально позиционировался так, что это будет такой очень дружественный к экосистеме Node дебаггер для Node. И в отзывах, которые мне больше всего понравились, люди были счастливы от того, что кто-то начал делать дебаггер для Node, не начиная с редактора, а начиная с тулов.
Потому что всё-таки есть Visual Studio Code, который позволяет дебажить Node. И он достаточно неплох. Но это всё-таки IDE и это страшный комбайн, который переваривает ещё и Python, и всё остальное, что только можно. А тут удобный инструмент заточенный для Node. Я склонен думать так: Chrome DevTools — инструменты для веба, ndb — инструменты для Node.
Сделали, запустили, хотели незаметно запустить на Google Chrome Labs — у нас есть специальный GitHub-репозиторий для таких экспериментальных проектов, которые вообще никому не должны быть интересны. Думали, незаметненько там запустим, а в итоге это оказалось через 15 минут на Hacker News и собрало какое-то бесконечное число звёзд. Несмотря на то, что ничего не работало (и до сих пор не работает, я должен это признать), люди как-то лайкают и им нравится. И иногда это работает и работает неплохо.
Проект оказался с тяжёлой судьбой, потому что выяснилось, что писать на Node сложно. Удивительным образом выяснилось, что писать на Node на Windows, Linux и Mac, когда вам надо активно взаимодействовать с файловой системой — очень сложно, файловая система медленная, файловая система полна всяких странных ограничений.
Ну не странных, наверное, вполне логично, что вы не можете подписываться на изменения в больше, чем n файлов. Но всё-таки там это реализовано таким образом, что в этот момент оно просто падает, нет никакой возможности быть более гибким. И ещё есть стандартные проблемы с тем, что в environment-переменных Windows нельзя передавать пробелы, а в Linux — можно, и так далее. Там началось веселье. И так как ещё не было под рукой Windows-машины, это превратилось в какой-то кошмар.
Мы победили большую часть багов, но их всё ещё очень много. Проектом кто-то пользуется, я иногда им пользуюсь, и мне очень нравится, когда он работает. Надо похвалить то, что сам сделал. А по поводу того, как это всё родилось — просто родилась внутри команды идея, что надо сделать лучше поддержку Node, и выяснилось, что на тот момент я был лучшим человеком, который может это сделать. Я, конечно, контрибьютор в этот проект, но мне кажется, я единственный контрибьютор в этот проект на данный момент. Но самый главный результат ndb, на самом деле, это Carlo. Carlo — это очень своеобразный ответ Electron. На данный момент он очень далёк от Electron по возможностям и медленнее его, но это некий взгляд на то, как можно сделать Electron иначе.
Дмитрий: Это та штука от Google, которая использует твой текущий Chrome?
Алексей: Да, она появилась из ndb. Там это сделали впервые и, соответственно, код из ndb.
Дмитрий: Прикольно, инсайды. А чтобы комфортно работать над Chrome DevTools, делать штуки, которые ты делал, какой нужен набор скиллов? И, вообще, как попасть в такую команду?
Алексей: Как работать в Chrome DevTools? Есть путь стажёром. Он такой, с лайфхаком, потому что, когда я пришёл в команду Chrome DevTools, это был первый день, когда я написал первую строчку на JavaScript. До этого я никогда не видел язык и был, видимо, из той категории людей, которые думают, что вот есть Java, а в JavaScript, наверное, что-то похожее должно быть. Ну ладно, всё не так плохо было.
А правильный набор скиллов: вы должны знать веб-стек, конечно же. Вы должны быть веб-девелопером. Но помимо этого, вы должны быть очень специфическим специалистом, и вам надо знать C++. Потому что хороший, крепкий инженер Chrome DevTools обычно владеет и бэкендом, и фронтендом. У нас есть, конечно, и чисто фронтенд-разработчики и чисто бэкенд-разработчики, но всегда лучше, когды вы знаете и то, и другое. Ваши шансы попасть в команду Chrome DevTools значительно выше, если вы почему-то знаете и C++, и веб-стек.
Я значительно лучше знаю C++, сейчас я знаю JavaScript, но вот CSS… Я помню ещё доклад с HolyJS, где говорилось, что CSS — это технология, которую учить не обязательно, она сама выучится. Но, к сожалению, не учится! Неожиданно.
Соответственно, если вы знаете и C++, и веб-стек, вас возьмут. Если вы знаете что-то одно, вас, скорее всего, рассмотрят, если вы хотите. Не уверен, что есть вакансии именно на careers.google.com, можно посмотреть, может, там есть Chrome DevTools, но, скорее всего, там есть software engineer-вакансия, как обычно. Можете податься на обычного software-инженера и потом, когда будете говорить с рекрутером, сказать: «Я всю жизнь мечтал писать Chrome DevTools».
Дмитрий: На каком уровне нужно знать С++? Если вдруг всё-таки захотелось.
Алексей: Хороший вопрос по поводу уровня плюсов. Ну, конечно же, метапрограммирование на шаблонах — это, возможно, не очень ценный навык, это не нужно знать. Обычно это зло: в популярном промышленном коде большого опенсорс-проекта люди стараются этого избегать, просто потому что порог вхождения туда очень высок, а хочется, чтобы как можно больше людей могли что-то писать.
Соответственно, вам надо знать C++ на каком-то базовом уровне, классы понимать и так далее. Чуть лучше, чем «Hello, world!», в общем. И стандартную библиотеку знать не обязательно, потому что вам придётся выучить стандартную библиотеку, которая есть в Chrome. Постепенно фичи от новых C++ приходят в код Chrome, но он всё ещё C++ 11, а новые фичи мы постепенно адоптим. Нет ничего вроде требования знать Boost или конкретный фреймворк.
Дмитрий: Ещё по поводу навыков. Мы знаем, что ты закончил серьёзную питерскую физико-математическую школу 239, насколько это помогает и насколько это надо? Или всё-таки там задачи в основном логического уровня? Как мы обычно программируем single page application.
Алексей: Мне кажется, что после того, как вы переведёте это на английский, меня уволят, но я вынужден это сказать. В твиттере регулярно появляются споры на тему того, нужен computer science-бэкграунд или не нужен. Регулярно люди делятся на два лагеря: одни говорят — без этого никак, а другие говорят — да нафиг это нужно, тратить долгие годы.
Безусловно, без этого можно жить и вы выживете. В Google попасть будет сложнее, потому что собеседования в Google настроены на людей после университета. И все эти алгоритмические задачки, которые вам большую часть жизни не нужны, у вас спросят на собеседовании. Вы можете их подготовить отдельно, конечно. То есть computer science-бэкграунд вам очень сильно поможет пройти собеседование, а в работе…
Вот 239, на самом деле, больше была не про математику, а в принципе про подход к обучению, мне кажется, и это феноменальный опыт и там научили учиться. И заложили очень хорошие фундаментальные знания, которые важны, на их основании вы можете быстрее учить что-то новое. У вас нет такого вопроса, что вот JavaScript — как его учить? Это не проблема. Вы знаете, что вы знаете a, b и c, в каждом из них есть часть JavaScript, и вы понимаете, что JavaScript это просто микс других концептов вместе. JavaScript — это страшный микс, на самом деле.
Соответственно, фундаментальное образование и CS-бэкграунд позволяют вам быстрее учить всё новое, лучше понимать и ориентироваться. В принципе, когда вам нужно поговорить о чём-то с коллегами, вам проще описать то, о чём вы говорите. Вы можете понять то, что хочет до вас донести коллега, потому что вы знаете, о чём он говорит, более-менее. Поэтому это круто иметь, если у вас есть такая возможность, пойти получить хорошее computer science-образование — я только за, я считаю, что это must have, без этого никак. Но, безусловно, я знаю примеры, очень много успешных разработчиков, у которых его нет и они достаточно успешны. Но это люди, которые просто готовы сами очень серьёзно учиться.
Дмитрий: Получается, когда ты пишешь какую-нибудь отладку асинхронного JavaScript, там же всё-таки, наверное, присутствуют какие-то сложные алгоритмы и структуры данных?
Алексей: Да. Это всё присутствует, конечно, но мне кажется, что когда вам что-то нужно, вы, безусловно, можете найти на Stack Overflow, какую именно структуру данных вам нужно использовать, почитать о ней и за пару дней разобраться. Просто если вы эту структуру проходили в университете, вам не нужна эта пара дней, вы просто сразу пишете. А так да, когда async-стеки писали, нам нужно было свой маленький garbage collector написать.
Дмитрий: Прикольно. Такой вопрос: а как ты сам учишься? Грубо говоря, что читаешь, про что читаешь? Что смотришь? Именно для образования.
Алексей: Хороший вопрос. В основном сейчас я пытаюсь закрывать некоторые пробелы, CSS и так далее. На самом деле, у меня нет такого ресурса, который я могу всем посоветовать. Ресурс — это Google-поиск, просто ищу что-то и пытаюсь читать. Это очень неэффективный подход, я твёрдо уверен, что есть хорошие ресурсы, которые вы открываете и сразу находите то, что нужно, и не надо перелопачивать много информации. Так получается, что я не могу сказать, что я активно уделяю этому время. Я иногда смотрю разные видео лекции.
Последнее, что я смотрел — очередной курс про интеллект. Там выходец из постсоветского пространства читает курс в Беркли как профессор. Очень интересно рассказывает обо всём современном в состоянии искусственного интеллекта, если вы слышали о победе в го, обо всех этих успехах DeepMind в игре в StarCraft (прим. ред.: хотя игры с геймерами Zest, soO и Stats мы не нашли) и так далее — это модный нынче Reinforcement Machine Learning. Сейчас специалисты по Reinforcement Machine Learning уже пошли писать комментарии. Если бы это был бы youtube, там бы уже было 15 комментариев, что я не понимаю, о чём говорю.
В последнее время так получается, что просто работа-работа-работа, и в работе постоянно нужно какие-то маленькие нюансы выучить, понять и осознать, и ты их быстро учишь. Такого, что я трачу два часа в неделю на самообразование, у меня нет. Играю на гитаре, но это никак не помогает мне писать на CSS.
Алексей: Откуда ты знаешь?
Алексей: Я не знаю, мне так кажется. На самом деле, есть разные теории. Говорят, что игра на гитаре позволяет быстрее учить другие языки. Зная лучше английский, я могу читать больше статей и слушать больше подкастов и YouTube — и в итоге быстрее учить CSS. Так что, возможно, связь есть. Но так, чтобы прямо учиться программировать, играя на гитаре — нет.
Дмитрий: Прикольно. А что ты думаешь про митапы и воркшопы в таком разрезе? Насколько они полезны?
Алексей: Чтобы иметь хорошую точку зрения, нужно поучаствовать хотя бы больше, чем один раз. Я участвовал однажды в Node.js, когда мы помогали людям писать базовый код на Node. И мне кажется, что прикольно. По крайней мере, как всегда, когда вы чему-то учитесь или что-то делаете, самое важное — это ваша целеустремлённость, на самом деле. Безусловно, будет трудно, вы будете что-то не понимать и не понимать, что вы здесь делаете, но вам постоянно необходимо преодолевать непонимание и кидаться в эту гущу непонятных знаний и слов. Это сложно.
И поэтому мне кажется, что такие базовые митапы и воркшопы для людей — «давайте законтрибьютим первый патч в Node.js» — полезны, потому что вот этот первый шаг, мне кажется, для людей, которые никогда ничего не контрибьютили в Node.js, очень сложный. И на таком базовом уровне, мне кажется, это классно, потому что вы помогаете им преодолеть этот первый порог входа. Потом они столкнутся ещё с пятнадцатью другими порогами, и вам надо помочь им там тоже.
Дмитрий: Переходим к последним вопросам. Наверное, ты был на большом количестве конференций. Без чего, по-твоему, конференция не может быть хорошей? Кто-то считает, что конференции только для нетворкинга, кто-то — только как доклады, это совсем крайние точки зрения. А что для тебя максимально важно?
Алексей: Мне кажется, что очень важной бывает организационная часть. Я очень люблю те конференции, когда всё организовано настолько хорошо, что я не вспоминаю о существовании организационной части. Потому что я пару раз был на конференциях, где проектор не работал, ещё что-то не работало. Это всегда очень сильно выбивает из колеи, потому что если вы хотите что-то рассказывать, в моём случае я всегда очень сильно нервничаю и переживаю, а если ещё что-то не работает, мне хочется прямо там сразу же и пристрелить кого-нибудь. Поэтому организационная часть мне кажется очень важной. Организационная часть — это как DevTools: когда они работают — всё хорошо, никто никогда о ней не вспоминает и не замечает, а вот когда они не работают — это пожар.
И всё остальное тоже важно. Хорошо бы иметь крутые доклады, хорошо отобранные и разнообразные по тематике, потому что всегда приходят достаточно разные люди. Потому что, когда происходит нетворкинг, вы хотите общаться не только с людьми, которые пишут JavaScript-отладчик, а с людьми, которые пишут всё на свете. И за счёт обмена опытом и разных перспектив на проблемы получать новые знания. Соответственно, разнообразие людей, организация, крутые доклады — стандартный набор.
Очень круто, когда на конференции есть доклады на тему общих жизненных вопросов («не знаю, как CSS выучить наконец-то») и одновременно технических. Бывают конференции, на которых есть сильный уклон в жизненное (diversity, как нам выучить CSS и так далее), но нет технических докладов. И слушаешь подряд три доклада на такие абстрактные темы, они важные для индустрии, но технической части не хватает. Всегда нужен баланс. Вывод из этого — очень люблю сбалансированные конференции. Но баланс — это вещь в восприятии очень персональная и личная, поэтому оставьте организацию. Организация — вещь безусловная.
Дмитрий: И совсем финалочка: что ты ожидаешь от HolyJS?
Алексей: Я очень жду HolyJS, потому что в мае в Петербурге всегда очень здорово. Я жду, как всегда, классных докладов. Я жду, когда я снова встречусь со всеми этими классными докладчиками, которых я видел год назад, и жду встречи со всеми этими классными организаторами.
Дмитрий: Политкорректность не нужна, если что...
Алексей: Подготовить хороший доклад, на самом деле. Для меня самое важное — подготовить хороший доклад. Иначе волнение сильное появляется. Очень жду. Очень люблю HolyJS именно в Петербурге, потому что очень крутая конференция и ещё Петербург в мае, это лучший город на земле, мне кажется. Извините, пожалуйста, я просто оттуда. И в мае нету дождя, солнце, прекрасная погода, мосты разводят, белые ночи почти начались, а ещё такая классная конференция — идеальный момент. Очень политкорректное интервью. Что-то я перестарался в этот раз.
Доклад «Протокол Chrome DevTools» (и не только его) можно увидеть в бесплатной трансляции HolyJS, куда попадают доклады из первого зала 24 мая. После окончания трансляции YouTube будет рендерить запись, и временно будет доступна только часть дня, но позднее она снова станет доступна целиком.
