Better to lose a day

In investing, there is the concept of “Bad now - good then.” The investor regularly nibbles off 10, 20% or even 30% of his earnings for the future. He invests this money in bonds, stocks, OFZs, ETFs - who is much worth it. Now, in the moment, the investor is taking away his earnings, is depriving himself of some benefits, so that in the future, on the horizon of 10-20 years, he will benefit from investments. Profits in the future will cover today's hardships. About the same strategy professed by Alexei Okhrimenko ( obenjiro ), but with regard to development - it is better to lose a day, and then fly in 5 minutes.


Source

At  Frontend Conf 2018, Alexey said how having lost a lot of time now, ultimately save it later. This report is not about a feeling of boredom and not about how to deal with monotonous and routine tasks, but about how to spend time to the maximum  - how much is, spend everything, and see what comes of it. The transcript of the report is the experience of writing tools for debugging, testing, optimization, scaffolding and validation for different projects. As a bonus, Alexey will talk about a number of existing tools and the benefits they bring. Let's find out if you need to waste time on this at all.

About the speaker: Alexei Okhrimenko  is a developer at Avito Frontend Architecture, where he improves the lives of millions of people a little. Leads a Podcast“5 min Angular” , and in his spare time from sleep and podcast, he organizes Angular Meetup together with the guys from Tinkoff, and makes a huge number of different and  controversial reports .

Where can I lose time?

The zero step is to buy a Mac / iMac and immediately begin to lose time, or put Linux on a laptop and lose all working time in it, changing configs. I also highly recommend starting with Gentoo.

There are 8 points we can spend time on.

• Terminal.
  
• Design.
  
• Create a project.
  
• Code Generation.
  
• Spelling code.
  
• Refactoring
  
• Testing.
  
• Debugging
  

We proceed to a solid loss starting in order.

Terminal

Where on the terminal can we spend our time to lose everything? Organize your workspace  - create folders “My work”, “My hobby projects” and put everything in them. Set yourself Homebrew to install additional software that will be mentioned.



Put iTerm2 , and default terminal on Mac - throw it out.



Install add-ons like oh-my-zsh , which come with a bunch of very cool plugins.



Put tmux - terminal multiplexer. This is a program for the terminal, which allows you to open several windows in one window and additionally support the session. Usually, if you close the terminal, everything breaks and ends, and tmux will continue to work, even if you turned it off. If I have never worked with tmux, I recommend a review from DBMS Studio .



Prescribe aliases . Every time you wrote something more than once in the terminal - write yourself alias, it will come in handy. Two times - already a lot, there will certainly be a third, sixth and tenth.



Deliver additional tools, for example, jmespath or in abbreviated form - jp. It can be installed through brew and make interesting query-requests in JSON-files.

brew tap jmespath/jmespath
brew instal jp

For example, you have packed JSON files, you can go through everything and find out which versions of React in your applications and projects.

Automate your work - do not open the same files many times!

Now let's talk about where to spend it all. All that is above is a small loss of time, you can lose more in Shell Scripts.

Shell script

It is a programming language, mainly for bash, with its own syntax.

#!/bin/bash
for dir in ‘ls $YOUR_TOP_LEVEL_FOLDER’;
do
for subdir in ’Is $YOUR_TOP_LEVEL_FOLDER/$dir’
do
$(PLAY AS MUCH AS YOU WANT); 
done
done

The language is full - some people create games and web servers, which I do not advise doing. I recommend all the work that took the time to spend it again and write it all fully in the file. What for? All the familiar developers who have been working in the industry for a long time simply create their own GitHub repository for configurations and place the configuration there for their TMUX - terminal multiplexer, Shell Scripts for initialization.



Why spend a ton of time on what has already been done once? Then, when you switch to another job, they will change your computer at work, the motherboard will burn out and you will spend a day or two or three again to set up the environment . When you have such a repository, setup and installation will only take 10 minutes.

Design

Usually everyone is very inspired at once: “Yes, design! UML diagrams! ”, But when I say the word UML out loud, many familiar programmers notice:

- In 2018 ?! What happened to you? UML is a terrible relic of the past. Why are you digging up a corpse? Drop the shovel!

But UML is very useful. For example, at a Scrum rally, a Java developer listens as Python programmers discuss backend feature architecture. He rubs his head sadly and realizes that he does not understand anything, but simply loses an hour of his time. A Java developer cannot interact with Python programmers - he won’t say how to write code, use classes, mixins, or anything else. He simply is not involved in the matter. Our company has JavaScript, Python, and Lua. In the moment 2/3 of people are bored: first one 2/3, then others. UML solves this problem.

UML is a universal abstract visual language for system design, which allows you to ignore the features of languages.

I will give two of my favorite examples.

Sequence diagrams

These diagrams help show the history of interaction over time.



On the vertical Y axis, a temporal dependence goes down: first we get an authentication request, then we give an answer, and then we put something in the logs. On the horizontal axis X there is already a direct interaction between the characters - participants in some event.

Personally, I periodically use Sequence Diagrams to describe process authentication in applications. In doing so, I, a JS developer, find a common language with the backend of Python, Lua and Java. We all understand each other and know how the code will work as a result, and we don’t bother about the specific implementation of this or that language.

Class diagram

These charts are also very useful. JavaScript has classes, what's the point of diagrams? But there is TypeScript, and with it you can get interfaces, abstract classes - a complete representation of the final architecture.

A minute of design saves a week of coding.

PlantUML

I use the PlantUML Java library . With it, you can use some complicated dsl, in which, for example, indicate that List is inherited from AbstractList, Collection from AbstractCollection, as well as interaction, aggregation, properties, interfaces and everything else.

@startuml
abstract class AbstractList 
abstract AbstractCollection 
interface List 
interface Collection
List <|— AbstractList 
Collection <|— AbstractCollection
Collection <|— List 
AbstractCollection <|— AbstractList 
AbstractList <|— ArrayList
class ArrayList {
Object[ ] elementData 
size()
}
enum TimeUnit {
DAYS

As a result, I get the final diagram.



All this works well, there are plugins for Visual Studio Code.
There is another interesting application.

StarUML

We draw the simplest diagram: there is a base class from which the test class is inherited.



Next we use StarUML . It is not too expensive and can export to Java. There is no tool that would export UML diagrams to TypeScript code, but we can export just using StarUML to Java code.

Jsweet

Then we apply JSweet  - a library that allows you to convert Java code to TypeScript or JavaScript code.



Java code ...

import java.until.*;
/**
*
*/
public class BaseClass {
/**
* Default constructor 
*/
public BaseClass(){
}
/**
* some attribute 
*/
protected String baseAttribute;
}

... using JSweet convert to TypeScript code:

/* Generated from Java with JSweet 2.0.0 — http://www.jsweet.org */ 
/**
* Default constructor
* @class 
*/
class BaseClass {
public constructor) {
this.baseAttribute = null;
}
/**
* some attribute 
*/
baseAttribute : string;
}
BaseClass["_class«] = «BaseClass»;

There is an additional parameter here _class- this is a feature of Java, this can be deleted. As a result, we got a ready-made boilerplate of TypeScript code from diagrams - a base on which you can work. Moreover, this base is designed and clear to everyone.

Spending time designing UML is definitely worth it.

Project creation

Who configures Webpack every time and creates webpack-config in a new project - guys, what's wrong with you ?! All is well? Do you need some help? If you are held hostage - write the coordinates in the comments, we will send a rescue helicopter.

The easiest way to avoid this and not to configure the same thing each time is to create a common repository on GitHub locally or raise GitLub CI, clone this repository, go into it and delete the git folder.

git clone something
cd something
rm -rf .git

Now we have a reference project from which we are cloning. With this approach you can get very cheap bootstrapping .

Yeoman - deprecated. Slush - deprecated

That Yeoman deprecated  is too arrogant. It is not deprecated, just less and less use it, like  Slush . These are two identical tools, just with a different base: Yeoman is Grunt and code generation. Slush is Galp and code generation .

Despite the fact that the tools are interesting, now others are more often used.

Angular CLI, Create React App, Vue CLI

Who works with Angular - use the Angular CLI. Create React App - who works with React. Vue CLI - fans of Vue.JS.

Most have already moved to these tools. One of the main arguments why it is worth working with the CLI is uniformity . If you forgot to grab your project using the CLI, you are sure that the person who comes after you will know the structure of the project: teams, features, that you can run end-to-end and unit tests. These tools are very good.

Is it worth it to spend time on bootstrapping projects using the CLI, rather than Yeoman? Yes, do not hesitate.

Code Generation

We have a certain code base. Usually, when we start a project, we create Routing first, and then Redux - how can we do without it? Each framework has a specialized code generation tool. In Angular, this is CLI Schematics . Vue CLI has a separate section for generating Vue CLI plugins : you can generate some code for our projects in the plugins section .

Redux CLI

I want to focus on the React and Redux CLI, because from my practice, it is React programmers who are the least engaged in code generation and it hurts to look at it. Every time people create the same files and complain that it is hard to work with Redux, you need to create a bunch of everything. So there are already tools!

This is the Redux CLI , which will create a dock file for you, in which there will be effects, and reducers, and the corresponding actions, and "stupid" components, and "smart" components. Additionally, you can generate your components or code base using the Redux CLI. Redux CLI is installed simply, you can either create a project using it, or initialize it in a ready-made one, for example, created using the Create React App.

npm i redux-cli -g
blueprint new 
blueprint init
blueprint g dumb SimpleButton

There is another universal tool that does not depend on the framework - Plop .

Plop

I found out about him recently. Plop does the same as the previous one: by initializing this tool, you can create all the necessary basic components. Indicate what components your application consists of and just generate them. So you do not waste time creating the main code base. Having a user story and specification you can generate basic functionality, tests, basic styles - save a huge amount of work .

You will have to tune all the tools - I periodically tune to React Blueprint, make my component library, but  this time pays off .

Code writing

There will be triviality.

Code snippets

Code snippets allow you to write a small fragment, a key code word, and get a ready-made piece of functionality. For example, you can create an Angular component by writing @Component.


For React and Vue, there are the same code snippets.

There is a problem with commonplace code snippets. The more professional the developer, the less he uses code snippets - simply because he already knows how everything is written and he is too lazy to create them. He already remembered how to write this component.

Let me remind you that our goal is to spend time without doing anything useful. Therefore, we sit down and write code snippets. Here you can spend an infinitely large amount of time, and the goal will be achieved.

Personally, snippets came in handy when I worked with  i-bem.js :

modules.define("button«, [«i-bem-dom»], function(provide, bemDom) {
provide(
bemDom.declBlock( 
this.name,
{
/* методы экземпляра */
},
{
/* статические методы */
}
)
);
});

There is nothing complicated about this declaration, but the syntax is neither Angular, nor React, nor Vue, and it is very difficult to remember it the first hundred times. One hundred and first is remembered. I was tormented, spent a lot of time, and then began to mass-create these components simply due to the fact that I used code snippets.

For those who work with WebStorm, this is not very useful, simply because it does not have such a large ecosystem of plug-ins and, basically, everything is included initially - this is a full-fledged IDE .

VScode extensions / VIM extensions

The situation with the editors of Visual Studio Code and  VIM is different. To get any benefit from them, you need to install plugins. You can spend several days to find all the good plugins and install them - there are a lot of plugins!



I killed an insane amount of time searching for them, which I recommend to you. You can sit for hours, look, look at them, at beautiful animated gifs - a miracle! Write in the comments if you want me to share everything that I have.

There are tools that automatically highlight the complexity of the code, which tests pass, which do not, when you can see the reason for failure directly in the code, which code passed or not, autocomplits, autoprefixes - all this in the plugins.

Here you can spend a lot of time, and we will achieve our goal. Of course, plugins are not a bit relevant to writing code, but imagine that they help us write it.

Refactoring

This is my favorite topic! And so much so that I have a separate report on refactoring: “Refactoring - Where? Where to? When? Where from? Why? Why and How? ” I tell in detail what it is and how to work with it.

I warn you right away , refactoring is not what you usually imagine . Usually, this means: "I improved the code base and added a new feature." This is not refactoring. If you have cognitive dissonance right now, look at the report and it will pass.

AngularJS Grunt -> webpack

About refactoring I want to tell one instructive story. We had a very old AngularJS project, which was built using Grunt with banal concatenation. The project was written during the first and second versions of Angular. Accordingly, everything was very simple there: the files were concatenated, then uglify, and that’s it. At some point, we realized that we had to move to Webpack. We have a huge legacy code base - how to translate it to Webpack?

We made some interesting visits. First, they turned to the lebab.io library .

Lebab.io

This library allows you to convert code from ES5 to ES6, and very well. It takes the old code base and turns it into a new one: inserts imports, uses new lines, classes, sets letand constcorrectly - it does everything for you. In this regard, a very good library.



We installed this plugin, ran the file code through Lebab.io . After that, they just took Mustache templates and the code, which looked different under the new Angular 1.6 and 1.5 with a component approach. With the help of the regulars, we pulled out the necessary pieces, with the help of Mustache we rendered our template in a different way and went through a cycle through all our files.

var object_to_render = {key: «value», ...};
fs.readFile(path_to_mustache_template, function (err, data) { 
if (err) throw err;
var output = Mustache.render(data.toString(), object_to_render);
fs.saveFileSync(path_to_mustache_template);
}):

As a result, we converted a huge amount of legacy code into a modern format and quickly connected Webpack. For me personally, the story is very instructive.

Jsfmt

This is a tool that allows you to format the code base and search on it not with a regular search, but  semantically . We connect our library, file system, read the file and want to find something. Below is an abstract example, we are currently working with Angular.

var jsfmt = require(‘jsfmt’); 
var fs = require(’fs’);
var js = fs.readFileSync(’component.js’);
jsfmt.search(js,"R.Component(a, { dependencies : z })").map((matches, wildcards) => { 
console.log(wildcards.z);
});

This is what our request looks like:

R.Component (a, { dependencies: z })

R/Component- This is its own library Rand a certain one Component.

This part looks very strange:

R.Component (a, { dependencies: z })

This doesn't seem to be valid JavaScript - and it does. We insert small letters, like placeholders, and tell Jsfmt that we are not interested in what is there: an object or an array, a string or a boolean value, null or undefined - it does not matter. It is important for us to get links to  a  and  z , after which, when we go through the entire code base, we will find all variants of  z . For example, we can find all the dependencies of this component. Thanks to this, you can do complex refactoring.

Using the tool, I was able to refactor a huge code base with a semantic approach using trees and analysis.

I didn’t have to write complex queries, complex regulars or parse a syntax tree - I just formed a query and indicated what to change for.

Two additional tools

In refactoring, there is a simple thing that I have to say about. If you want to refactor something, then in the Visual Studio Code, select the code, and there will be hints and refactoring options that are there. For example, an extract method, an inline method.


WebStorm has a context menu that can be called up using a combination of keys, depending on the configuration, and reformed code base.

In general, WebStorm has more commands; it is now more developed than Visual Studio Code.

Testing

Now the most interesting and inspiring :)

Selenium IDE

First a little story. Somehow testers came to me and say:

- We are writing end-to-end tests, we want to automate them, and we have a Selenium IDE.

The Selenium IDE  is just a plugin for Firefox that records your actions in a browser. It remembers all your steps - clicks, scrolls, inputs, transitions, and you can lose these steps again. But that is not all. You can export what you have written, for example, in Java or Python, and run automated end-to-end tests using the Selenium IDE.

It sounds great, but in reality the Selenium IDE by itself does not work perfectly, and besides, at that time we still had ExtJs .

Extjs

If you had ExtJs - sympathize and hug. The Selenium IDE always writes the most unique selector. On our elements, this is id. But ExtJs for each element generates a random id, I don’t know why. This problem with ExtJs comes with the zero version.

ExtJS = 

As a result, our testers opened the application in the morning, recorded everything, then, without reloading the page , periodically ran it, trying to understand if the backend, for example, had broken. They updated the backend, but did not touch the frontend. The main thing was not to click refresh, because after that a new id was generated.

Immediately testers came up with one brilliant idea. Selenium IDE can export its records to HTML format - we can work with HTML, we have templating engines - let's try to do it!

Google Chrome Extension

Quickly created a Google Chrome extension and immediately found a gorgeous method elementFromPoint.

document.elementFromPoint(x, y);

Trite recording the mouse movement on the window and then calling elementFromPoint, when the click worked, I found the coordinates of the element that I clicked on. Further, it was necessary to create a certain selector, somehow to select this element specifically. Id can not be used - what to do?

An idea came up - additionally hang special test-id on components . An abstract test id was created for the component, which was needed only for tests.

data-test-id="ComponentTestId«

It was generated only in a test environment, and we did it selectby the data attribute. But this was not always enough. For example, we have a component, but inside there is still div, span, icon, icon on the i-tag. What to do about it?

For this tail, we additionally generated XPath:

function createXPathFromElement(elm) {
var allNodes = document.getElementsByTagName(’*’);
for (var segs = [ ]; elm && elm.nodeType = 1; elm = elm.parentNode)
{
if (elm.hasAttribute(’class’)) {
segs.unshift(elm.localName.toLowerCase() +
’[a)class = «’ + elm.getAttribute(‘class’) + ‘ »] ‘);
} else {
for (i = 1, sib = elm.previousSibling; sib; sib = sib.previousSibling) {
if (sib.localName = elm.localName) i++; }; 
segs.unshift(elm.localName.toLowerCase() + ’[’ + i + ’]’);
};
};
return segs.length ? ’/’ + segs.join(’/’) : null;
};

As a result, a unique XPath selector is formed, which consists, in a successful case, of the data attribute of the selector by the data attribute with the name of the component:

.//*[@data-test-id=’ComponentName’]/ul/li/div/p[2]

If there was still some kind of complex structure inside the component, everything else stood out according to strict XPath - without id. We avoided id because we worked with ExtJs.

This XPath could be easily tested. We all recorded, exported back to the HTML document, uploaded back to the Selenium IDE, and ran it.



We created the Chrome Extension, which simply generated the Selenium IDE record format, but in its own way, not the way the Selenium IDE does. There we added a lot of smart checks for spinner scrolling, successful application loading - we added additional nuances that the Selenium IDE does not take into account. Thanks to this, we have fully automated end-to-end tests.

The only thing that remained for the testers to do after that was to open any version of the application, click, upload to Selenium IDE, check, save it as a Python code, enjoy the salary and bonus increase and say “thank you” to me.

For unit tests, I can’t please people from the React and VueJS communities - sorry! I do not know about similar tools for React and VueJS - perhaps they are. I will only please those with Angular.

Simontest

There is a SimonTest plugin in Visual Studio Code for Angular.



If you need to write a unit test for your component - point to this component and say to generate the framework of your unit test. After that, all the necessary frame will appear:

• all necessary dependencies will be created, they will be locked and all necessary properties for correct testing will be indicated;
  
• tests for methods with a basic check and basic functionality will be created.
  

All that remains is to add a check of the business logic and some logic of your component, or the business logic of your application, into this component. Just by clicking generation, we get a full framework for unit tests.

Spend time testing - it will be in vain.

Debugging

The first 80% of the time in development is not as scary as the last 80% in debugging.

Where can I spend time on debugging when we still have no exceptions and problems? What at this stage can be interesting to do and spend a lot of time?

Chrome DevTools

Here we can check the performance, get some data and debug our code to understand how it works in reality, especially if the code base is old.



What Debugger Alternatives Do You Know? Full stack or backend programmers are simply required to know the alternative that they use for debugging. There is Profiler, but it is more for determining performance, there are Dumps, but we are interested in working in runtime, and there is a monitoring tool that allows us to understand what is happening and what is going wrong.

Tracing

To begin with - the concept of the tracer: all events are recorded in real time. The entire log of everything is recorded in runtime: there was a click that caused the event, after the event was called - promise, then setTimeout, after setTimeout another promise. All these events are caught by the tracer.

Spy-js vs TraceGL

Initially, there were two main competitors: Spy-js and  TraceGL . These competing tracers could show in real time what is happening with the program. The difference from Debugger is this: let's say your code base consists of a thousand lines - how many times does it need to go through? Long, hard, dreary - and you can’t always catch bugs.

The debugger problem, for example, on a multi-threaded backend - if you start to block, then some things just can not be found. If you have a multi-threaded program that does deadlocks, you will not catch deadlock with the debugger, because events will arrive in a different sequence.

In JS, the same thing happens sometimes, so tracers help. They allow you to see the real picture in real time. You just analyze deadlocks and that’s it.

Spy-js bought WebStorm, cleared the repository, new versions are no longer laid out. Changes appeared only in spy-js. TraceGL bought Mozilla. The developer had huge plans, he promised that a super-tracer will appear in Firefox. TraceGL was cool, but then, apparently, the authorities decided to introduce new features incrementally and they are still being implemented. TraceGL traces in Chrome are not visible and, most likely, will never be.

Rejoice, owners of WebStorm, because that’s where Spy-js is. It is very easy to configure: you create some kind of Spy-js configuration, launch your project, after which you start to catch all the necessary events in real time and you can analyze them. Additionally, WebStorm provides a number of interesting features: it is compatible with TypeScript, CoffeeScript, and additionally displays the latest execution data. If you run the code using Spy-js, after the program has finished, you can see what variables and what values ​​were in your arguments. In this regard, the tool is gorgeous.

В любом новом проекте, в который приходил, я включал трассировщик и через 5 минут знал, как работает проект: архитектура, устройство, элементы взаимодействия, какие события происходят. Несколько минут — и я эксперт в любой кодовой базе, просто потому что в реальном времени видел и понимал, что происходит.

Что теперь у нас в арсенале?

• Мы потратили кучу времени на настройку и написание скриптов для терминала.
  
• Для проектирование мы потратили время на картинки, которые в результате мы все-таки превратили в код, но не в полноценный, а только в каркас бизнес-логики.
  
• Создание проекта. Мы соскафолдили проект с помощью инструментов.
  
• Кодогенерация — сгенерировали некоторое количество кода, базовые компоненты, то есть сделали черновую работу;
  
• We ourselves did not write the code , but at the same time we prepared everything: we installed all the plugins and snippets.
  
• At  refactoring, you can kill an infinite amount of time, and we did it, but used smart tools - this is a bit not what I wanted.
  
• We spent time well on  testing - we created our own test recorder.
  
• You can spend as much time on  debugging as we want! You can debug endlessly.
  

Why did we do all this? I will quote a professional from the cartoon “Wings, Legs and Tails”:

“You won’t take off anyway!” Remember: it’s better to lose a day, then fly in 5 minutes! Forward!

Доклад Алексея — один из лучших на конференции 2018 года. Уже через пару недель пройдет Frontend Conf. в составе РИТ++. Понравилось? Присоединяйтесь! Приходите на Frontend Conf РИТ++ в мае, подписывайтесь на рассылку: новые материалы, анонсы, доступы к видео и больше крутых статей.

Опрос. Стоит ли тратить время на..