“You need to know both the web stack and C ++”: an interview with Alexei Kozyatinsky about the development of Chrome DevTools and not only
How to develop using Chrome DevTools, everyone knows. And what does the development of Chrome DevTools themselves look like? Alexei Kozyatinsky previously worked at Google and did just that, and now he has moved to Netflix, but he has not gone far from his previous activities.
What exactly is he doing now? How realistic is it for an ordinary non-Google developer to copy something useful in DevTools? Which computers do Chrome engineers use?
We are currently hosting the HolyJS 2019 Piter conference, where Alexey has already made a new report, “Chrome DevTools Protocol” (the recording can be seen in the free broadcast ). And on this occasion, he was questioned in detail by two members of the HolyJS program committee: Dmitry DmitryMakhnev Makhnev andAlexey zolotyh Zolotykh .
Dmitry Makhnev: Tell me a little about yourself. Where, how, where, what are you doing now?
Alexei Kozyatinsky: I'll be back a bit and tell you that Chrome DevTools at Google has been working for more than four years. Basically, I did a JavaScript debugger and everything related to JavaScript, Node and everything that can be imagined around JavaScript in general. Now I work for another company called Netflix. And here I came to do a very simple thing: they have their own internal web engine with their own strange JavaScript. And the whole thing needs its own cool tools, which can be called "Chrome DevTools." And, accordingly, my goal was to make these tools.
It is still relevant, I do something and am absolutely responsible for everything: for the backend of this business, for the DevTools frontend to work normally. And at the same time, our goal is to work in such a way that I continue to smuggle in Chrome DevTools, to upgrade all the patches that are possible. So that it would not be that we fork, we will forever disperse and lose the result of the work of my cool colleagues from Google. So I continue to do the same as before - Chrome DevTools.
Dmitry: Cool.
Alexey Zolotykh: In your biographyHolyJS website has the following wording: “He led most of the company's attempts to improve the lives of developers, starting with asynchronous stacks and ending with the new fashionable Query Objects.” First, why try? And secondly, can you tell us more - is this probably more about Google?
Alexei: Let's start with the word “attempt”. Very good question. And I have an answer to it. This was originally the word "efforts." Since I have been living and working in California for the past few years, a translation failed me. Why did I decide to translate the word “effort” as “attempt”? Perhaps this is still not an “attempt”. Of course, these were “attempts”, because we tried to do something, but these were successful attempts, we completed most of them.
But at the same time, Query Objects - it was something small that can be read on Twitter or on the Medium, and this is what we have completed. And async debugging is what we need to complete in Chrome DevTools. We started to do this, tried several times, because this is not a trivial thing. You try one solution - listen to users, they come to you and say: “I don’t understand what is happening here, can you please do something about it?” You try differently, try to do something else, and so, step by step, something happens. But it is important to say that most attempts were successful.
At Google, I spent most of my development life. I came there once as an intern. It was back in wonderful times when there was a Google office in St. Petersburg. Arriving there, I was doomed to engage in Chrome DevTools: I had no other choice, because I came as an intern to the Chrome DevTools team. I was told: “Here is a very simple intern project. We have a cool API that allows us to take all the JavaScript code, somehow process it, return it back and tell Chrome to execute another JavaScript instead of the JavaScript that came to us. ”
We had such an API, and on its basis it was possible to build an AST tree. I remember that there was a great talk about AST treeson HolyJS. It was necessary to parse the AST-tree and instruct the code in such a way as to measure the execution time, and actually write a tooling profiler. And it was such an internet project, I still have it somewhere on GitHub. It has not been working in Chrome for a very long time, because the API that it used was asked to cut it out myself - it was difficult to maintain. I was very sad that day, because it was the API on which the entire project was built - “delete it”. And I deleted it. After three months, I went from interns to engineers - I stayed with Google and started doing everything related to JavaScript. Started with something very simple: I had to fix console.log (). And then it gradually happened that the main part of the JavaScript-related tool team left the team for some reason, and I was left with almost all of the JavaScript. At that moment it was very scary, but I got ready and gradually began to do something, to understand something.
At the same time JavaScript developed, as we know, asinks, promises appeared there. Now we already have async / await, arrow functions appeared in all possible frameworks, so we needed inline breakpoints (there were no way without them) - and I did, did, did many of these small improvements. Async stacks turned out to be a lot of work, this is an async model that describes async in JavaScript in a very simple language.
And since you can’t work in Chrome DevTools on the JavaScript frontend and know nothing about the V8 engine, in the course of all this work, I gradually had to smuggle more and more into V8. I have a lot of patches there. At some point, we moved the JavaScript backend from Chrome code to V8 code. This, of course, was logical to do from the very beginning, but historically he was not there. At the same time, Node came to us, we had to somehow support it, and we decided that if we can debug V8, and Node seems to use V8, why don't we make Node support with us? And we did it, in this project I was not the most important, but I actively helped those who did it. I’ve been doing this all on Google for about five years.
Dmitry: What do you consider the coolest and most difficult of these?
Alexei:For some reason, the last is remembered best. And the last was an interesting project that we did. This is now in the Chrome DevTools console, when you type, you can see the live result of doing what you type. If you want to test new JavaScript features (at that time it was BigInt), you simply print in the console, immediately see the result, and you do not need to press “Enter” and clog your console with a billion results. And doing it right is harder than it sounds. It was very important for us that with the greedy execution of all your expressions, we would not destroy the state of your program, otherwise all our users would be very upset. And in order to do this, we had to take JavaScript, take V8 and add the ability to it: execute any expression, but guarantee that it will not change the state of your program. And it was difficult, for a long time and no one has done it before us, there are no more such JavaScript engines. I’m not sure that there are such engines at all. Maybe in Java there is (because in Java, as we know, everything is there), but I'm not sure. And at that moment we did it.
It was a very long process, which involved many different teams, because it was important for us not only to execute without "side effects", but also to ensure that if you suddenly start to run an endless while (true) loop, then you will not suspend everything in the world, because the JavaScript stream is still the same. And this was a separate effort: it turned out that the Chrome code itself doesn’t like when JavaScript ends at a random moment in time, in which case it likes to say: “Mm ...” and crash. It had to be fixed. And we did it too.
The project of this work resulted in Google even getting a patent. Google patented not to chase after you, but, like most other companies (except the old Oracle, probably), to protect yourself if something happens if someone comes to them and says: “Dudes, you made Google “Search, this is bad, we have patents.” And for some reason, those dudes will do JavaScript debugger at the same time. Google will say: "And here we have such a patent for JavaScript debugger." Well, patent attorneys know better what is going on there, but we patented it, it was fun. Google gives out a small piece of the puzzle when you get a patent. He is very cool. And it was very interesting, because no one had done this before, and we managed to do it.
Dmitry: And it would seem that something is simply displayed in the console.
Alexei: Yes, yes, it's all very "simple", of course. Someone’s quote was that any well-made technology is indistinguishable from magic.
Dmitry: Well, yes, interesting. And what of what I really wanted to do, could not be done? Something else? More powerful?
Alexei: This is a very dangerous question. You always want to do everything, and there is never enough time. Of course, I would like to finish the things that we started, but I did not finish it. This is an async model, and async debugging still had to be completed, of course, and made it more obvious to the user, to take some more steps. I'm not sure what to do there, but from the important thing I wanted to finish: in V8 there is a mechanism similar to HotSwapin Java and with similar technologies, when you can take a piece of code in your program that is currently executing and update it. For example, you settled on an exception and know how to fix it, immediately fix it right there, save the file, and everything works farther, and as if there were no exceptions - everything was fixed live. This is a very cool tool. Some people think that it can even in some sense replace debugging, because you gradually write the code in small pieces, you immediately see what happens - there is practically no need to debug after that.
And for a very long time, about 9-10 years ago, we had a code that did this. It was written a little in another world, in a different reality - there was a different V8, there were not all of these Ignition, TurboFan and everything else. I'm not sure that at that time even Crankshaft was there, it is the previous compiler in V8. There was nothing. And async / await wasn't there either, of course. The code was very old, it used some very old internal V8 utilities that supported only for this code, because at that time no one wanted to understand this code and rewrite it.
At some point, I sat down and rewrote it, and it began to crash less. But he still very often says that he can’t edit your code, because, for example, there is not enough support for generators. When writing this code, there was one generator per million lines of code in JavaScript. And when we got async / await, each async / await function is actually a generator in itself. Therefore, if you ask to edit the code with async / await, you will be disappointed.
And since these are still tools for developers and debugging, there is an unpleasant feature: if they do not work twice out of ten when using the tool, they won’t use it anymore. And I would very much like to finish it. Maybe we’ll finish it, because now I’ll probably bring V8 to my new place of work and due to this I can continue to work on it.
Dmitry: Could this work exclusively during debugging, or could theoretically change a part of the application in some single page application production?
Alexei:From the point of view of V8, in production it is easier to change, more difficult to change when you are paused. If it is paused, then you have the current stack trace, which is already running. It is necessary to update this code and force all this current stack, which referred to some variables in your code, to continue working. And when you just have production, you can wait for the moment when JavaScript is over (let's hope that you don't have while (true) there), and at that moment everything is imperceptibly replaced.
And it is much simpler, because you can simply replace the code, you do not need to update all the links. And the main difficulty is, of course, replacing all links, restarting all frames, restarting generators, and so on.
Alex: I suddenly had a question about using Chrome DevTools as an IDE. There is such a function when you edited JavaScript and you can somehow bind it to the file system, and the same thing with styles. And I have a lot of questions for him, because it does not work. And I'm a lazy person, I like to fix it in one place, for example.
Alexei: The question, apparently, is why it does not work. It is important to say initially that Chrome DevTools were never an IDE, they never positioned themselves as an IDE. The IDE is a project of a different scale, it requires other efforts and more people. Chrome DevTools was built first as a tool, and then as an editor. Unlike IDEs, which appear as an editor, and then add a debugger, plug-ins, and so on.
At the same time, we understood that it would be very pleasant for our users to edit and save, there were several attempts to do this - now, probably, the second or third attempt ... But it all comes down to the fact that on the web, taking into account the existence of all these webpack CSS compilers and everything else, a very non-trivial task is to apply the changes back. You change the code that you see inside the page, you need to understand where this code came from in your page and carefully apply the change back.
Therefore, on the other hand, we can say that we can simply do it to work for people who do not have such complex configurations, but, unfortunately, this is a very small percentage of our users. Now everyone has webpack, Babel and so on. And they easily transpose and do something in one direction, but to get information in the opposite direction is a problem. For CSS and for SASS, this was done in some magical way, and sometimes it seems to work, I did not use it.
Whether this will change in the future, you can still ask. You can use Visual Studio Code or your favorite IDE (WebStorm or something else), edit the code there, and Chrome DevTools will try to apply these changes live. But in fact, we have a separate project for our frontend for Node, we'll probably talk about it even later, it works a little better there, because, thank God, Node has the maximum level of compilation and TypeScript compilation in JavaScript. And it’s already difficult there, but I still hope that on Node most of the packages and modules are written in pure JavaScript without intermediate build steps. I did not answer the question, but as I could.
Dmitry: What do you think, how will Chrome DevTools develop further in principle? What are the coolest things to expect from him?
Alexei:This is a difficult question. At some point, a person appeared on Google I / O who made another convenient tool for designers. This extension for Chrome, unfortunately, I do not remember the name. And it adds directly on top of your page some elements that make it easier for you as a designer to edit and do everything. And there were ideas that Chrome DevTools might be a better tool for designers. This is already a fairly convenient tool that can, for example, look at CSS and so on, but you can still make it much more ideal and convenient. For example, more convenient editing of flex properties and other small improvements.
And there’s also an important part of working on Chrome DevTools: the project is very large, it has a lot of users and a large stream of bugs that anyone can file on the sitecrbug.com . They need to be repaired, there are a lot of them, and a lot of time is spent just to make everything work. For debugging JavaScript live edit, which we talked about, hotswap may be a good next step, but it may or may not, I don’t know.
Alexei: Chrome DevTools, it seems to me, is objectively the most sophisticated software to help web developers. But there are other browsers - Safari, Edge is still there, Firefox again. Are there any tools that I would like to drag out from other browsers in Chrome DevTools? Is there something that you like, how cool it is made?
Alexei:Chrome DevTools developers regularly look at other browsers. From the interesting that I noticed there recently, I remember that Safari had a very convenient console. They very nicely structured the output to the console, and added navigation using the arrows on the results. You can select an object there, press "right" - it will open. It was damn convenient. As a result, now this feature is in Chrome DevTools.
In Firefox, from the interesting things in DevTools, it seems to me that they support visual editing of all CSS properties a little better - by this I mean properties like flex and others - they show you the grid directly on top of the page, and you can move it all up way down. This is cool, we partially have it, but not completely. Firefox DevTools, I think, currently has by far the best support for WebAssembly. If for some reason you have to write WebAssembly code, then they are much better than us, because we had nothing six months ago, now I have not checked it. I think they are investing a lot of energy in this.
As for Safari ... in a way, Chrome DevTools is a fork of Safari's Web Inspector, so we took all the best they had.
I remembered the important thing! Probably only Firefox has Time Travel Debugging. On a Mac, in Firefox’s Nightly Builds, you can indulge in Time Travel Debugging. I kept silent about him when I was asked about the following big steps: it sounds very cool, very monumental - I still do not believe that it is very useful. Personal point of view. But they have it, you can try, if it helps you, it will be a new interesting tool.
Dmitry: That's with regards to individual instruments. My former colleagues would not forgive me if I had not asked about one thing that we really, really, really needed. I don’t even remember the name, but it was a very cool tool (from the point of view of ideas and partly from the point of view of implementation) that showed composite layers that came from CSS. But if he began to play with him, then everything would very, very much die, right down to crashes.
From my own experience, I can say that it is very important to sit down with such a thing on large projects and catch really tough problems when composite layers came upon each other and everything turned out very badly. When will this thing come back and work well and stably? And in general, to whom to go after her? Maybe you yourself can try a little bit about this about this?
Alexei:I'll start from the end. Who to go to? This, again, crbug.com , there to get a feature request. All these feature requests, of course, read: not the fact that they do, but read. And this sometimes has some effect on what we do next. You can write on Twitter: there is a Chrome DevTools account , there are accounts of all the engineers from Chrome DevTools, for example, Paul Irish . Write, complain and hopefully you will be heard.
It’s possible to cut such a thing as composite layers yourself, but a very high entry threshold - you will have to spend an infinite amount of time to understand how it works in Chrome. If you are very serious, then this can be mastered, people will be happy, and the Chrome DevTools team will be happy, but it's difficult. Because, firstly, you need very powerful hardware in order to be able to just build Chrome and play with it. And secondly, the project is still huge, and in order to at least understand where to dig, without any insider, without a person who will help you ... I don’t know, it’s very cool if you succeed.
Dmitry: And then they’ll take it to Google? :)
Alexey:If you later want to go to Google and add this to your resume, this will certainly be a good help. We once had a tool called layers panel, in my opinion. His fate was difficult, because it took a lot of effort to support, and the number of users has historically been low. Because this is a very advanced tool, certainly needed, but I think that most people did not come across composite layers. At least I did not come across, there is a slight bias.
Where did they hide him? Press Cmd / Ctrl + Shift + P, type Show layers - this tool can help. Discoverability of some features in Chrome DevTools is something that certainly requires a lot of work and corrections. It’s somewhere, it’s still not deleted. But they can delete it at any time, because somehow you need to redo this feature. It is cool, but you always want to make features that are cool, useful and can be used by a large number of people.
Dmitry: This thing has such a joke that when you need it, it’s completely straightforward.
Alexey: I agree with that.
Dmitry: For example, when you have problems on the main page of some small social network. Such tools are needed there. Yes, I agree, the problem is not common.
Alexei:You can talk about it on HolyJS. That I encountered such a problem and tried to solve it.
Dmitry: I looked a little from the side, so to speak, over my shoulder and felt what was happening. Well, the instrument itself also touched a little. This is just about what you said: once something falls, and you no longer really believe in it. Somehow it was.
Alexei: You mentioned that if I want to develop something in Chrome, then most likely I won’t succeed. For two reasons. The first is iron, I do not have such a powerful laptop. And the second is a very high entry threshold. But still, something can be done to help the team?
Alexei:Not so bad. I meant exactly about composite layers, all this composite logic in Chrome is very complex. But if you want to do something that’s easier in terms of Chrome code, it might work.
If you open the Chrome DevTools project on GitHub (this is a mirror of our frontend), there is a little instruction on how to locally build a DevTool frontend without having to build Chrome, which will save you crazy hours of time on your computer. And, accordingly, you can do something in Chrome DevTools, such patches are generally very welcome. Sometimes it happens that at first some simple bugs are fixed, something that bothers and annoys you. Or you want to add something simple. For example, not so long ago a person added a cookie editor.
And such things can be done, the DevTool frontend, from this point of view, is relatively simple. It does not use any frameworks, it is written in JavaScript, in such very vanilla basic CSS, and there is practically no HTML there either. Such a true single-page application. The only problem is that there is still some kind of framework there, and it is its own, homegrown, so you have to spend some time.
But in principle, the best approach is to look at something similar to what you want to do (for example, the same button is somewhere), look for it in the Chrome code, watch how it's done, and creatively recycle it. There is a cs.chromium.org site , and it has a convenient search by code.
Among our bugs, unfortunately, there is no “good first bug” section, but in other components of Chrome there is such a thing as good first bug - you need to look for such a label and you will find some bugs that are considered good for developers who have just arrived.
An alternative opportunity that you have if you want to work on JavaScript is a slightly smaller V8 project than all of Chrome. I am not saying that it is simpler, it is also very complex, because it is a virtual machine. But there you can also do something for debugging, and when you do something there, you immediately have the opportunity to immediately do something, not only for Chrome, but also for Node. Or vice versa, if something annoys you about Node support, you do it for Node, and then port it to Chrome. And, accordingly, you immediately make happy twice as many users.
Therefore, you can start with this, try to repair something in V8, try to do something in the DevTool frontend separately. If you really want to dig into Chrome, you can do this too, but somehow you need to find a very fast computer, otherwise you’ll just be building Chrome for 15 hours.
Dmitry: And on what machines do those developers who write Chrome generally work?
Alexei:On quite unique ones, Lenovo makes special workstations, which at Google specifically for Chrome engineers separately achieve RAM and all the rest. There are the latest Xeon, 64 or 128 cores - this is endless madness. I remember on the processor the first level cache was 32 megabytes. And although I am young, there was less RAM on my first computer. And I remember that GTA 2 worked great on my first computer.
In general, there is some kind of madness going on. And these machines cost a lot of money - Google allows you to order hardware and not pay for it, but when you order, Google always shows how much it spent on you. There are absolutely crazy numbers, and these are extremely productive machines, the latest generation of these machines makes an interesting profit. Chrome has a distributed compiler for C ++, but sometimes compiling locally on such a computer is faster. That is, redistribution for nothing is not needed when you have such a workstation at hand.
Alexei: But you won’t work from home.
Alexei:At home, I dealt with this by connecting to my machine via SSH and driving the code back and forth, I don’t remember with what help. I had some kind of plugin that allows you to conveniently synchronize code between different machines via SSH. And I wrote on my Mac, then I went into the terminal and ran the command: "Compile this code and run the tests." On a Mac, of course, people collect, it somehow works, with distributed compilers it still works more or less, but the distributed compiler is closed, it is not an open source, unfortunately.
Dmitry: Surovo. Interestingly, such a computer is more expensive than an airplane?
Alexei: No, no, much cheaper than an airplane. I recently watched the cost of a Cessna, it’s such a very popular plane, and it’s even used up to 17 times more expensive. In total, plus or minus 17 computers of the Chrome DevTools team.
Dmitry: Okay, come on, maybe simpler. More precisely, more real, from the point of view of work. In my opinion, you recently presented ndb (or some part of it), you are one of its contributors. You already mentioned that when developing Chrome DevTools, you have to slightly affect V8 and Node. How did you end up next to ndb, and why did you decide to do something for Node? Was it some kind of work task or personal initiative?
Alexei:ndb is a project with a very difficult fate. In Chrome DevTools, Node support has been around for quite some time. And it was originally hidden: Node started and told you to go to the magic URL, you went, the frontend opened. Then dedicated appeared - this is a separate frontend for Node. And you can now go to chrome: // inspect, there will be such a blue link “open dedicated frontend”, something in the spirit of this. You open it, and this frontend automatically connects to all the nodes that you run locally. It worked somehow, but there were few users, and it was not clear why. And the idea arose within the team that it was probably too difficult - extra steps. And the value that we bring to users in comparison with the steps that must be overcome does not correspond.
Therefore, it was decided to increase what we give users and reduce the threshold for entry. And in this case, we decided to do something that you can install using npm - “npm install -g ndb” - and just to make it a debugger. Initially, it required downloading all of Chrome, and it was a fairly large package. At the moment, it works with Chrome, which you have installed out of the box. And so there are 2.6 megabytes of Chrome DevTools code along with pictures. You install and run this frontend. This is in terms of ease of installation.
In addition, I wanted to add some value: before that, it was impossible to debate child-processes, which was a big problem for the people who have them. And ndb solved this problem.
The project was initially positioned so that it would be such a Node ecosystem-friendly debugger for Node. And in the reviews that I liked most, people were happy that someone started making a debugger for Node, not starting with the editor, but starting with the tools.
Because there is still a Visual Studio Code that allows you to debug Node. And he's pretty good. But this is still an IDE and it is a terrible processor that digests Python as well, and everything else that is possible. And here is a convenient tool for Node. I tend to think like this: Chrome DevTools - tools for the web, ndb - tools for Node.
They did it, started it, wanted to quietly launch it on Google Chrome Labs - we have a special GitHub repository for such experimental projects that should not be interesting to anyone at all. They thought we would quietly launch it, but in the end it turned out after 15 minutes on Hacker News and gathered some infinite number of stars. Despite the fact that nothing worked (and still does not work, I have to admit it), people like and somehow like it. And sometimes it works and works well.
The project turned out to be difficult, because it turned out that writing on Node is difficult. In an amazing way, it turned out that writing on Node on Windows, Linux, and Mac, when you need to actively interact with the file system, is very difficult, the file system is slow, the file system is full of all sorts of strange restrictions.
Well, not strange, it’s probably logical that you can’t subscribe to changes in more than n files. But still there it is implemented in such a way that at this moment it just falls, there is no way to be more flexible. And there are also standard problems with the fact that spaces cannot be passed in Windows environment variables, and on Linux it is possible, and so on. There the fun began. And since the Windows machine was not yet at hand, it turned into a nightmare.
We defeated most of the bugs, but there are still a lot of them. Someone uses the project, I sometimes use it, and I really like it when it works. We must praise what he himself did. And as to how this all was born, the idea was simply born within the team that we need to do better support for Node, and it turned out that at that time I was the best person who could do this. Of course, I am the contributor to this project, but it seems to me that I am the only contributor to this project at the moment. But the most important result of ndb, in fact, is Carlo . Carlo is Electron's very peculiar answer. At the moment it is very far from Electron in capabilities and slower than it, but this is a kind of look at how Electron can be done differently.
Dmitry: Is this the thing from Google that uses your current Chrome?
Alexei: Yes, she came from ndb. There they did it for the first time and, accordingly, the code from ndb.
Dmitry: Cool, insiders. And to work comfortably on Chrome DevTools, do the things you did, what set of skills do you need? And, in general, how to get into such a team?
Alexey: How to work in Chrome DevTools? There is a trainee path. It is like that with a life hack, because when I joined the Chrome DevTools team, it was the first day I wrote the first line in JavaScript. Before that, I had never seen a language and was, apparently, from that category of people who think that there is Java, and in JavaScript, probably, something similar should be. Well, everything was not so bad.
And the right set of skills: you must know the web stack, of course. You must be a web developer. But besides this, you must be a very specific specialist, and you need to know C ++. Because a good, solid Chrome DevTools engineer usually owns both a backend and a frontend. We have, of course, purely front-end developers and purely back-end developers, but it is always better when you know both of them. Your chances of getting into the Chrome DevTools team are significantly higher if for some reason you know both C ++ and the web stack.
I know C ++ much better, now I know JavaScript, but CSS ... I also remember a report from HolyJS, which said that CSS is a technology that you don’t need to learn, it will learn itself. But, unfortunately, does not study! Suddenly.
Accordingly, if you know both C ++ and the web stack, they will take you. If you know one thing, you will most likely be considered if you want. I’m not sure that there are vacancies on careers.google.com , you can see maybe Chrome DevTools is there, but most likely there is a software engineer vacancy, as usual. You can go to a regular software engineer and then, when you talk to a recruiter, say: "I’ve always dreamed of writing Chrome DevTools."
Dmitry: At what level do you need to know C ++? If suddenly you still wanted to.
Alexei:Good question about the level of pluses. Well, of course, metaprogramming on templates is probably not a very valuable skill; you don't need to know that. Usually this is evil: in the popular industrial code of a large open-source project, people try to avoid this, simply because the threshold for entering there is very high, and I want as many people as possible to write something.
Accordingly, you need to know C ++ at some basic level, understand classes, and so on. A little better than “Hello, world!” In general. And the standard library is not necessary to know, because you have to learn the standard library, which is in Chrome. Gradually, features from the new C ++ come into the Chrome code, but it is still C ++ 11, and we will gradually adopt new features. There is nothing like the requirement to know Boost or a specific framework.
Dmitry: More about skills. We know that you graduated from the serious St. Petersburg school of physics and mathematics 239, how much does it help and how much does it need? Or are there still tasks of a mainly logical level? As we usually program single page application.
Alexei: It seems to me that after you translate this into English, they will fire me, but I have to say this. There are regular debates on Twitter about whether a computer science background is needed or not. Regularly people are divided into two camps: some say - without this in any way, while others say - yes what for it is necessary, spend many years.
Of course, without this you can live and you will survive. Going to Google will be harder because interviews at Google are set up for people after university. And all these algorithmic problems that you don’t need most of your life will be asked for during an interview. You can prepare them separately, of course. That is, computer science-background will help you to get an interview very much, but at work ...
Here 239, in fact, was no longer about mathematics, but, in principle, about the approach to learning, it seems to me that this is a phenomenal experience and they taught me to study there. And they laid very good fundamental knowledge, which is important, on their basis you can learn something new faster. You have no such question, that here JavaScript - how to learn it? It's not a problem. You know that you know a, b and c, each of them has a piece of JavaScript, and you understand that JavaScript is just a mix of other concepts together. JavaScript is a scary mix, actually.
Accordingly, fundamental education and CS-background allow you to learn new things faster, better understand and navigate. Basically, when you need to talk about something with colleagues, it’s easier for you to describe what you are talking about. You can understand what your colleague wants to convey to you, because you know what he is talking about more or less. Therefore, it’s cool to have, if you have such an opportunity, to go get a good computer science education - I’m only for it, I think that it must have, without it in any way. But, of course, I know examples, there are a lot of successful developers who do not have it and they are quite successful. But these are people who are simply ready to study very seriously themselves.
Dmitry: It turns out, when you write some kind of debugging of asynchronous JavaScript, there are probably some kind of complex algorithms and data structures in the same place?
Alexey: Yes. All this is present, of course, but it seems to me that when you need something, you can certainly find on Stack Overflow what data structure you need to use, read about it and figure it out in a couple of days. Simply, if you passed this structure at the university, you do not need this couple of days, you just write right away. And yes, when async stacks were written, we needed to write our own little garbage collector.
Dmitry: Cool. Such a question: how do you study yourself? Roughly speaking, what are you reading, what are you reading about? What are you watching? It is for education.
Alexei:Good question. Basically, now I am trying to close some spaces, CSS and so on. In fact, I do not have such a resource that I can advise everyone. A resource is a Google search, just looking for something and trying to read. This is a very inefficient approach, I am firmly convinced that there are good resources that you open and immediately find what you need, and you don’t need to shovel a lot of information. It turns out that I can’t say that I am actively devoting time to this. I sometimes watch different lecture videos.
The last thing I watched was another course about intelligence. There, a native of the former Soviet Union teaches a course in Berkeley as a professor. It tells very interestingly about everything modern in a state of artificial intelligence, if you heard about the victory in go, about all these successes of DeepMind in the game in StarCraft(Ed. Note: although we did not find games with the gamers Zest, soO, and Stats) and so on, Reinforcement Machine Learning is now fashionable. Now Reinforcement Machine Learning specialists have already gone to write comments. If it were youtube, there would already have been 15 comments that I don’t understand what I’m talking about.
Recently, it has turned out that it’s just work-work-work, and in work you constantly need to learn some small nuances, understand and realize it, and you quickly learn them. I don’t have one that I spend two hours a week on self-education. I play the guitar, but it doesn’t help me write in CSS.
Alexei: How do you know?
Alexei:I don’t know, I think so. In fact, there are different theories. It is said that playing the guitar allows you to learn other languages faster. Knowing better English, I can read more articles and listen to more podcasts and YouTube - and, as a result, learn CSS faster. So perhaps there is a connection. But in order to learn directly how to program while playing the guitar, no.
Dmitry: Cool. What do you think about meetings and workshops in this context? How useful are they?
Alexei:To have a good point of view, you need to participate at least more than once. I once participated in Node.js when we helped people write basic code on Node. And it seems to me that it's cool. At least, as always, when you are learning something or doing something, the most important thing is your determination, in fact. Of course, it will be difficult, you will not understand something and do not understand what you are doing here, but you constantly need to overcome misunderstanding and throw yourself into this thicket of incomprehensible knowledge and words. It's complicated.
And therefore, it seems to me that such basic mitaps and workshops for people - “let's copy the first patch in Node.js” - are useful, because this first step, it seems to me, for people who have never smoked anything in Node.js, very complicated. And at such a basic level, I think it’s cool, because you help them overcome this first threshold of entry. Then they will face another fifteen other rapids, and you need to help them there too.
Dmitry: We turn to the last questions. You must have been to a large number of conferences. What do you think a conference cannot be good without? Someone thinks that conferences are only for networking, others only as reports, these are very extreme points of view. And what is most important to you?
Alexei:It seems to me that the organizational part is very important. I really love those conferences when everything is organized so well that I do not remember the existence of the organizational part. Because a couple of times I was at conferences where the projector didn’t work, something else didn’t work. It’s always very unsettling because if you want to tell something, in my case I’m always very nervous and worried, and if something else doesn’t work, I want to shoot someone right there right away. Therefore, the organizational part seems very important to me. The organizational part is like DevTools: when they work, everything is fine, no one ever remembers or notices about it, but when they do not work, it’s a fire.
And everything else is important too. It would be nice to have cool reports, well selected and varied in subject matter, because quite different people always come. Because when networking happens, you want to communicate not only with people who write a JavaScript debugger, but with people who write everything in the world. And through the exchange of experience and different perspectives on problems, to gain new knowledge. Accordingly, a variety of people, organization, cool reports - a standard set.
It’s very cool when there are reports at the conference on general life issues (“I don’t know how to learn CSS at last”) and at the same time technical. There are conferences where there is a strong bias in life (diversity, how do we learn CSS, and so on), but there are no technical reports. And you listen to three reports in a row on such abstract topics, they are important for the industry, but the technical part is not enough. Always need a balance. Conclusion from this - I really like balanced conferences. But balance is a thing in perception that is very personal and personal, so leave the organization. Organization is an absolute thing.
Dmitry: And the final one: what do you expect from HolyJS?
Alexei:I really look forward to HolyJS, because in May St. Petersburg is always very cool. I am waiting, as always, for class reports. I'm waiting for me to meet again with all these cool speakers that I saw a year ago, and look forward to seeing all these cool organizers.
Dmitry: Political correctness is not needed, if that ...
Alex:Prepare a good report, actually. For me, the most important thing is to prepare a good report. Otherwise, strong excitement appears. I'm really looking forward to it. I love HolyJS very much in St. Petersburg, because a very cool conference and even St. Petersburg in May is the best city on earth, it seems to me. I'm sorry, I'm just from there. And in May there is no rain, the sun, beautiful weather, bridges are being built, white nights have almost begun, and such a cool conference is an ideal moment. Very politically correct interview. Something I overdid this time.
The report “Chrome DevTools Protocol” (and not only it) can be seen in the free HolyJS broadcast , where the reports from the first room on May 24th fall. After the end of the broadcast, YouTube will render the recording, and only part of the day will be temporarily available, but later it will again be available in its entirety.