About summer internship at JetBrains
Hi, Habr!
Now nobody is surprised that internships are organized for IT companies for students. At the same time, employers themselves have different goals: choose among the best students for further work, introduce newcomers to their workflow, or even simply satisfy the need of the university to attach students to it for the summer. We didn’t have special internship programs in past years: if one of our employees teaches at an educational institution, and there is a very sensible student in the stream, over time his term paper may turn into something more related to our work.
Over the years, we have a lot of educational programs that we support ( Computer Science Center , Master's program at the AU RAS , JetBrains Laboratory at the Faculty of Mathematics and Mechanics of St. Petersburg State University, etc.) and many students who want to do an internship with us. As a result, this summer we conducted a large-scale summer practice project.
')
Here is what one of the interns tells about his practice, a student at the Computer Science Center and the Polytechnic University, Kirill Kononov:
My August 2013th was all about internships at JetBrains. Under the leadership of Dmitry Bulychev, I worked on an individual project “Command Line Plugin for IntelliJ IDEA”.
It all started with the fact that once in my high school (SPbGPU) the whole course was announced of the need to go through summer “work experience”. This procedure involves the monthly employment in any company that the student needs to accompany a number of documents and reporting forms.
Our department has several standard options - these are three plants: "ZMK", "Aurora" and "Krizo". Guys are sent there “by default” if they do not express a desire to do the practice elsewhere. But all these options were not interesting to me, besides, I heard a lot of negative reviews about the work in these places. As a rule, students there perform very primitive tasks (like scanning paperwork) and, by and large, are not needed by anyone.
The thought arose that since I was studying at the CS Center, then I should take an internship at one of the friendly companies. Thus, I decided to combine the necessary with the useful.
It was the month of March, when I turned to the curators of the Computer Science Center for my question. At that time, nothing concrete was known about summer internships, and I was offered to write directly to company representatives. There was little time left, because soon I had to submit a primary document to the department.
I wanted to be at JetBrains, so I contacted Andrei Ivanov (JetBrains COO) and in a letter I expressed my desire to get an internship. Andrei Vladimirovich invited me to the office for a conversation. I told about myself, about the university, about the procedure of production practice and about my training in the CS-center. It was then that I met Dmitry Bulychev - he was ready to take me to one of the projects.
It was the same project that I wanted to get in the fall of 2012. But it turned out that at the Academic University, presentations of the practices took place earlier than at the CS-center, and the Command Line Plugin went to students from the AU - Sergey Savenko and Pavel Chadnov. Thus, by the time I began my summer internship, there was already a certain prototype of the plug-in. I had to study it, and then continue to develop.
Here are the main points that were made before me:
It is worth noting that Sergey and Pavel did a great job. Even the first item in itself is quite capacious for a developer who writes a plugin for the first time. However, not everything in the then state of the project was operational. Moreover, in the discussion with Dmitry, we decided to change the architecture in many ways.
The new version of the plugin is characterized as follows:
Next, I will briefly talk about how each of these points was implemented.
The use of named arguments allows for much greater flexibility than the use of positional ones. The following format was adopted:
A total of six options are possible - including long values ​​in quotes (they can contain any characters, including spaces).
The essence of the feature is that when input is changed, parsing is performed only for the arguments on the different part of the string. At the next parsing, the first non-matching character is determined for the old and new lines, after which only the states of the affected one (the black line below) and the subsequent arguments are subject to change.
In this example, the v3 argument will be deleted from the old state along with its value, and the v4 argument will be added to the new one (without clearing and re-parsing the command, v1 and v2 arguments).
Thus, on long commands with a lot of arguments, a significantly higher parsing efficiency is achieved, because in reality, input changes will almost always occur at the end of the line: the user quickly dials a command, and after each key pressed there is no need to perform a full parsing.
Autocompletion is the ability to substitute the full string value of any part of the text during user input.
Options are available to supplement:
The hints in the first two directions are obvious: the plugin has its own set of commands, has a set of commands derived from extensions using an extension point , and has a fixed set of options for each command.
In the case of values, there are two options: completion may appear from the standard “provider” of type values ​​(as in the example when we can list all relevant values ​​for this type) or be provided by the team developer. The second case is implemented, for example, if the value should be any path to the file from the environment. In general, the String will not be added, but in the context of a specific command and a specific variant of the argument, similar prompts can be offered.
Validation here is the definition of the correctness of the input command, along with all its arguments.
It includes a case study:
The last three types of analysis are implemented in such a way that they can be easily used for typical cases. However, beyond this, the team developer can manually implement any more complex validation logic.
From the interface point of view, the result of the validation at any time can be determined by the state of the “Execute” button in the plug-in component: if there is a problem, the button will be unavailable.
When using the command line, the ability to return to the previously entered commands is customary. Within the framework of this idea, the plugin has two main functionalities:
Below is an example of showing the full list of commands:
It is important that the story accumulates over the lifetime of the entire IDE (and does not disappear when you close the command line component and open it elsewhere).
In its new form, the command line plugin is presented as a stable component. It does not disappear when the focus is lost or any other actions unrelated to its explicit closing or closing of the containing container (as opposed to pop-up components).
The component can be launched in any visual area in the IDE if the user first makes it active. After that, the command line will correctly respond to movement and size changes in the component hierarchy in which it will be included.
The example shows the behavior strategies of a component in various conditions. For example, it can be seen that it has a minimum size and it does not go beyond the boundaries of the IDE during extreme stretching / compression of a window.
Thus, the plugin feels comfortable in the IDE window.
Soon after the completion of the internship, Dmitry and I agreed on the continuation of the project, already in the framework of the semester practice from the CS-center. The following estimates were taken as approximate benchmarks:
40% of the time:
60% of the time:
The first point is needed because there are still unfinished details in the architecture and in the interface. The expansion of the instruction set is the next step, the implementation of which will be based on the viable infrastructure made earlier.
Now I would like to tell you a little about how my work at JetBrains took place.
On the first day of August all the new participants of the practice gathered at the reception. We received a paper on the non-disclosure of secrets of the company and soon went on a mini-tour. We were shown the main objects in the office ecosystem and were told what and how it works, who and where is sitting, how to get to the roof, and everything else that could be interesting. Then everyone knew what room he would sit in, and everyone went to their places. Work has begun.
I ended up in room 303 - it was a meeting on the third floor with black walls and yellow curtains. Besides me, four more labored in the room. When we arrived, all the necessary personal integration tools were already located next to our computers: an electronic pass and a document with information about accounts, corporate mail and company resources.
My neighbors were a team of three people who worked on the VMkit and MMTk project, as well as one of the project participants involved in decompiling the JVM bytecode. All neighbors, like me, were supervised by Dmitry Bulychev.
The first stage of my internship was to study the existing developments that remained from the children from the AU. Two days before the start of the practice, I found one of the past participants - Sergey Savenko - on the social network, and asked him about the project. Sergey willingly answered my questions and told about the device of the main components of the plug-in, their interaction with each other and other paramount things. Later, during the internship, it helped me to quickly understand the unfamiliar code.
At that time, Sergey also practiced at JetBrains, and then it turned out that we were sitting in the next rooms. True, in the office met with him a couple of times.
Monthly employment in the company took place on full-time working conditions, which meant an 8-hour working day. We did not have a hard schedule, so everyone made up the regime, based on their own preferences. By a strange coincidence, all my neighbors turned out to be larks: they started work early - about 10 hours. I usually came from 12 to an hour, when everyone was already assembled. But he finished much later than the others.
In the last week of August, a “summer school” was held at the St. Petersburg State University Mat-mekh, in which many students from this department were involved, as well as Dmitry Bulychev. The “VMkit and MMTk” team went to classes in full, and there were two of us left in the 303rd room. This week we worked without a manager, which, however, had no effect on efficiency.
In most of the practice time, communication with Dmitriy took place, as a rule, at the initiative of the student. We held meetings as needed and discussed everything that was relevant at one time or another. There was one global task that we initially discussed in detail, after which I had enough autonomy to work. So I liked working with Dmitry. And the whole internship turned out great!
Now nobody is surprised that internships are organized for IT companies for students. At the same time, employers themselves have different goals: choose among the best students for further work, introduce newcomers to their workflow, or even simply satisfy the need of the university to attach students to it for the summer. We didn’t have special internship programs in past years: if one of our employees teaches at an educational institution, and there is a very sensible student in the stream, over time his term paper may turn into something more related to our work.
Over the years, we have a lot of educational programs that we support ( Computer Science Center , Master's program at the AU RAS , JetBrains Laboratory at the Faculty of Mathematics and Mechanics of St. Petersburg State University, etc.) and many students who want to do an internship with us. As a result, this summer we conducted a large-scale summer practice project.
')
Here is what one of the interns tells about his practice, a student at the Computer Science Center and the Polytechnic University, Kirill Kononov:
KIRILL KONONOV:
My August 2013th was all about internships at JetBrains. Under the leadership of Dmitry Bulychev, I worked on an individual project “Command Line Plugin for IntelliJ IDEA”.
It all started with the fact that once in my high school (SPbGPU) the whole course was announced of the need to go through summer “work experience”. This procedure involves the monthly employment in any company that the student needs to accompany a number of documents and reporting forms.
Our department has several standard options - these are three plants: "ZMK", "Aurora" and "Krizo". Guys are sent there “by default” if they do not express a desire to do the practice elsewhere. But all these options were not interesting to me, besides, I heard a lot of negative reviews about the work in these places. As a rule, students there perform very primitive tasks (like scanning paperwork) and, by and large, are not needed by anyone.
The thought arose that since I was studying at the CS Center, then I should take an internship at one of the friendly companies. Thus, I decided to combine the necessary with the useful.
Introduction
It was the month of March, when I turned to the curators of the Computer Science Center for my question. At that time, nothing concrete was known about summer internships, and I was offered to write directly to company representatives. There was little time left, because soon I had to submit a primary document to the department.
I wanted to be at JetBrains, so I contacted Andrei Ivanov (JetBrains COO) and in a letter I expressed my desire to get an internship. Andrei Vladimirovich invited me to the office for a conversation. I told about myself, about the university, about the procedure of production practice and about my training in the CS-center. It was then that I met Dmitry Bulychev - he was ready to take me to one of the projects.
Project Command Line Plugin
It was the same project that I wanted to get in the fall of 2012. But it turned out that at the Academic University, presentations of the practices took place earlier than at the CS-center, and the Command Line Plugin went to students from the AU - Sergey Savenko and Pavel Chadnov. Thus, by the time I began my summer internship, there was already a certain prototype of the plug-in. I had to study it, and then continue to develop.
Here are the main points that were made before me:
- organization of the plug-in for IDEA with the necessary components (including extension point)
- prototype architecture implying positional arguments
- built-in set of four teams
- prototype autocompletion capabilities
- interface as a pop-up component
It is worth noting that Sergey and Pavel did a great job. Even the first item in itself is quite capacious for a developer who writes a plugin for the first time. However, not everything in the then state of the project was operational. Moreover, in the discussion with Dmitry, we decided to change the architecture in many ways.
The new version of the plugin is characterized as follows:
- architecture based on named arguments
- effective incremental parsing
- full support for autocompletions
- multidimensional validation
- command history
- interface as a sustainable component
Next, I will briefly talk about how each of these points was implemented.
1. Name arguments
The use of named arguments allows for much greater flexibility than the use of positional ones. The following format was adopted:
A total of six options are possible - including long values ​​in quotes (they can contain any characters, including spaces).
2. Incremental parsing
The essence of the feature is that when input is changed, parsing is performed only for the arguments on the different part of the string. At the next parsing, the first non-matching character is determined for the old and new lines, after which only the states of the affected one (the black line below) and the subsequent arguments are subject to change.
In this example, the v3 argument will be deleted from the old state along with its value, and the v4 argument will be added to the new one (without clearing and re-parsing the command, v1 and v2 arguments).
Thus, on long commands with a lot of arguments, a significantly higher parsing efficiency is achieved, because in reality, input changes will almost always occur at the end of the line: the user quickly dials a command, and after each key pressed there is no need to perform a full parsing.
3. autocompletion
Autocompletion is the ability to substitute the full string value of any part of the text during user input.
Options are available to supplement:
- team name
- argument option name
- argument values ​​(when possible)
The hints in the first two directions are obvious: the plugin has its own set of commands, has a set of commands derived from extensions using an extension point , and has a fixed set of options for each command.
In the case of values, there are two options: completion may appear from the standard “provider” of type values ​​(as in the example when we can list all relevant values ​​for this type) or be provided by the team developer. The second case is implemented, for example, if the value should be any path to the file from the environment. In general, the String will not be added, but in the context of a specific command and a specific variant of the argument, similar prompts can be offered.
4. Validation
Validation here is the definition of the correctness of the input command, along with all its arguments.
It includes a case study:
- invalid command, variant or argument value
- mutually exclusive arguments
- lack of required argument
- no dependent argument in relation to the already entered
The last three types of analysis are implemented in such a way that they can be easily used for typical cases. However, beyond this, the team developer can manually implement any more complex validation logic.
From the interface point of view, the result of the validation at any time can be determined by the state of the “Execute” button in the plug-in component: if there is a problem, the button will be unavailable.
5. Team history
When using the command line, the ability to return to the previously entered commands is customary. Within the framework of this idea, the plugin has two main functionalities:
- movement through the command history: Ctrl + up / down
- show full list of commands
Below is an example of showing the full list of commands:
It is important that the story accumulates over the lifetime of the entire IDE (and does not disappear when you close the command line component and open it elsewhere).
6. Interface
In its new form, the command line plugin is presented as a stable component. It does not disappear when the focus is lost or any other actions unrelated to its explicit closing or closing of the containing container (as opposed to pop-up components).
The component can be launched in any visual area in the IDE if the user first makes it active. After that, the command line will correctly respond to movement and size changes in the component hierarchy in which it will be included.
The example shows the behavior strategies of a component in various conditions. For example, it can be seen that it has a minimum size and it does not go beyond the boundaries of the IDE during extreme stretching / compression of a window.
Thus, the plugin feels comfortable in the IDE window.
Project development
Soon after the completion of the internship, Dmitry and I agreed on the continuation of the project, already in the framework of the semester practice from the CS-center. The following estimates were taken as approximate benchmarks:
40% of the time:
- refinement of architectural components
- interface improvement
60% of the time:
- command set extension
The first point is needed because there are still unfinished details in the architecture and in the interface. The expansion of the instruction set is the next step, the implementation of which will be based on the viable infrastructure made earlier.
Internship
Now I would like to tell you a little about how my work at JetBrains took place.
On the first day of August all the new participants of the practice gathered at the reception. We received a paper on the non-disclosure of secrets of the company and soon went on a mini-tour. We were shown the main objects in the office ecosystem and were told what and how it works, who and where is sitting, how to get to the roof, and everything else that could be interesting. Then everyone knew what room he would sit in, and everyone went to their places. Work has begun.
I ended up in room 303 - it was a meeting on the third floor with black walls and yellow curtains. Besides me, four more labored in the room. When we arrived, all the necessary personal integration tools were already located next to our computers: an electronic pass and a document with information about accounts, corporate mail and company resources.
My neighbors were a team of three people who worked on the VMkit and MMTk project, as well as one of the project participants involved in decompiling the JVM bytecode. All neighbors, like me, were supervised by Dmitry Bulychev.
The first stage of my internship was to study the existing developments that remained from the children from the AU. Two days before the start of the practice, I found one of the past participants - Sergey Savenko - on the social network, and asked him about the project. Sergey willingly answered my questions and told about the device of the main components of the plug-in, their interaction with each other and other paramount things. Later, during the internship, it helped me to quickly understand the unfamiliar code.
At that time, Sergey also practiced at JetBrains, and then it turned out that we were sitting in the next rooms. True, in the office met with him a couple of times.
Monthly employment in the company took place on full-time working conditions, which meant an 8-hour working day. We did not have a hard schedule, so everyone made up the regime, based on their own preferences. By a strange coincidence, all my neighbors turned out to be larks: they started work early - about 10 hours. I usually came from 12 to an hour, when everyone was already assembled. But he finished much later than the others.
In the last week of August, a “summer school” was held at the St. Petersburg State University Mat-mekh, in which many students from this department were involved, as well as Dmitry Bulychev. The “VMkit and MMTk” team went to classes in full, and there were two of us left in the 303rd room. This week we worked without a manager, which, however, had no effect on efficiency.
In most of the practice time, communication with Dmitriy took place, as a rule, at the initiative of the student. We held meetings as needed and discussed everything that was relevant at one time or another. There was one global task that we initially discussed in detail, after which I had enough autonomy to work. So I liked working with Dmitry. And the whole internship turned out great!
Source: https://habr.com/ru/post/202318/
All Articles