The best presentations at the conference United Dev Conf 2017

In April, a large IT conference United Dev Conf, organized by Frontend Dev Conf, Highload Dev Conf and Mobicode, took place in Minsk.

We were offered to be inspired by the experience, to find new friends and business partners, to find out the latest news and trends, and just enjoy socializing with like-minded people. How was it possible to refuse such an offer? Therefore, we went to the capital of our northern neighbor.

In Minsk, we were met by gloomy weather and strict border guards. Having finished with the formalities, we headed to the very center of the city, to the venue of the conference. Ahead of us waited two days of interesting reports and communication.
')
The conference was held in four streams: Frontend, Highload, Mobile and Sales. About 700 participants attended, and 40 speakers shared their experiences. And during the breaks, the sponsoring companies played quadrocopters, which could have been played at an IT event without them.

We, as front-end developers, were primarily interested in the Frontend stream, and we actually visited it during these two days. All reports were interesting, but we chose the most interesting, in our opinion.

Day 1

Konstantin Kryvlenia, “Continuous Integration for the Frontend” ( slides )

With the development of technology on the web, projects have become more complex. Now, to run the project, you need to install a bunch of dependencies and wait for the build to build. To make applications reliable and easier to develop without errors, the code needs to be tested. Finally, in order to deliver our project to users, you need to perform all the above steps and put the code on the server. These are routine operations that are simplified thanks to continuous integration and delivery systems.

Konstantin began with a story about the old days, when we connected to the server via FTP, copied files there, or corrected them there if necessary. Then the speaker raised the problems of working in a team, namely the merging of the results of work, when your change creates bugs in the feature of a colleague, and vice versa. He shared such popular ways of solving these problems as global configuration of code analyzers for projects and writing tests. All checks must be performed before committing the code, in which Git itself can help you through git-hooks.

But best of all is to entrust the entire assembly and testing process to continuous integration systems. This allows not to load the working machine and keep all the artifacts in one place. The report highlighted systems such as Travis , Jenkins , Concourse.ci , Circleci and Teamcity . All of them have their advantages and disadvantages. For example, Travis, despite the assembly matrix that appears, allowing the process to be broken down into stages, still has less readable logs than Jenkins, but the latter has a much less convenient interface.

In conclusion, Konstantin noted the advantages and disadvantages of using continuous integration systems. Positive aspects include:

• Early detection of bugs.
• Avoidance of protracted releases, evergreen assemblies and, as a result, expectation.
• Assembly artifacts are always in the same place, if necessary, it will be convenient to study them.
• Instilling discipline in a team.
• One step to continuous delivery.
• The ability to easily remove the code metrics.

However, CI have several disadvantages:

• The need to configure such a system, which is sometimes a difficult task.
• Does not always reflect the real situation; the absence of errors in the tests does not guarantee the performance of the application.
• Long response in large projects.
• The instability of the system itself; there are situations when the build falls through the fault of the build agent, and not the failed test.

Denis Radin, “Applying NASA Coding Standards to JavaScript” ( slides )

The reports of Denis always touch on interesting topics, and this time he raised a very interesting, and meanwhile, an important topic: why don't JS developers trust to write software for spacecraft and aviation? He also offered to speculate how to correct this situation.

The speaker suggested that in the future all interfaces will be written in HTML / CSS / JS, because this is, at the moment, the best bundle for developing interfaces. At the same time it has a number of advantages and disadvantages. The arguments “for” include: availability over the network, the possibility of a simple update and sharing, reliability, and a rather large market for components. However, there are a number of serious flaws, such as poor performance, risk of memory leaks, etc.

As front-end developers, we would never want to fly on airplanes that run JavaScript. And all because in our work a very small price of error, which allows us to write less secure and stable code.

However, if we want to capture this niche in the future, we need to introduce new standards for writing code. Denis looked at the rules that govern NASA and the Jet Propulsion Laboratory when programming their spacecraft, and applied them to JS.

1. One function is one thing . Small functions are easier to read, reuse, test and refactor.
2. Predictability . "Stop writing cool code, start writing simple and predictable." Define coding standards, use code analyzers and collect metrics.
3. Respect RAM . Nowadays, SPA applications can work for hours without reloading the page. We need to know how the garbage collector works and help it do its job. You also need to investigate the application for memory leaks using developer tools in browsers.
4. All cycles must have an upper limit . This rule is difficult to interpret for the JS code, this is an antipattern for us, we want to be flexible. So let's say that this is a plus in the piggy bank of static analysis.
5. Test your application well . There should be at least 2 tests for one function. Monitor and study system anomalies, as well as measure code coverage.
6. No shared state . This can lead to unpredictable results, which contradicts clause 2.
7. Check the value of the returned functions . The most neglected rule is due to its non-pragmatism. We will not check every time that, for example, Math.round returned a true integer.
8. Limit the amount of code being transported . We cannot predict which code is generated by the transpiler, the performance of this code will be lower, and the size of the assembly will increase.
9. Reduce connectivity . Encapsulate logic and state, reduce call chains.
10. Keep everything green . Tests, dependencies, builds. From the very start of the project.

Day 2

James Allardice, "Building a better login with The Credential Management API" ( slides )

James flew in from foggy Albion in order to share knowledge about new features in the field of authorization on websites.

Since the appearance of the login form, not much has changed in the interface: we all also have fields by which we can determine who is in front of us. But browsers began to help users interact with these forms, saving usernames / passwords, automatically filling out forms and synchronizing our keys between devices. Also, third-party authorization services and social networks have simplified our lives when authorizing in a new or familiar to us system.

The Credential Management API is a new step in the development of browser help filling in login forms. It provides two key features:

1. Helps with authentication by giving developers access to user credentials.
2. Helps the browser to save this data.

All this allows you to implement on your site the following sequence:

• the user logs in to the site for the first time;
• we save its data in the browser storage;
• the next time the user logs in, we will check if there is a saved password for him and authorize it himself, without even showing the login page.

This is a secure technology: a prerequisite for the API is a secure connection. It works only within the same domain, user data is not available on the page, it is encrypted in the internal storage of the browser. So even if the attacker receives them, he cannot use them.

It sounds interesting, but in reality it's still an experimental API. Its specification is at the draft stage, which adds the risk of a major API change, and the only browser that supports it is Google Chrome. There is also a limitation: it works only with the Fetch API.

However, despite the very limited support and the initial stage of the specification, you can please your Chrome users with a new convenient feature. We are waiting for the rest of the browser developers to catch up.