Когда нужно сделать код в проекте гибким и удобным, на помощь приходит разделение архитектуры на несколько слоев. Рассмотрим подробнее этот подход и альтернативы, а также поделимся рекомендациями, которые могут быть полезны как начинающим, так и опытным разработчикам Vue.js, React.js, Angular.

В старые времена, когда JQuery только появился, а о фреймворках для серверных языков лишь читали в редких новостях, веб-приложения реализовывали целиком на серверных языках. Зачастую для этого использовали модель MVC (Model-View-Controller): контроллер (controller) принимал запросы, отвечал за бизнес-логику и модели (model) и передавал данные в представление (view), которое рисовало HTML.

Объектно-ориентированное программирование (ООП) на тот момент только начинало формироваться, поэтому разработчики зачастую интуитивно решали, где и какой код надо писать. Таким образом, в мире разработки зародилось такое понятие, как Божественные объекты, которые первоначально отвечали практически за всю работу отдельных частей системы. Например, если в системе была сущность Пользователь, то создавался класс User и в нем писалась вся логика, так или иначе связанная с пользователями. Без разбиения на какие-то ещё файлы. И если приложение было большим, то такой класс мог содержать тысячи строк кода.

Затем появились первые фреймворки, работать с ними стало удобнее, но они не учили, как правильно заложить структуру, архитектуру проекта. И разработчики продолжали писать тысячи строк кода в контроллерах новомодных фреймворков.

1. Выход есть

Как известно, Vue.js, React.js и прочие подобные фреймворки основаны на компонентах. То есть, по большому счету, приложение состоит из множества компонентов, которые могут заключать в себе и бизнес-логику и представление и много чего еще. Таким образом, разработчики во многих проектах пишут всю логику в компонентах и эти компоненты, как правило, начинают напоминать те самые божественные классы из прошлого. То есть, если компонент описывает какую-то крупную часть функционала с большим количеством (возможно сложной) логики, то вся эта логика и остается в компоненте. Появляются десятки методов и тысячи строк кода. А если учесть то, что, например, во Vue.js еще есть такие понятия как computed, watch, mounted, created, то логику пишут еще и во все эти части компонента. В итоге, чтобы найти какую-то часть кода, отвечающую за клик по кнопке, надо перелистать десяток экранов js-кода, бегая между methods, computed и прочими частями компонента.

Примерно в 2008 году, применительно к backend, была предложена слоистая архитектура. Основная идея этой архитектуры заключается в том, что весь код приложения следует разбивать на определенные слои, которые выполняют определенную работу и не очень знают о других слоях.

С подобным разбиением приложение становится намного проще поддерживать, писать тесты, искать ответственные зоны и вообще читать код.

Вот о таком разбиении кода на слои и пойдет речь, но уже применительно к frontend-фреймворкам, таким как Vue.js, React.js и прочим.

Изначальная теория слоистой архитектуры, применительно к backend, имеет много ограничений и правил. Идея же этой статьи в том, чтобы перенять именно разбиение кодовой базы на слои. Схематично ее можно изобразить примерно так.

2. Создание удобной архитектуры приложения

Рассмотрим пример, в котором вся логика находится в одном компоненте.

2.1. Логика в компоненте

Рассматриваемый компонент отвечает за работу с коллажами, в частности за дублирование, восстановление и удаление. В нем уже используются некоторые сервисы, но все равно в компоненте много бизнес-логики.

methods: {    duplicateCollage (collage) {      this.$store.dispatch('updateCollage', { id: collage.id, isDuplicating: true })      dataService.duplicateCollage(collage, false)        .then(duplicate => {          this.$store.dispatch('updateCollage', { id: collage.id, isDuplicating: false })        })        .catch(() => {          this.$store.dispatch('updateCollage', { id: collage.id, isDuplicating: false })          this.$store.dispatch('errorsSet', { api: `We couldn't duplicate collage. Please, try again later.` })        })    },    deleteCollage (collage, index) {      this.$store.dispatch('updateCollage', { id: collage.id, isDeleting: true })      photosApi.deleteUserCollage(collage)        .then(() => {          this.$store.dispatch('updateCollage', {            id: collage.id,            isDeleting: false,            isDeleted: true          })          this.$store.dispatch('setUserCollages', { total: this.userCollages.total - 1 })          this.$store.dispatch('updateCollage', {            id: collage.id,            deletingTimer: setTimeout(() => {              this.$store.dispatch('updateCollage', { id: collage.id, deletingTimer: null })              this.$store.dispatch('setUserCollages', { items: this.userCollages.items.filter(userCollage => userCollage.id !== collage.id) })               // If there is no one collages left - show templates              if (!this.$store.state.editor.userCollages.total) {                this.currentTabName = this.TAB_TEMPLATES              }            }, 3000)          })        })    },    restoreCollage (collage) {      clearTimeout(collage.deletingTimer)      photosApi.saveUserCollage({ collage: { deleted: false } }, collage.id)        .then(() => {          this.$store.dispatch('updateCollage', {            id: collage.id,            deletingTimer: null,            isDeleted: false          })          this.$store.dispatch('setUserCollages', { total: this.userCollages.total + 1 })        })    }}

2.2. Создание слоя сервисов для бизнес-логики

Для начала можно ввести в приложение сервисный слой, который будет отвечать за бизнес-логику.

Один из классических способов хоть какого-то разбиения логики это деление на сущности. Например, почти всегда в проекте есть сущность Пользователь или, как в описываемом примере, Коллаж. Таким образом, можно создать папку services и в ней файлы user.js и collage.js. Такие файлы могут быть статическими классами или просто возвращать функции. Главное чтобы вся бизнес-логика, связанная с сущностью, была в этом файле.

services  |_collage.js  |_user.js

В сервис collage.js следует поместить логику дублирования, восстановления и удаления коллажей.

export default class Collage {  static delete (collage) {    // ЛОГИКА УДАЛЕНИЯ КОЛЛАЖА  }   static restore (collage) {    // ЛОГИКА ВОССТАНОВЛЕНИЯ  КОЛЛАЖА  }   static duplicate (collage, changeUrl = true) {    // ЛОГИКА ДУБЛИРОВАНИЯ КОЛЛАЖА  }}

2.3. Использование сервисов в компоненте

Тогда в компоненте надо будет лишь вызвать соответствующие функции сервиса.

methods: {  duplicateCollage (collage) {    CollageService.duplicate(collage, false)  },  deleteCollage (collage) {    CollageService.delete(collage)  },  restoreCollage (collage) {    CollageService.restore(collage)  }}

С таким подходом методы в компоненте будут состоять из одной или нескольких строчек кода, а логика, связанная с коллажами, будет инкапсулирована в соответствующем файле collage.js, а не размазана по огромному компоненту, соответственно, будет проще искать нужный код, поддерживать его и писать тесты. Еще один плюс такого подхода в том, что код из сервисов можно переиспользовать в любом месте проекта.

Также многие разработчики на пути к удобной архитектуре выносят вызовы методов API в отдельный файл (файлы). Это как раз создание слоя вызовов API, которое также приводит к удобству и структурированности кода.

import axios from '@/plugins/axios' export default class Api {   static login (email, password) {    return axios.post('auth/login', { email, password })      .then(response => response.data)  }   static logout () {    return axios.post('auth/logout')  }   static getCollages () {    return axios.get('/collages')      .then(response => response.data)  }    static deleteCollage (collage) {    return axios.delete(`/collage/${collage.id}`)      .then(response => response.data)  }    static createCollage (collage) {    return axios.post(`/collage/${collage.id}`)      .then(response => response.data)  }}

3. Что и куда выносить?

На вопрос, что же именно и куда выносить, однозначно ответить невозможно. Как вариант, можно разбить код на три условные части: бизнес-логика, логика и представление.

Бизнес-логика это все то, что описано в требованиях к приложению. Например, ТЗ, документации, дизайны. То есть все то, что напрямую относится к предметной области приложения. Примером может быть метод UserService.login() или ListService.sort(). Для бизнес-логики можно создать сервисный слой с сервисами.

Логика это тот код, который не имеет прямого отношения к предметной области приложения и его бизнес-логике. Например, создание уникальной строки или поиск некоего объекта в массиве. Для логики можно создать слой хэлперов: например, папку helpers и в ней файлы string.js, converter.js и прочие.

Представление все то, что непосредственно связано с компонентом и его шаблоном. Например, изменение реактивных свойств, изменение состояний и прочее. Этот код пишется непосредственно в компонентах (methods, computed, watch и так далее).

login (email, password) {  this.isLoading = true  userService.login(email, password)    .then(user => {      this.user = user      this.isLoading = false    })}

Далее в компонентах надо будет вызывать сервисы, а сервисы будут использовать хэлперы. Такой подход предоставит нам легкие, маленькие и простые компоненты, а вся логика будет находиться в логически понятных файлах.

Если же сервисы или хэлперы начнут разрастаться, то сущности всегда можно разделить на другие сущности. К примеру, если у пользователя в приложении маленький функционал в 3-5 методов и пара методов про заказы пользователя, то разработчик может вынести всю эту бизнес-логику в сервис user.jsрешить всю эту бизнес-логику написать в сервисе user.js. Если же у сервиса пользователя сотни строк кода, то можно все, что относится к заказам, вынести в сервис order.js.

4. От простого к сложному

В идеале можно сделать архитектуру на ООП, в которой будут, помимо сервисов, еще и модели. Это классы, описывающие сущности приложения. Те же User или Collage. Но использоваться они будут вместо обычных объектов данных.

Рассмотрим список пользователей.

Классический способ вывода ФИО пользователей выглядит так.

<template><div class="users">  <div    v-for="user in users"    class="user"  >    {{ getUserFio(user) }}  </div></div></template> <script>import axios from '@/plugins/axios' export default {  data () {    return {      users: []    }  },  mounted () {    this.getList()  },  methods: {    getList() {      axios.get('/users')        .then(response => this.users = response.data)    },    getUserFio (user) {      return `${user.last_name} ${user.first_name} ${user.third_name}`    }  }}</script>

Функцию получения ФИО можно вынести для того, чтобы легко и просто переиспользовать при необходимости.

Для начала следует создать модель Пользователь.

export default class User {  constructor (data = {}) {    this.firstName = data.first_name    this.secondName = data.second_name    this.thirdName = data.third_name  }   getFio () {    return `${this.firstName} ${this.secondName} ${this.thirdName}`  }}

Далее следует импортировать эту модель в компонент.

import UserModel from '@/models/user'

С помощью сервиса получить список пользователей и преобразовать каждый объект в массиве в объект класса (модели) User.

methods: {   getList() {     const users = userService.getList()     users.forEach(user => {       this.users.push(new UserModel(user))     })   },

Таким, образом, в шаблоне или в методах не надо будет создавать какие-то отдельные функции для работы с объектом пользователя, они будут уже внутри этого объекта.

<template><div class="users">  <div    v-for="user in users"    class="user"  >    {{ user.getFio() }}  </div></div></template>

К вопросу о том, какую логику выносить в модели, а какую в сервисы. Можно всю логику поместить в сервисы, а в моделях вызывать сервисы. А можно в моделях хранить логику, относящуюся непосредственно к сущности модели (тот же getFio()), а логику работы с массивами сущностей хранить в сервисах (тот же getList()). Как будет удобнее.

5. Заключение

Если в проекте большое количество логики хранится в компонентах, есть риск сделать их трудночитаемыми и осложнить дальнейшее переиспользование логики. В таких случаях можно ввести слои для вынесения этой логики: например, слой сервисов для бизнес-логики, слой хэлперов для остальной логики. Внутри компонента стоит оставить ту логику, которая относится непосредственно к нему и его шаблону.

Также для удобства можно создать слои для операций с сессиями, перехватчиками (interceptors) api, глобальными обработчиками ошибок смотря что вам будет удобно. Таким образом, вы сделаете компоненты маленькими и простыми, а логика будет хранитьсятам, где ее легко будет найти и переиспользовать в любом месте проекта.

Спасибо за внимание! Будем рады ответить на ваши вопросы.

У каждого из вас может возникнуть потребность поработать с графикой при создании React-приложения. Или вам нужно будет отрендерить большое количество элементов, причем сделать это качественно и добиться высокой производительности при перерисовке элементов. Это может быть анимация либо какой-то интерактивный компонент. Естественно, первое, что приходит в голову это Canvas. Но тут возникает вопрос: Какой контекст использовать?. У нас есть выбор 2d-контекст либо WebGl. А как на счёт 2d-графики? Тут уже не всё так очевидно.

При работе над задачами с высокой производительностью мы попробовали оба решения, чтобы на практике определиться, какой из двух контекстов будет эффективнее. Как и ожидалось, WebGl победил 2d-контекст, поэтому кажется, что выбор прост.

Но тут возникает проблема. Вы сможете ощутить её, если начнете работать с документацией WebGl. С первых мгновений становится понятно, что она слишком низкоуровневая, в отличие от 2d context. Поэтому, чтобы не писать тонны кода, перед нами встаёт очевидное решение использование библиотеки. Для реализации этой задачи подходят библиотеки pixi.js и three.js с качественной документацией, большим количеством примеров и крупным комьюнити разработчиков.

Pixi.js или three.js

На первый взгляд, выбрать подходящий инструмент несложно: используем pixi.j для 2d-графиков, а three.js для 3d. Однако, чем 2d отличается от 3d? По сути дела, отсутствием 3d-перспективы и фиксированным значением по третьей координате. Для того чтобы не было перспективы, мы можем использовать ортографическую камеру.

Вероятно, вы спросите: Что за камера?. Camera это одно из ключевых понятий при реализации графики, наряду со scene и renderer. Для наглядности приведу аналогию. Представим, что вы стоите в комнате, держите в руках смартфон и снимаете видеоролик. Та комната, в которой вы снимаете видео это scene. В комнате могут быть различные предметы, например, стол и стулья это объекты на scene. В роли camera выступает камера смартфона, в роли renderer матрица смартфона, которая проецирует 3d-комнату на 2d-экран.

Ортографическая камера отличается от перспективной, которая и используется в реальной жизни, тем, что дальние объекты в ней имеют тот же размер, что и ближние. Другими словами, если вы будете отходить от камеры, то в перспективной камере вы будете становиться меньше, а в ортографической останетесь такими же. Можно сказать, что в этой камере нет координаты z, но это не совсем так. Она есть, но она управляет наложением одного объекта на другой.

Таким образом, three.js также подходит для 2d-графики. Так что же в итоге выбрать? Мы попробовали оба варианта и выявили на практике несколько преимуществ three.js.

• Во-первых, нам нужно было выполнить интерактивное взаимодействие с элементами на сцене. Написать собственную реализацию достаточно трудозатратно, но в обеих библиотеках уже есть готовые решения: в pixi.js из коробки, в three.js библиотека three.interaction.

Казалось бы, в этом плане библиотеки равноценны, но это лишь первое впечатление. Особенность реализации интерактивности в pixi.js предполагает, что интерактивные элементы должны иметь заливку. Но как быть с линейными графиками? У них же нет заливки. Без собственного решения в этом случае не обойтись. Что же касается three.js, то тут этой проблемы нет, и линейные графики также интерактивны.

• Еще одна задача это экспорт в SVG. Нам нужно было реализовать функциональность, которая позволит экспортировать в SVG то, что мы видим на сцене, чтобы потом это изображение можно было использовать в печати. В three.js для этого есть готовый пример, а вот в pixi.js нет.

• Ну и будем честны с собой, в three.js больше примеров реализации тех или иных задач. К тому же, изучив эту библиотеку, при желании мы можем работать с 3d-графикой, а вот в случае pixi.js такого преимущества у нас нет.

Исходя из всего вышеописанного, наш выбор очевиден это three.js.

Three.js и React

После выбора библиотеки мы сталкиваемся с новой дилеммой использовать react-обертку или каноническую three.js.

Для react есть реализация обёртки это react-three-fiber. На первый взгляд, в ней довольно мало документации, что может показаться проблемой. Действительно, при переносе кода из примеров three.js в react-three-fiber возникает много вопросов по синтаксису.

Однако, на практике все не так уж сложно. У этой библиотеки есть обёртка drei с неплохим storybook с готовой реализацией множества различных примеров. Впрочем, всё, что за находится пределами этой реализации, по-прежнему может причинять боль.

Еще одна проблема это жёсткая привязка к react. А если мы отлично реализуем view с графикой и захотим использовать где-то ещё? В таком случае снова придётся поработать.

Учитывая эти факторы, мы решили использовать каноническую three.js и написать свою собственную обертку на хуках. Если вы не хотите перебирать множество вариантов реализации, попробуйте использовать нативные ES6 классы это хорошее и производительное решение.

Вот пример нашей архитектуры. В центре сцены нарисован квадрат, который при нажатии на него меняет цвет с синего на серый и с серого на синий.

Создаём класс three.js для работы с библиотекой three.js. По сути, всё взаимодействие с ней будет проходить в объекте данного класса.

class Three {  constructor({    canvasContainer,    sceneSizes,    rectSizes,    color,    colorChangeHandler,  }) {    // Для использования внутри класса добавляем параметры к this    this.sceneSizes = sceneSizes;    this.colorChangeHandler = colorChangeHandler;     this.initRenderer(canvasContainer); // создание рендерера    this.initScene(); // создание сцены    this.initCamera(); // создание камеры    this.initInteraction(); // подключаем библиотеку для интерактивности    this.renderRect(rectSizes, color); // Добавляем квадрат на сцену    this.render(); // Запускаем рендеринг  }   initRenderer(canvasContainer) {    // Создаём редерер (по умолчанию будет использован WebGL2)    // antialias отвечает за сглаживание объектов    this.renderer = new THREE.WebGLRenderer({antialias: true});     //Задаём размеры рендерера    this.renderer.setSize(this.sceneSizes.width, this.sceneSizes.height);     //Добавляем рендерер в узел-контейнер, который мы прокинули извне    canvasContainer.appendChild(this.renderer.domElement);  }   initScene() {    // Создаём объект сцены    this.scene = new THREE.Scene();     // Задаём цвет фона    this.scene.background = new THREE.Color("white");  }   initCamera() {    // Создаём ортографическую камеру (Идеально подходит для 2d)    this.camera = new THREE.OrthographicCamera(      this.sceneSizes.width / -2, // Левая граница камеры      this.sceneSizes.width / 2, // Правая граница камеры      this.sceneSizes.height / 2, // Верхняя граница камеры      this.sceneSizes.height / -2, // Нижняя граница камеры      100, // Ближняя граница      -100 // Дальняя граница    );     // Позиционируем камеру в пространстве    this.camera.position.set(      this.sceneSizes.width / 2, // Позиция по x      this.sceneSizes.height / -2, // Позиция по y      1 // Позиция по z    );  }   initInteraction() {    // Добавляем интерактивность (можно будет навешивать обработчики событий)    new Interaction(this.renderer, this.scene, this.camera);  }   render() {    // Выполняем рендеринг сцены (нужно запускать для отображения изменений)    this.renderer.render(this.scene, this.camera);  }   renderRect({width, height}, color) {    // Создаём геометрию - квадрат с высотой "height" и шириной "width"    const geometry = new THREE.PlaneGeometry(width, height);     // Создаём материал с цветом "color"    const material = new THREE.MeshBasicMaterial({color});     // Создаём сетку - квадрат    this.rect = new THREE.Mesh(geometry, material);     //Позиционируем квадрат в пространстве    this.rect.position.x = this.sceneSizes.width / 2;    this.rect.position.y = -this.sceneSizes.height / 2;     // Благодаря подключению "three.interaction"    // мы можем навесить обработчик нажатия на квадрат    this.rect.on("click", () => {      // Меняем цвет квадрата      this.colorChangeHandler();    });     this.scene.add(this.rect);  }   // Служит для изменения цвета квадрат  rectColorChange(color) {    // Меняем цвет квадрата    this.rect.material.color.set(color);     // Запускаем рендеринг (отобразится квадрат с новым цветом)    this.render();  }}

А теперь создаём класс ThreeContauner, который будет React-обёрткой для нативного класса Three.

import {useRef, useEffect, useState} from "react"; import Three from "./Three"; // Размеры сцены и квадратаconst sceneSizes = {width: 800, height: 500};const rectSizes = {width: 200, height: 200}; const ThreeContainer = () => {  const threeRef = useRef(); // Используется для обращения к контейнеру для canvas  const three = useRef(); // Служит для определения, создан ли объект, чтобы не создавать повторный  const [color, colorChange] = useState("blue"); // Состояние отвечает за цвет квадрата   // Handler служит для того, чтобы изменить цвет  const colorChangeHandler = () => {    // Просто поочерёдно меняем цвет с серого на синий и с синего на серый    colorChange((prevColor) => (prevColor === "grey" ? "blue" : "grey"));  };   // Создание объекта класса Three, предназначенного для работы с three.js  useEffect(() => {    // Если объект класса "Three" ещё не создан, то попадаем внутрь    if (!three.current) {      // Создание объекта класса "Three", который будет использован для работы с three.js      three.current = new Three({        color,        rectSizes,        sceneSizes,        colorChangeHandler,        canvasContainer: threeRef.current,      });    }  }, [color]);   // при смене цвета вызывается метод объекта класса Three  useEffect(() => {    if (three.current) {      // Запускаем метод, который изменяет в цвет квадрата      three.current.rectColorChange(color);    }  }, [color]);   // Данный узел будет контейнером для canvas (который создаст three.js)  return <div className="container" ref={threeRef} />;}; export default ThreeContainer;

А вот пример работы данного приложения.

При первом открытии мы получаем, как и было описано ранее, синий квадрат в центре сцены, которая имеет серый цвет.

После нажатия на квадрат он меняет цвет и становится белым.

Как мы видим, использование нативного three.js внутри React-приложения не вызывает каких-либо проблем, и этот подход достаточно удобен. Однако, на плечи разработчика в этом случае ложится нагрузка, связанная с добавлением/удалением узлов со сцены. Таким образом, теряется тот подход, который берёт на себя virtual dom внутри React-приложения. Если вы не готовы с этим мириться, обратите внимание на библиотеку react-three-fiber в связке с библиотекой drei этот способ позволяет мыслить в контексте React-приложения.

Рассмотрим реализованный выше пример с использованием этих библиотек:

import {useState} from "react";import {Canvas} from "@react-three/fiber";import {Plane, OrthographicCamera} from "@react-three/drei"; // Размеры сцены и квадратаconst sceneSizes = {width: 800, height: 500};const rectSizes = {width: 200, height: 200}; const ThreeDrei = () => {  const [color, colorChange] = useState("blue"); // Состояние отвечает за цвет квадрата   // Handler служит для того, чтобы  const colorChangeHandler = () => {    // Просто поочерёдно меняем цвет с серого на синий и с синего на белый    colorChange((prevColor) => (prevColor === "white" ? "blue" : "white"));  };   return (    <div className="container">      {/* Здесь задаются параметры, которые отвечают за стилизацию сцены */}      <Canvas className="container" style={{...sceneSizes, background: "grey"}}>        {/* Камера задаётся по аналогии с нативной three.js, но нужно задать параметр makeDefault,         чтобы применить именно её, а не камеру заданную по умолчанию */}        <OrthographicCamera makeDefault position={[0, 0, 1]} />        <Plane          // Обработка событий тут из коробки          onClick={colorChangeHandler}          // Аргументы те же и в том же порядке, как и в нативной three.js          args={[rectSizes.width, rectSizes.height]}        >          {/* Материал задаётся по аналогии с нативной three.js,               но нужно использовать attach для указания типа прикрепления узла*/}          <meshBasicMaterial attach="material" color={color} />        </Plane>      </Canvas>    </div>  );}; export default ThreeDrei;

Как видите, кода стало гораздо меньше и он стал более прозрачным, с точки зрения его чтения. Однако, как уже упоминалось выше, в этом случае разработчику доступноменьше примеров реализации различных компонентов. Кроме того, в процессе изучения некоторые особенности работы могут не быть очевидными, что заставляет подумать над их реализацией.

В этой статье мы с вами рассмотрели два подхода в использовании библиотеки three.js внутри React-приложения. Каждый из этих подходов имеет свои плюсы и минусы, поэтому выбор за вами.

Спасибо за внимание! Надеемся, что наш опыт был для вас полезен.

В своих проектах мы стараемся по мере необходимости покрывать код тестами и придерживаться принципов SOLID и чистой архитектуры. Хотим поделиться с читателями Хабра переводом статьи Hannes Dorfmann автора серии публикаций об Android-разработке. В этой статье описан способ, который помогает абстрагировать работу со строками, чтобы скрыть детали взаимодействия с разными типами строковых ресурсов и облегчить написание юнит-тестов.

Если вы работаете над большим Android-приложением и предполагаете, что в коде может появиться путаница в работе с ресурсами из разных источников, или если хотите упростить написание тестов в отношении строк, то эта статья может быть вам полезна. Переводим с разрешения автора.

Подбирать подходящую абстракцию нелегко. В этой статье я хотел бы поделиться техникой, которая хорошо работает у меня и моих товарищей по команде Android при операциях со строковыми ресурсами на Android.

Уровень абстракции для строк?

Нужна ли вообще абстракция для работы со строками на Android? Возможно, не нужна, если ваше приложение достаточно простое. Но чем более гибким должно быть приложение при отображении текстовых данных, тем скорее вы поймете, что существуют разные типы строковых ресурсов, и чтобы изящно оперировать всеми этими типами в своем коде, вам, возможно, понадобится еще один уровень абстракции. Давайте я объясню, что я имею в виду под разными типами строковых ресурсов:

• Простой строковый ресурс вроде R.string.some_text, отображаемый на экране с помощью resources.getString(R.string.some_text)

• Отформатированная строка, которая форматируется во время выполнения, т.е. context.getString(R.string.some_text, arg1, 123) с

<string name=some_formatted_text>Some formatted Text with args %s %i</string>

• Более сложные строковые ресурсы, такие как Plurals, которые перегружены, например resources.getQuantityString(R.plurals.number_of_items, 2):

<plurals name="number_of_items">  <item quantity="one">%d item</item>  <item quantity="other">%d items</item></plurals>

• Простой текст, который не загружается из ресурсов Android в XML-файле вроде strings.xml, а уже загружен в переменную типа String и не требует дальнейшего преобразования (в отличие от R.string.some_text). Например, фрагмент текста, извлеченный из json ответа с сервера.

Вы обратили внимание, что для загрузки этих видов строк нужно вызывать разные методы с разными параметрами, чтобы фактически получить строковое значение? Для элегантной работы с ними следует подумать о введении слоя абстракции для строк. Для этого надо учитывать следующие моменты:

1. Мы не хотим раскрывать подробности реализации, например, какой метод вызвать для фактического преобразования ресурса в строку.

2. Нам нужно сделать текст объектом первого класса (если это возможно) слоя бизнес-логики, а не слоя пользовательского интерфейса, чтобы слой представления мог легко его визуализировать.

Давайте шаг за шагом рассмотрим эти моменты на конкретном примере: предположим, мы хотим загружать строку с сервера по http, и если это не удается, мы отображаем аварийную fallback-строку из strings.xml. Например, так:

class MyViewModel(  private val backend : Backend,  private val resources : Resources // ресурсы Android из context.getResources()) : ViewModel() {  val textToDisplay : MutableLiveData<String>  // MutableLiveData используется для удобства чтения   fun loadText(){    try {      val text : String = backend.getText()       textToDisplay.value = text    } catch (t : Throwable) {      textToDisplay.value = resources.getString(R.string.fallback_text)    }  }}

Детали реализации просочились в нашу MyViewModel, что в целом усложняет ее тестирование. Действительно, чтобы написать тест для loadText(), нам надо либо замокать Resources, либо ввести интерфейс наподобие StringRepository (по шаблону "репозиторий"), чтобы при тестировании мы могли заменить его другой реализацией:

interface StringRepository{  fun getString(@StringRes id : Int) : String} class AndroidStringRepository(  private val resources : Resources // ресурсы Android из context.getResources()) : StringRepository {  override fun getString(@StringRes id : Int) : String = resources.getString(id)} class TestDoubleStringRepository{    override fun getString(@StringRes id : Int) : String = "some string"}

Затем вью-модель получит StringRepository вместо непосредственно ресурсов, и в этом случае все будет в порядке, не так ли?

class MyViewModel(  private val backend : Backend,  private val stringRepo : StringRepository // детали реализации скрываются за интерфейсом) : ViewModel() {  val textToDisplay : MutableLiveData<String>     fun loadText(){    try {      val text : String = backend.getText()       textToDisplay.value = text    } catch (t : Throwable) {      textToDisplay.value = stringRepo.getString(R.string.fallback_text)    }  }}

На эту вью-модель можно написать такой юнит-тест:

@Testfun when_backend_fails_fallback_string_is_displayed(){  val stringRepo = TestDoubleStringRepository()  val backend = TestDoubleBackend()  backend.failWhenLoadingText = true // заставит backend.getText() выкинуть исключение  val viewModel = MyViewModel(backend, stringRepo)  viewModel.loadText()   Assert.equals("some string", viewModel.textToDisplay.value)}

С введением interface StringRepository мы добавили уровень абстракции и решили задачу, верно? Нет. Мы добавили уровень абстракции, но реальная проблема все еще перед нами:

• StringRepository не учитывает тот факт, что существуют другие типы текста (см. перечисление в начале этой статьи). Это проявляется в том, что код нашей вью-модели все еще трудно поддерживать, потому что она явно знает, как преобразовывать разные типы текста в String. Вот где нам на самом деле нужна хорошая абстракция.

• Кроме того, если рассматривать реализацию TestDoubleStringRepository и тест, который мы написали, насколько он является значимым? TestDoubleStringRepository всегда возвращает одну и ту же строку. Мы могли бы совершенно испортить код вью-модели, передавая R.string.foo вместо R.string.fallback_text в StringRepository.getString(), и наш тест все равно бы был пройден. Конечно, можно улучшить TestDoubleStringRepository, чтобы он не просто всегда возвращал одну и ту же строку:

class TestDoubleStringRepository{    override fun getString(@StringRes id : Int) : String = when(id){      R.string.fallback_test -> "some string"      R.string.foo -> "foo"      else -> UnsupportedStringResourceException()    }}

Но насколько это поддерживаемо? Вы хотели бы так делать для всех строк в вашем приложении (если их у вас сотни)?

Есть более удачный вариант, который позволяет решить обе эти проблемы с помощью одной абстракции.

Нам поможет TextResource

Придуманная нами абстракция называется TextResource. Это модель для представления текста, которая относится к слою domain. Таким образом, это объект первого класса в нашей бизнес-логике. И выглядит это следующим образом:

sealed class TextResource {  companion object { // Используется для статических фабричных методов, чтобы файл с конкретной реализацией оставался приватным    fun fromText(text : String) : TextResource = SimpleTextResource(text)    fun fromStringId(@StringRes id : Int) : TextResource = IdTextResource(id)    fun fromPlural(@PluralRes id: Int, pluralValue : Int) : TextResource = PluralTextResource(id, pluralValue)  }} private data class SimpleTextResource( // Можно будет также использовать inline классы  val text : String) : TextResource() private data class IdTextResource(  @StringRes id : Int) : TextResource() private data class PluralTextResource(    @PluralsRes val pluralId: Int,    val quantity: Int) : TextResource() // можно будет добавить и другие виды текста...

Так выглядит вью-модель с TextResource:

class MyViewModel(  private val backend : Backend // Обратите, пожалуйста, внимание, что не надо передавать ни какие-то ресурсы, ни StringRepository.) : ViewModel() {  val textToDisplay : MutableLiveData<TextResource> // Тип уже не String     fun loadText(){    try {      val text : String = backend.getText()       textToDisplay.value = TextResource.fromText(text)    } catch (t : Throwable) {      textToDisplay.value = TextResource.fromStringId(R.string.fallback_text)    }  }}

Основные отличия:

1) textToDisplay поменялся c LiveData<String> на LiveData<TextResource>, поэтому теперь вью-модели не нужно знать, как переводить разные типы текста в String. Она должна уметь переводить их в TextResource. Однако, это нормально, как будет видно далее, TextResource это абстракция, которая решит наши проблемы.

2) Посмотрите на конструктор вью-модели. Нам удалось удалить неправильную абстракцию StringRepository (при этом нам не нужны Resources). Вас, возможно, интересует, как теперь писать тесты? Так же просто, как напрямую протестировать TextResource. Дело в том, что эта абстракция также абстрагирует зависимости Android, такие как ресурсы или контекст (R.string.fallback_text это просто Int). И вот как выглядит наш юнит-тест:

@Testfun when_backend_fails_fallback_string_is_displayed(){  val backend = TestDoubleBackend()  backend.failWhenLoadingText = true // заставит backend.getText() выкинуть исключение  val viewModel = MyViewModel(backend)  viewModel.loadText()   val expectedText = TextResource.fromStringId(R.string.fallback_text)  Assert.equals(expectedText, viewModel.textToDisplay.value)  // для data class-ов генерируются методы equals, поэтому мы легко можем их сравнивать}

Пока все хорошо, но не хватает одной детали: как нам преобразовать TextResource в String, чтобы можно было отобразить его, например, в TextView? Что ж, это касается исключительно отрисовки в Android, и мы можем создать функцию расширения и заключить ее в слое UI.

// Можно получить ресурсы с помощью context.getResources()fun TextResource.asString(resources : Resources) : String = when (this) {   is SimpleTextResource -> this.text // smart cast  is IdTextResource -> resources.getString(this.id) // smart cast  is PluralTextResource -> resources.getQuantityString(this.pluralId, this.quantity) // smart cast}

А поскольку преобразование TextResource в String происходит в UI (на уровне представления) архитектуры нашего приложения, TextResource будет переводиться при изменении конфигурации (т.е. при изменении системного языка на смартфоне), что обеспечит правильную локализацию строки для любых ресурсов R.string.* вашего приложения.

Бонус: вы можете легко написать юнит-тест для TextResource.asString(), создавая моки для ресурсов. При этом не следует создавать мок для каждого отдельного строкового ресурса в приложении, потому что на самом деле нужно протестировать всего лишь работу конструкции when. Поэтому здесь будет корректно всегда возвращать одну и ту же строку из замоканного resources.getString(). Кроме того, TextResource можно многократно использовать в коде, и он соответствует принципу открытости/закрытости. Так, его можно расширить для будущих вариантов использования, добавив всего несколько строк кода: новый класс данных, который расширяет TextResource, и новую ветку в конструкцию when в TextResource.asString().

Поправка: как правильно подметили в комментариях, TextResource не следует принципу открытости/закрытости. Можно было бы поддержать принцип открытости/закрытости для TextResource, если бы у sealed class TextResouce была abstract fun asString(r: Resources), которую реализуют все подклассы. Я лично считаю, что можно пожертвовать принципом открытости/закрытости в пользу упрощения структур данных и работать с расширенной функцией asString(r: Resources), которая находится за пределами иерархии наследования (именно этот способ описан в статье и является достаточно расширяемым, хотя и не настолько, как с принципом открытости/закрытости). Почему? Я считаю, что добавление функции с параметром Resources к публичному API TextResource проблематично, потому что только часть подклассов нуждается в этом параметре (например, SimpleTextResource такого вообще не требует). Кроме того, если такая реализация станет частью общедоступного API, это может привести к увеличению накладных расходов на поддержку кода, а также к появлению дополнительных сложностей (особенно при тестировании).

Выводы

Описанный в статье способ можно применять для работы со строками и другими ресурсами: dimens, изображениями, цветами. При этом в каждом случае важно анализировать, насколько уместна работа с абстракциями. Хотя злоупотреблять ими нежелательно, в некоторых случаях абстракции могут быть полезны в том числе, как мы уже упоминали, для более простого написания тестов. Ждем ваших отзывов об этом методе и его практическом применении!

Бывают ситуации, когда компании-заказчику нужно рассчитать сроки реализации IT-проекта как можно быстрее например, на старте переговоров с инвесторами. Однако, даже быстрая оценка должна содержать все предстоящие трудозатраты: на разработку, тестирование, управление и возможные риски рисковый резерв. В этой статье мы рассмотрим процесс оценки на примере веб- и мобильных проектов.

Как происходит оценка проекта

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

• созваниваться с клиентом для уточнения требований, согласования вариантов решения и стека технологий;

• курировать процесс оценки;

• предлагать варианты реализации;

• оценивать и закладывать риски;

• определять состав команды разработки;

• составлять предварительный роадмап проекта.

Подробная оценка занимает в среднем 3-5 рабочих дней. За это время мы определяем возможные ограничения и риски, стек технологий, состав команды, ориентировочные сроки работы и ее стоимость. После этого переходим к обсуждению оценки с клиентом. По нашим наблюдениям, на этом этапе могут происходить различные уточнения по следующим причинам:

• требования клиента изменились, например, он подготовил более детальное ТЗ и макеты;

• была выявлена необходимость реализовать продукт поэтапно, начиная с MVP, с учетом бюджета или дедлайнов;

• иногда нужно изменить технологический стек, если клиент сообщает новые бизнес-задачи или особенности инфраструктуры.

Риски и трудозатраты на управление

При оценке нужно учитывать трудозатраты на управление проектом (Project Management или PM), в том числе:

• распределение и контроль выполнения задач

• проведение митингов;

• коммуникации с заказчиком продукта и устранение препятствий;

• ретроспективы с командой;

• демо с заказчиком;

• работа с метриками и оценка рисков.

Проектный менеджер при реализации проекта отслеживает любые риски, которые могут повлиять на сроки и стоимость выполнения работ. При этом некоторые риски можно выявить уже на ранних этапах, например:

• команда часто перерабатывает, причем больше, чем на 10-15%;

• ТЗ постоянно меняется, а тестовая документация при этом не обновляется;

• фактическое время выполнения задачи сильно превышает планируемое.

В целом, работа с рисками это тема вечных споров о том, как их минимизировать и как правильно вести расчеты. Рассмотрим, как могут отличаться трудозатраты, на примере двух видов приложений из нашей практики.

Оценка трудозатрат

При разработке тех или иных новых модулей команде предстоит выполнить различные виды работ, в зависимости от типа проекта:

1. Приемка приложения

2. Аналитика и дизайн

3. Непосредственная разработка и интеграция с другими IT-системами

4. Тестирование и обеспечение качества (QA)

Мы поставили перед собой задачу выяснить, как в среднем распределяются трудозатраты по фазам разработки. Для этого мы проанализировали выборку веб- и мобильных MVP-проектов, разработанных в 2020 году. Трудозатраты на их реализацию составили от 2000 до 4500 часов.

Веб-приложение

Мы посчитали, в каком соотношении в этих проектах распределялись трудозатраты по разным видам работ (в процентах):

• Аналитика 7%

• Backend 30%

• Frontend 24,6%

• Тестирование 15%

• Управление 22%

Как показывает практика, разработка занимает около 50-60% от общих сроков реализации веб-приложения.

Таким образом, вы можете очень приблизительно посчитать часы непосредственно на разработку и умножить их на 2, чтобы в первом приближении оценить, сколько времени вам понадобится. При этом, конечно, каждый проект желательно оценивать индивидуально, с учетом его технологического стека, уровня сложности и других особенностей.

Мобильная разработка

Немного другая картина складывается в том случае, если ваш продукт предназначен для смартфонов и других переносных устройств. Для анализа трудозатрат мы взяли выборку мобильных проектов, в которых мы выполняли разработку под Android и iOS. При этом мы исходили из допущения, что административная панель во всех проектах была основана на стандартных компонентах фреймворка разработки.

В веб-проектах трудозатраты распределились так:

• Аналитика 3,8%

• Backend 18,9%

• iOS 16,1%

• Android 25,8%

• Тестирование 25,1%

• Управление 10,3%

По нашим оценкам, Backend- и мобильная разработка в среднем составили около 60% трудозатрат.

По сравнению с веб-приложениями, мобильные проекты зачастую более трудоемкие из-за реализации и тестирования сразу на нескольких платформах. Сроки тестирования для них выше в среднем на 10% по сравнению с веб-проектами, потому что парк устройств постоянно растет.

Особенности расчетов

Рассчитать сроки разработки можно с помощью разных инструментов, в том числе вручную в Excel. Для нас наиболее удобным методом стала автоматизация расчетов, для этого мы разработали собственный сервис Estimate, о котором ранее уже рассказывали на Хабре. Этот сервис позволяет подключать шаблоны и учитывать особенности каждого вида проектов. С помощью сервиса можно рассчитать, сколько часов необходимо на каждую фазу или этап разработки, на реализацию отдельных фич.

Заключение

В этой статье мы рассчитали особенности распределения трудозатрат в разных видах продуктов. В наших веб-проектах разработка составила в среднем 50% от общих трудозатрат, а в мобильных проектах около 60%.

При этом наша выборка основана на заказной разработке, большая часть проектов была реализована в формате MVP, поэтому такие расчеты могут не подходить для других типов проектов например, при долгосрочной поддержке. Безусловно, что каждый проект индивидуален и распределение часов везде может быть разным.

Мы надеемся, что наш опыт может быть полезен в прогнозировании рисков, при проведении верхнеуровневой оценки, а также для проверки расчетов на старте проекта. В случае недооценки проекта на этом этапе можно провести оценку повторно и скорректировать трудозатраты, чтобы в дальнейшем выполнить работу в срок полным составом команды.

Фиксация различных нарушений, контроль доступа, розыск и отслеживание автомобилей лишь часть задач, для которых требуется по фотографии определить номер автомобиля (государственный регистрационный знак или ГРЗ).

В этой статье мы рассмотрим создание модели для распознавания с помощью Catalyst одного из самых популярных высокоуровневых фреймворков для Pytorch. Он позволяет избавиться от большого количества повторяющегося из проекта в проект кода цикла обучения, расчёта метрик, создания чек-поинтов моделей и другого и сосредоточиться непосредственно на эксперименте.

Сделать модель для распознавания можно с помощью разных подходов, например, путем поиска и определения отдельных символов, или в виде задачи image-to-text. Мы рассмотрим модель с несколькими выходами (multihead-модель). В качестве датасета возьмём датасет с российскими номерами от проекта Nomeroff Net. Примеры изображений из датасета представлены на рис. 1.

Рис. 1. Примеры изображений из датасета

Общий подход к решению задачи

Необходимо разработать модель, которая на входе будет принимать изображение ГРЗ, а на выходе отдавать строку распознанных символов. Модель будет состоять из экстрактора фичей и нескольких классификационных голов. В датасете представлены ГРЗ из 8 и 9 символов, поэтому голов будет девять. Каждая голова будет предсказывать один символ из алфавита 1234567890ABEKMHOPCTYX, плюс специальный символ - (дефис) для обозначения отсутствия девятого символа в восьмизначных ГРЗ. Архитектура схематично представлена на рис. 2.

Рис. 2. Архитектура модели

В качестве loss-функции возьмём стандартную кросс-энтропию. Будем применять её к каждой голове в отдельности, а затем просуммируем полученные значения для получения общего лосса модели. Оптимизатор Adam. Используем также OneCycleLRWithWarmup как планировщик leraning rate. Размер батча 128. Длительность обучения установим в 10 эпох.

В качестве предобработки входных изображений будем выполнять нормализацию и преобразование к единому размеру.

Кодирование

Далее рассмотрим основные моменты кода. Класс датасета (листинг 1) в общем обычный для CV-задач на Pytorch. Обратить внимание стоит лишь на то, как мы возвращаем список кодов символов в качестве таргета. В параметре label_encoder передаётся служебный класс, который умеет преобразовывать символы алфавита в их коды и обратно.

class NpOcrDataset(Dataset):   def __init__(self, data_path, transform, label_encoder):       super().__init__()       self.data_path = data_path       self.image_fnames = glob.glob(os.path.join(data_path, "img", "*.png"))       self.transform = transform       self.label_encoder = label_encoder    def __len__(self):       return len(self.image_fnames)    def __getitem__(self, idx):       img_fname = self.image_fnames[idx]       img = cv2.imread(img_fname)       if self.transform:           transformed = self.transform(image=img)           img = transformed["image"]       img = img.transpose(2, 0, 1)             label_fname = os.path.join(self.data_path, "ann",                                  os.path.basename(img_fname).replace(".png", ".json"))       with open(label_fname, "rt") as label_file:           label_struct = json.load(label_file)           label = label_struct["description"]       label = self.label_encoder.encode(label)        return img, [c for c in label]

Листинг 1. Класс датасета

В классе модели (листинг 2) мы используем библиотеку PyTorch Image Models для создания экстрактора фичей. Каждую из классификационных голов модели мы добавляем в ModuleList, чтобы их параметры были доступны оптимизатору. Логиты с выхода каждой из голов возвращаются списком.

class MultiheadClassifier(nn.Module):   def __init__(self, backbone_name, backbone_pretrained, input_size, num_heads, num_classes):       super().__init__()        self.backbone = timm.create_model(backbone_name, backbone_pretrained, num_classes=0)       backbone_out_features_num = self.backbone(torch.randn(1, 3, input_size[1], input_size[0])).size(1)        self.heads = nn.ModuleList([           nn.Linear(backbone_out_features_num, num_classes) for _ in range(num_heads)       ])     def forward(self, x):       features = self.backbone(x)       logits = [head(features) for head in self.heads]       return logits

Листинг 2. Класс модели

Центральным звеном, связывающим все компоненты и обеспечивающим обучение модели, является Runner. Он представляет абстракцию над циклом обучения-валидации модели и отдельными его компонентами. В случае обучения multihead-модели нас будет интересовать реализация метода handle_batch и набор колбэков.

Метод handle_batch, как следует из названия, отвечает за обработку батча данных. Мы в нём будем только вызывать модель с данными батча, а обработку полученных результатов расчёт лосса, метрик и т.д. мы реализуем с помощью колбэков. Код метода представлен в листинге 3.

class MultiheadClassificationRunner(dl.Runner):   def __init__(self, num_heads, *args, **kwargs):       super().__init__(*args, **kwargs)       self.num_heads = num_heads    def handle_batch(self, batch):       x, targets = batch       logits = self.model(x)             batch_dict = { "features": x }       for i in range(self.num_heads):           batch_dict[f"targets{i}"] = targets[i]       for i in range(self.num_heads):           batch_dict[f"logits{i}"] = logits[i]             self.batch = batch_dict

Листинг 3. Реализация runnerа

Колбэки мы будем использовать следующие:

• CriterionCallback для расчёта лосса. Нам потребуется по отдельному экземпляру для каждой из голов модели.

• MetricAggregationCallback для агрегации лоссов отдельных голов в единый лосс модели.

• OptimizerCallback чтобы запускать оптимизатор и обновлять веса модели.

• SchedulerCallback для запуска LR Schedulerа.

• AccuracyCallback чтобы иметь представление о точности классификации каждой из голов в ходе обучения модели.

• CheckpointCallback чтобы сохранять лучшие веса модели.

Код, формирующий список колбэков, представлен в листинге 4.

def get_runner_callbacks(num_heads, num_classes_per_head, class_names, logdir):   cbs = [       *[           dl.CriterionCallback(               metric_key=f"loss{i}",               input_key=f"logits{i}",               target_key=f"targets{i}"           )           for i in range(num_heads)       ],       dl.MetricAggregationCallback(           metric_key="loss",           metrics=[f"loss{i}" for i in range(num_heads)],           mode="mean"       ),       dl.OptimizerCallback(metric_key="loss"),       dl.SchedulerCallback(),       *[           dl.AccuracyCallback(               input_key=f"logits{i}",               target_key=f"targets{i}",               num_classes=num_classes_per_head,               suffix=f"{i}"           )           for i in range(num_heads)       ],       dl.CheckpointCallback(           logdir=os.path.join(logdir, "checkpoints"),           loader_key="valid",           metric_key="loss",           minimize=True,           save_n_best=1       )   ]     return cbs

Листинг 4. Код получения колбэков

Остальные части кода являются тривиальными для Pytorch и Catalyst, поэтому мы не станем приводить их здесь. Полный код к статье доступен на GitHub.

Результаты эксперимента

Рис. 3. График лосс-функции модели в процессе обучения. Оранжевая линия train loss, синяя valid loss

В списке ниже перечислены некоторые ошибки, которые модель допустила на тест-сете:

• Incorrect prediction: T970XT23- instead of T970XO123

• Incorrect prediction: X399KT161 instead of X359KT163

• Incorrect prediction: E166EP133 instead of E166EP123

• Incorrect prediction: X225YY96- instead of X222BY96-

• Incorrect prediction: X125KX11- instead of X125KX14-

• Incorrect prediction: X365PC17- instead of X365PC178

Здесь присутствуют все возможные типы: некорректно распознанные буквы и цифры основной части ГРЗ, некорректно распознанные цифры кода региона, лишняя цифра в коде региона, а также неверно предсказанное отсутствие последней цифры.

Заключение

В статье мы рассмотрели способ реализации multihead-модели для распознавания ГРЗ автомобилей с помощью фреймворка Catalyst. Основными компонентами явились собственно модель, а также раннер и набор колбэков для него. Модель успешно обучилась и показала высокую точность на тестовой выборке.

Спасибо за внимание! Надеемся, что наш опыт был вам полезен.

Больше наших статей по машинному обучению и обработке изображений:

• Data Science: предсказание бизнес-событий для улучшения сервиса

• Как мы используем алгоритмы компьютерного зрения: обработка видео в мобильном браузере с помощью OpenCV.js

• Тестируем комплементарную кросс-энтропию в задачах классификации текста

Какие навыки прокачать на старте, где найти ментора, как получить первый опыт командной работы все эти вопросы знакомы разработчикам-джунам. Изучая Java или C# самостоятельно, можно запутаться в море информации и потратить больше года на первые шаги. Сократить этот путь помогают практикумы, в том числе в IT-компаниях где менторы готовы поделиться знаниями, давно накоплена база знаний и отлажены процессы разработки. Мы в SimbirSoft проводим такие практикумы несколько раз в год. Сейчас мы открыли запись на ближайший запуск 22 февраля. Рассказываем, чему научатся участники и как подать заявку.

В чём помогают практикумы

С помощью онлайн-практикумов разработчики могут комплексно решить несколько задач в обучении:

• за 1,5-2 месяца систематизировать свои знания, занимаясь в небольших группах;

• получить от менторов ответы на вопросы в ходе еженедельных теоретических занятий;

• за время практикума вместе с командой реализовать проект, который можно в дальнейшем показать в своем портфолио.

Как правило, по итогам практикумов у участников есть возможность трудоустройства. Например, мы приглашаем на собеседование в среднем от 20 до 50% выпускников. Исходя из результатов, мы можем предложить начинающему разработчику дальнейшее обучение в компании или посоветовать ему, какие навыки нужно подтянуть самостоятельно.

Как устроены наши практикумы

У нас в SimbirSoft есть разные форматы онлайн-встреч как для обучения, так и для обмена опытом:

• Например, это онлайн-митапы, где наши разработчики и приглашенные гости выступают с докладами. Такие события открыты для всех желающих, чтобы принять участие, достаточно зарегистрироваться на TimePad.

• Практикумы, в свою очередь, рассчитаны на начинающих разработчиков-джунов. Для них и менторов наиболее удобны небольшие группы, в среднем до 10-15 человек, и по этой причине количество участников ограничено. В этот раз мы в первую очередь рассмотрим заявки разработчиков из тех городов, где у нас есть офисы и наиболее опытные менторы:

1) ждем начинающих C#-разработчиков из Ульяновска, Самары, Саранска, Димитровграда, Казани и Краснодара;

2) начинающих Java-разработчиков из Казани и Самары.

Если вы живете в другом городе или интересуетесь другими видами разработки, вы также можете записаться на наши ближайшие интенсивы и практикумы:

- До 10 февраля принимаем тестовые задания на Весенний интенсив для Frontend-, Web- и мобильных разработчиков.

- До 11 февраля принимаем тестовые задания на онлайн-практикум по QA и тестированию в Краснодаре.

- Подписаться на новости о следующих событиях можно ВКонтакте или в Telegram.

Программа Backend-практикума

1) Трек Java

• Spring Initializr, (Rest)Controller, Git. Как создать проект, как сделать контроллер, отдающий статику и json, как создать репозиторий и как залить в него изменения.

• DB, Service, Repository (встроенки), Component, Configuration. Как подключить базу данных, как организовать работу с данными через сервисы и репозитории, что такое бины и компоненты, как с ними работать.

• Security, Migrations, DB level-up. Как подключить и настроить базовую безопасность, как управлять пользователями, что такое миграции и для чего они нужны, транзакции и каскадные операции с БД.

• Testing, Patterns, Security level-up. Как писать правильные тесты и работать с тестовыми фреймворками, какие существуют паттерны проектирования и как применять их в проектах, вопросы безопасности.

• Spring AOP, Tips&Tricks. Что такое АОП и как этим пользоваться, работа с побочными инструментами (swagger, статические анализаторы и др.), как работать с GitHub (пулл-реквесты, projects).

2) Трек C#

• .NET Core 3.1, Asp.Net Core, Git. Как создать проект и репозиторий, внести и залить изменения.

• Nuget. Как подключать библиотеки к проекту и управлять зависимостями.

• Entity Framework Core, DbUp. Как подключить базу данных, организовать работу с данными через сервисы и репозитории, как с ними работать. Что такое миграции и для чего они нужны, транзакции и каскадные операции с БД.

• Testing, Patterns, xUnit. Как писать правильные тесты и работать с тестовыми фреймворками, какие существуют паттерны проектирования и как применять их в проектах.

• Security, Docker. Глубже рассмотрим вопросы безопасности и автоматизации развёртывания и управления приложениями.

Владислав, куратор практикумов по Backend-направлению:

Наш практикум это удобное средство входа в профессию Backend-разработчика. Каждый наш ментор имеет большой опыт в реализации множества проектов и готов поделиться этим опытом с вами. Мы поможем вам раскрыть свой потенциал, найти точки роста и научим работать в команде!

Алексей, разработчик C#, ментор трека C#:

В ходе нашего практикума вы сможете попробовать себя в качестве разработчика, обучиться азам профессии, а также получите опыт работы в команде, что является неотъемлемой частью IT-сферы. Полученные знания позволят оценить силу мотивации, реальные возможности и решить, нужно ли идти дальше. Менторы ответят на все ваши вопросы, помогут разобраться в трудностях и обучат собственным профессиональным приёмам.

Подключайтесь к нашему практикуму! Регистрация на TimePad до 18 февраля.

Как и многие мобильные разработчики, мы с нетерпением ждали презентации Flutter и теперь хотим поделиться с читателями Хабра переводом статьи Tadas Petra о том, как можно выстроить свое обучение, если вы хотите познакомиться с Flutter и кроссплатформенными приложениями в 2021 году. Кстати, мы подключились к созданию курса Flutter, и об этом тоже расскажем в конце статьи. Приглашаем прочитать или посмотреть видеоверсию!

***

2021 год обещает быть очень важным для Flutter. Комьюнити разработчиков продолжает стремительно расти, а 3 марта 2021 года состоялась презентация Flutter Engage. Это делает потенциал Flutter поистине огромным.

Однако, чем более популярным становится фреймворк, тем больше людей хотят его пощупать и иногда не знают, с чего же, собственно, начать? В данной статье автор постарался создать roadmap и описать несколько ресурсов, которые могут быть полезны для вас.

Кстати, здесь можно посмотреть видеоверсию материала на английском, а если вы предпочитаете читать, то давайте продолжим.

Основы

Преимущество Flutter возможность разрабатывать приложения без значительных усилий. Однако, иногда это влечет определенные проблемы, если разработчик уделяет недостаточно внимания коду, который пишет.

Перед началом погружения в Flutter стоит вспомнить принципы ООП, в частности, на примере Dart. Вероятно, этот способ будет для вас удобен, если вы переходите на Flutter с языков вроде C++ или JavaScript. Так, у меня ушло всего пару дней на то, чтобы привыкнуть к его синтаксису. После этого можно перейти к непосредственному изучению фреймворка.

Учебные ресурсы

Документация Flutter

Для меня документация первый шаг к изучению чего-либо, включая Flutter. Команда Flutter сфокусирована на обеспечении высокого качества документации, поэтому загляните сюда в первую очередь в случае любых проблем.

Codelabs

Codelabs от Google разрабатываются и дорабатываются командой Flutter. Можно быть уверенными в их качестве и актуальности материала. Также это хорошая отправная точка в изучении Flutter на практике.

YouTube

Для меня это самый важный ресурс для изучения всего нового. Поделюсь несколькими каналами, которые я использую:

Мой канал

Robert Brunhage

Fun With Flutter

Resocoder

MTechViral

Fireship

FilledStacks

FlutterExplained

Официальный канал Flutter

freeCodeCamp

Free code camp это одна из самых больших площадок для онлайн-обучения программированию. Уверен, со временем у них будет появляться все больше нового контента. Сейчас у них есть несколько видеокурсов по Flutter, включая мой.

Учебные курсы

Одним из лучших курсов по Flutter я считаю курс от Angela Yu. Сам я его не проходил, но слышал очень лестные отзывы о нем. Он имеет рейтинг 4.7 и более 90000 студентов на Udemy, что говорит о его качестве. Помимо Flutter, в его программу входит также изучение темы ООП и его принципов: инкапсуляции, наследования и полиморфизма.

Awesome Flutter

Это отличный GitHub-репозиторий, который содержит огромное количество ресурсов по Flutter.

Присоединяйтесь к сообществу

Хотя это непрямой способ изучения Flutter, я думаю, что если вы станете частью сообщества, это поможет вам вырасти как разработчику и познакомиться с новыми друзьями, которые способны помочь вам. Например, большое комьюнити разработчиков есть в Twitter, и я предлагаю свою версию списка важнейших Flutter-разработчиков.

Изучайте на практике

Важное напоминание: выше перечислены ресурсы для изучения фреймворка. Однако, на мой взгляд, разработка это лучший способ научиться. Как только вы освоите основы, сразу приступайте к разработке приложений, закрепляя полученные знания на практике. В случае возникновения проблем посмотрите перечисленные ресурсы и попробуйте решить задачу с их помощью. При этом изучение на практике гораздо эффективнее пассивного чтения.

Вот несколько приложений, которые вы можете создать для практики:

• Планировщик задач

• Приложение-чат

• Приложение интернет-магазина

Примечание: кстати, к этому списку можно добавить и другие идеи например, лента новостей, помощь в выборе сериалов или мониторинг криптовалют (15 проектов на Flutter с разбором для новичков и не только).

Если вам удастся реализовать данные приложения и они будут правильно работать вы на пути к тому, чтобы стать хорошим разработчиком. После этого важно сфокусироваться на качестве и эффективности кода, улучшении его работы в различных аспектах.

Хороших проектов всем! Пусть 2021 станет отличным годом для Flutter. Посмотреть другие полезные материалы @tadaspetra можно на всех платформах, включая YouTube.

Из нашей практики

Flutter как один из ключевых инструментов кроссплатформенной разработки хорошо подходит для тех случаев, когда нужно ускорить выпуск приложения или создать MVP для проверки гипотез. У нас разработчики используют как нативные технологии, так и кроссплатформенные и обмениваются опытом внутри команды.

По нашим наблюдениям, для качественного погружения в Flutter важен комплексный подход непосредственно разработка, создание интерфейсов и анимаций, особенности взаимодействия с нативными модулями. Такой подход мы используем на наших внутренних курсах SimbirSoft.

Также в этом году поделимся опытом с начинающими специалистами. По приглашению онлайн-университета Skillbox мы приняли участие в разработке нового дополненного курса Flutter и профессии разработчика кроссплатформенных приложений. Для этого мы записали блок лекций по нативным модулям и популярным архитектурам. Надеемся, что курс будет полезен разработчикам, и желаем успехов будущим коллегам!

Иногда бывает нужно размыть задний план на экранах мобильного приложения, например в чате. Теперь это можно сделать всего парой строк кода. В Android 12 появился новый API Render Effect, который позволяет накладывать визуальные эффекты на Canvas или View. Этот API радует своей простотой и высокой скоростью отрисовки. Наибольший интерес представляет Render Effect дляразмытия (BlurEffect), но в этой статье мы затронем и остальные виды эффектов. Материал может быть полезен не только андроид-разработчикам, но и дизайнерам мобильных приложений.

Итак, каким образом можно размыть задний план при отображении диалога? Раньше в Андроиде для этого надо было отрисовать все вью с заднего плана на bitmap-е и затем размыть его с помощью RenderScript или OpenGL. Но это означает, что в проекте появится немало запутанного для прочтения кода, либо придется подключить стороннюю библиотеку для размытия. Плюс добавятся обработчики событий отрисовки и код для получения битмапа. К тому же по производительности эти решения могут не давать желаемого результата. При использовании некоторых популярных библиотек для размытия разработчики замечают лаги, например, если есть RecyclerView, который содержит много BlurView.

С помощью Render Effect мы можем всего парой строк кода реализовать блюр без лагов. Render Effect работает эффективно за счет того, что он использует Render Nodes (узлы отрисовки). Они образуют иерархию аппаратно ускоренной отрисовки, и эта отрисовка происходит с помощью GPU (графического процессора). Перерисовываться будут только те части UI, которые оказались в состоянии invalidated. Все вычисления для Render Effect выполняются в Render потоке и не блокируют UI.

У Render Effect очень простой API:

val renderNode = RenderNode("myRenderNode")renderNode.setPosition(0, 0, 50, 50)renderNode.setRenderEffect(renderEffect) canvas.drawRenderNode(renderNode)

Мы добавили эффект для RenderNode методом setRenderEffect(), и его отрисовка происходит в методе Canvas.drawRenderNode().

Можно применить Render Effect и к узлу отрисовки вьюшки:

imageView.setRenderEffect(renderEffect)

Приведем пример создания эффекта:

val blurEffect = RenderEffect.createBlurEffect(       20f, //radiusX       20f, //radiusY              Shader.TileMode.CLAMP)imageView.setRenderEffect(blurEffect)

Здесь мы создаем эффект размытия и применяем его к узлу отрисовки, привязанному к imageView. Задаем интенсивность размытия по оси X и оси Y (Значения 20f) . Последний аргумент Shader.TileMode определяет то, как будет выглядеть эффект на краях отрисовываемой области.

Если применить размытие к корневому layout-у, то будут размыты все вьюшки: и кнопка, и ползунки.

Варианты значений TileMode:

• MIRROR. Используются зеркальные отражения изображения по вертикали и горизонтали, при этом на границах нет резких переходов.

• CLAMP. Если shader выходит за пределы границ, используется цвет пикселей на границе. Выглядит практически также как MIRROR, но возможно незначительное искажение формы объектов возле границы.

• REPEAT. Изображение повторяется горизонтально и вертикально. На изображении заметно, как темная вода из нижней части изображения отразилась на верхней границе изображения.

• DECAL (появился в API 31). Отрисовка shader-а только в пределах границ. Можно заметить, что на границе изображение стало чуть светлее.

Мы также можем применить размытие при создании тени. Конечно, можно просто создать тень с помощью свойства Elevation:

android:elevation="10dp"

Однако, в этом случае мы не сможем задавать направление, в котором должна отбрасываться тень, или ее цвет. Также тень для Elevation по умолчанию работает только с формами скругленного прямоугольника (круг и прямоугольник частные случаи прямоугольника со скругленными углами). Для тени другой формы нужно реализовать ViewOutlineProvider, чтобы он возвращал Outline с setPath(...), а это может быть весьма трудоемко.

Кастомную тень можно создать и с помощью xml, прописав <shape> с градиентом:

<gradient       android:type="radial"       android:centerColor="#90000000"       android:gradientRadius="70dp"       android:startColor="@android:color/white"       android:endColor="@android:color/transparent"/>

Мы получили тень круглой формы, ложащуюся от белого круга одинаково во всех направлениях то есть сверху она такой же длины, что и снизу. Но мы все же не сможем таким способом сделать тень сложной формы.

Сначала для сравнения покажем, как можно реализовать аналогичную тень круглой формы с помощью RenderEffect. Создаем круг серого цвета:

<shape android:shape="oval">   <solid android:color="#CCCCCC" /></shape>

Затем этот drawable устанавливаем в качестве содержимого ImageView и применяем размытие к ImageView:

imageView.setImageResource(R.drawable.gray_circle)val renderEffect = RenderEffect.createBlurEffect(20f, 20f, Shader.TileMode.CLAMP)imageView.setRenderEffect(renderEffect)

А вот как с помощью RenderEffect можно добиться тени произвольной формы и, если понадобится, произвольного цвета:

<ImageView   android:id="@+id/shadow"   android:layout_width="150dp"   android:layout_height="150dp"   android:src="@drawable/ic_baseline_time_to_leave_24"   android:tint="#444444"/>

val effect = RenderEffect.createBlurEffect(10f, 10f, Shader.TileMode.CLAMP)imageViewfindViewById<ImageView>(R.id.shadow).setRenderEffect(effect)

Если попробовать сделать размытие с разными значениями радиуса, например, 20 по горизонтали и 0 по вертикали, то получится эффект, похожий на смазанный снимок.

Всего есть семь видов RenderEffect:

• Bitmap отрисовывает содержимое битмапа. Обычно используется в цепочке для наложения последующих эффектов.

• Blur размытие по оси X и Y.

• ColorFilter применяется цветной фильтр (см. скриншот ниже).

• Offset сдвиг по осям X, Y (жаль, что нет поворота).

• Shader отрисовывает шейдер, переданный в аргументах. С помощью шейдеров можно создавать, например, различные градиенты.

• Chain комбинация 2 эффектов. Результат отрисовки одного эффекта используется как источник для второго эффекта.

• BlendMode для объединения 2 эффектов в определенном режиме.

Можно добиться красивого эффекта замерзшего стекла (или запотевшего окна): он достигается сочетанием размытия и наложения прозрачно-белого цвета.

Применим такой эффект к панели внизу экрана. Фактически здесь надо сочетать три эффекта: отрисовка битмапа + размытие + цветной фильтр. К сожалению, нельзя сделать так, чтобы размывалась та часть UI, которая отрисована под вьюшкой. Поэтому RenderEffect нужно применить не к самой панели, а к тому, что находится под ней и содержит фоновое изображение: к imageView или к корневому layout-у. Комбинировать эффекты можно 2 способами: передавать один эффект в параметр create-метода другого эффекта, либо использовать метод createChainEffect():

val bmpEffect = RenderEffect.createBitmapEffect(...)val blurBmpEffect = RenderEffect.createBlurEffect(..., bmpEffect, ..)val finalEffect = RenderEffect.createColorFilterEffect(..., blurBitmapEffect)

или

val finalEffect = RenderEffect.createChainEffect(colorEffect,blurEffect)

Приведем пример наложения цветного фильтра:

val argb = Color.valueOf(red, green, blue, transparency).toArgb()val colorEffect = RenderEffect.createColorFilterEffect(       PorterDuffColorFilter(argb, PorterDuff.Mode.SRC_ATOP))

Результат:

Или можно с помощью цветного фильтра поменять насыщенность изображения:

val matrix = ColorMatrix()matrix.setSaturation(0f)imageView.setRenderEffect(RenderEffect.createColorFilterEffect(ColorMatrixColorFilter(matrix)))

Результат для setSaturation(0f) и setSaturation(100f):

BlendMode

С помощью метода RenderEffect.createBlendModeEffect() можно объединить два эффекта в одном из режимов:

• CLEAR

• SRC

• DST

• SRC_OVER

• DST_OVER

• SRC_IN

• DST_IN

• SRC_OUT

• DST_OUT

• SRC_ATOP

• DST_ATOP

• XOR

• PLUS

• MODULATE

• SCREEN

• OVERLAY

• DARKEN

• LIGHTEN

• COLOR_DODGE

• COLOR_BURN

• HARD_LIGHT

• SOFT_LIGHT

• DIFFERENCE

• EXCLUSION

• MULTIPLY

• HUE

• SATURATION

• COLOR

• LUMINOSITY

Подробное описание режимов можно посмотреть здесь. Для примера приведем три режима (здесь источник, то есть первый RenderEffect это синий квадрат, а приемник, то есть второй Render Effect красный круг):

Как уже упоминалось выше, RenderEffect работает крайне эффективно. При скролле RecyclerView с большим количеством элементов, у которых размыто по две ImageView (размытие с параметрами radiusX: 20f, radiusY: 20f, Shader.TileMode.CLAMP), никаких подтормаживаний не наблюдается. Размытие вью с анимацией тоже работает без задержек. В настоящий момент работа RenderEffect была проверена автором на эмуляторе Android 12 (API 31).

Что касается поддержки RenderEffect API, можно надеяться, что она будет добавлена в библиотеке AndroidX для Android 10 и 11, так как Render Nodes, лежащие в основе RenderEffect, были добавлены в Android 10 (API level 29). Однако, как пишут в официальной документации, Render Effect могут поддерживать не все устройства: Different Android devices may or may not support the feature due to limited processing power.

Отметим также, что Render Effect является одним из вариантов замены для RenderScript API, который устарел начиная с Android 12.

Заключение

Итак, в Android 12 мы получили то, чего так долго не хватало многим разработчикам простой API для отрисовки визуальных эффектов. Сочетая простые эффекты (размытие, цветные фильтры, шейдеры), мы можем получать интересные графические результаты. При этом больше не нужно возиться с вытаскиванием bitmap-изображения, эффект можно просто повесить на вьюшку. А благодаря использованию RenderNodes, отрисовка RenderEffect работает очень быстро.

Спасибо за внимание! Надеемся, что наш опыт был вам полезен.

Как изменилась удаленка в 2021 году, после поправок в Трудовом кодексе делимся нашим опытом. Как и многие в отрасли, мы остаемся на удаленке для этого адаптировали к онлайну все процессы и взаимодействия в команде из 1000+ специалистов. Параллельно перестраиваем IT-офисы, вносим много изменений для будущей совместной работы. Рассмотрим правовой аспект и ответим на частые вопросы в статье, подготовленнойнашей юридической службой.

До 2020 года лишь отдельные компании поддерживали дистанционную работу, но пандемия внесла свои коррективы и изменила подход к удаленке у бизнеса, специалистов и законодателей. Далее рассмотрим изменения в Трудовом кодексе, вступившие в силу 1 января 2021 года в части регулирования удаленной/дистанционной работы.

1) На какой максимальный срок могут принять или перевести на временную дистанционную работу?

Трудовым договором или дополнительным соглашением к трудовому договору может предусматриваться выполнение работы дистанционно временно в течение срока, определенного трудовым договором или дополнительным соглашением к трудовому договору, но не превышающего шести месяцев (ст. 312.1 Трудового кодекса РФ).

2) Можно ли работать поочередно из дома и из офиса?

Можно, если трудовым договором или дополнительным соглашением предусмотрено чередование работы дистанционно и на стационарном рабочем месте (ст. 312.1 Трудового кодекса РФ).

3) Если сотрудник впервые заключает трудовой договор, то работодатель самостоятельно оформит трудовую книжку или дистанционному работнику необходимо ее приобретать и отправлять работодателю?

На сотрудников, которые впервые поступают на работу с 1 января 2021 года, работодатель сразу формирует электронные трудовые книжки, а трудовая книжка в бумажном виде не заводится (ст. 66.1 Трудового кодекса РФ).

При отсутствии у новичков СНИЛС тем, кто работает удаленно, придется самим оформлять этот документ, если трудовой договор с ними заключают путем обмена электронными документами (ст. 312.1 Трудового кодекса РФ).

4) Можно ли отправить подписанную скан-копию трудового договора работодателю по электронной почте?

Нет, нельзя. Трудовой договор должен быть подписан либо на бумажном носителе собственноручной подписью в офисе работодателя, либо в электронном виде усиленной квалифицированной или усиленной неквалифицированной электронной подписью (ст. 312.3 Трудового кодекса РФ).

Указанные выше правила относятся также к подписанию следующих документов:

• дополнительные соглашения к трудовому договору;

• договоры о материальной ответственности;

• ученические договоры;

• а также при внесении изменений в эти договоры и их расторжении (ст. 312.3 Трудового кодекса РФ).

Всеми остальными документами работник и работодатель могут обмениваться в иной форме, предусмотренной локальным нормативным актом, трудовым договором, дополнительным соглашением к трудовому договору (ст.312.3 Трудового кодекса РФ).

5) Вправе ли работодатель требовать от дистанционного работника предоставления нотариально заверенных копий документов, которые уже были высланы ему при трудоустройстве по электронной почте (паспорт, СНИЛС, трудовая книжка, документ об образовании и т.п)?

Да, вправе. По требованию работодателя лицо, поступающее на дистанционную работу, обязано представить ему нотариально заверенные копии документов, предоставляемых при трудоустройстве, на бумажном носителе (ст.312.2 Трудового кодекса РФ).

6) Вправе ли работодатель знакомить дистанционного работника с приказами, уведомлениями, требованиями и иными документами через электронную почту?

Да, вправе если подобное ознакомление и взаимодействие между работником и работодателем предусмотрено локальным нормативным актом, трудовым договором, дополнительным соглашением к трудовому договору (ст. 312.3 Трудового кодекса РФ).

В таком локально нормативном акте, трудовом договоре, дополнительном соглашении к трудовому договору должны быть прописаны все детали взаимодействия.

Более того, если взаимодействие через электронную почту закреплено документально, то и дистанционный работник вправе обратиться к работодателю с заявлением, предоставить объяснения либо другую информацию по электронной почте (ст. 312.3 Трудового кодекса РФ).

Вывод: необходимо внимательно знакомиться со всеми документами, принятыми у работодателя.

7) Как направить в адрес работодателя больничный лист для получения по нему оплаты?

Дистанционный работник направляет работодателю оригиналы больничных листов, оформленных на бумажном носителе, по почте заказным письмом с уведомлением либо представляет работодателю сведения о серии и номере листка нетрудоспособности, сформированного медицинской организацией в форме электронного документа (ст. 312.3 Трудового кодекса РФ).

8) Может ли работодатель вызвать дистанционного сотрудника для работы в офисе?

Такая возможность может быть предусмотрена только в отношении работника, выполняющего работу удаленно временно, и только в случае, если условия и порядок вызова предусмотрены локальным нормативным актом, трудовым договором, дополнительным соглашением к трудовому договору (ст. 312.4 Трудового кодекса РФ).

9) Должен ли работодатель обеспечивать дистанционного работника компьютером/ноутбуком и другим оборудованием?

Да, должен. Работодатель обеспечивает дистанционного работника необходимыми для выполнения им трудовой функции оборудованием, программно-техническими средствами, средствами защиты информации и иными средствами (ст. 312.6 Трудового кодекса РФ).

10) Если дистанционный работник привык к своему компьютеру/ноутбуку, может ли он работать на нем и отказаться от оборудования работодателя?

Дистанционный работник вправе с согласия или ведома работодателя и в его интересах использовать свое оборудование. При этом работодатель выплачивает дистанционному работнику компенсацию за использование оборудования, а также возмещает расходы, связанные с его использованием. Размер и порядок выплаты указанной компенсации может определяться в трудовом договоре, дополнительном соглашении к трудовому договору или в локально нормативном акте работодателя (ст.312.6 Трудового кодекса РФ).

11) Может ли работодатель направить дистанционного работника в командировку?

Да, такая возможность предусмотрена с 01.01.2021 года (ст. 312.6 Трудового кодекса РФ).

12) По каким основаниям может быть уволен дистанционный работник по инициативе работодателя?

Помимо оснований, ранее уже предусмотренных Трудовым кодексом РФ (ст. 71 и 81), появились новые основания расторжения трудового договора с дистанционным работником (ст. 312.8 Трудового кодекса РФ):

• Первое работник больше двух рабочих дней не отвечает на запросы руководителя.

• Второе работник переехал и по объективным причинам не может выполнять работу так же эффективно, как раньше. Расстаться по этому основанию можно только с тем сотрудником, которому удаленку оформили на неопределенный срок.

Иные основания увольнения дистанционного сотрудника по инициативе работодателя, прописанные в трудовом договоре, заключенном после 1 января 2021 года, будут считаться незаконными.

13) Если сотрудник не является дистанционным работником, вправе ли работодатель перевести его на удаленную работу без его согласия?

Вправе в случае наличия следующих обстоятельств (ст. 312.9 Трудового кодекса РФ):

• Первое в случае катастрофы природного или техногенного характера, производственной аварии, несчастного случая на производстве, пожара, наводнения, землетрясения, эпидемии или эпизоотии и в любых исключительных случаях, ставящих под угрозу жизнь или нормальные жизненные условия всего населения или его части на период наличия указанных обстоятельств (случаев).

• Второе в случае принятия соответствующего решения органом государственной власти и (или) органом местного самоуправления на период действия такого решения.

При этом работодатель обязан издать и предоставить сотрудникам для ознакомления локальный нормативный акт, в котором указывается список сотрудников, переводимых на удаленку, причины и сроки перевода сотрудников на временную дистанционную работу, порядок обеспечения таких работников оборудованием или размер и порядок выплаты компенсации (в случае если работники используют свое оборудование), а также порядок организации труда временных дистанционных работников (ст. 312.9 Трудового кодекса РФ).

Подводя итоги

Из рассмотренных изменений, внесенных в Трудовой кодекс РФ, на наш взгляд стоит особо выделить право работодателя самостоятельно устанавливать те или иные способы и режимы взаимодействия с удаленными/дистанционными сотрудниками, предусматривать порядок организации их работы в локальных нормативных актах, что безусловно облегчит работу как работодателя, так и работника, который находится вне офиса.

При этом хотелось бы дать следующую рекомендацию специалистам, которые работают или планируют работать дистанционно: внимательно читайте не только трудовой договор (дополнительные соглашения к нему), но и все внутренние документы, с которыми вас знакомит работодатель, поскольку именно в них, скорее всего, прописаны основные условия вашей дальнейшей работы.

Спасибо за внимание! Надеемся, что материал был вам полезен.

Ранее мы уже писали о том, когда бывает нужна автоматизация тестирования и какие проверки при этом используют. Сегодня предлагаем обсудить использование инструментов на практике и оценить их производительность. С разрешения Giovanni Rago автора серии полезных материалов о тестировании мы перевели его статью Puppeteer vs Selenium vs Playwright: сравнение скорости (Puppeteer vs Selenium vs Playwright, a speed comparison). Статья будет интересна тем, кто задумывается о выборе подходящего инструмента автоматизации в своих проектах.

От автора:

Для разработки системы мониторинга и тестирования Checkly мы решили использовать Puppeteer. Это инструмент автоматизации тестирования с возможностью включения headless браузера и открытым исходным кодом, позже мы также внедрили Playwright. Checkly помогает узнать, работает ли тестируемый сайт так, как ожидается в определенный момент времени. В нашем случае основной интерес вызывала скорость работы инструмента.

Задача определения наиболее быстрого инструмента автоматизации не так проста. Поэтому мы решили провести свой бенчмарк тест производительности, чтобы сравнить новичков Puppeteer и Playwright с ветераном WebDriverIO (в связке с Selenium и протоколом автоматизации DevTools).

В результате проведения тестов мы сделали неожиданные открытия: например, Puppeteer работает быстрее на небольших скриптах, а WebDriverIO показывает больший разброс на длинных сценариях. Далее подробнее расскажем о наших результатах и о том, как мы их получили.

Почему мы сравниваем эти инструменты автоматизации?

Рассматривать Puppeteer/Playwright и Selenium это всё равно что сравнивать яблоки с апельсинами: инструменты имеют существенно разные возможности и применяются в разных областях автоматизации, и тот, кто их оценивает, должен учитывать это, прежде чем анализировать скорость.

До этого многие из нас долгое время работали с Selenium, и мы очень хотели понять, действительно ли новые инструменты работают быстрее.

Важно заметить, что WebDriverIO это высокоуровневый фреймворк с множеством полезных функций, который может запускать автоматизацию в нескольких браузерах, используя различные встроенные инструменты.

Опыт показывает, что большинство пользователей Selenium, которые работают с JavaScript, используют WebDriverIO для запуска автоматизированных скриптов. Именно поэтому мы выбрали его. Также нам было интересно протестировать новый DevTools режим.

Другой важной задачей для нас было сравнить Playwright, для которого мы недавно добавили поддержку в Checkly, с нашим любимым Puppeteer.

Методология, или как мы запускали тесты

Можете смело пропустить этот раздел, если хотите сразу перейти к результатам. Но мы рекомендуем всё же ознакомиться с ним. Это поможет лучше понять результаты тестов.

Общие рекомендации

В тестировании производительности нет никакого смысла, если проверяемые инструменты находятся в разных условиях. Во избежание этого мы составили рекомендации и следовали им:

1. Равенство ресурсов: каждый тест запускался последовательно на одной и той же машине в состоянии покоя, то есть ни одна ресурсозатратная рабочая нагрузка не выполнялась в фоновом режиме во время бенчмарка, так как это могло бы исказить измерения.

2. Простое выполнение: скрипты запускались так, как это было показано в документации к каждому инструменту и с минимальными конфигурациями. Например, для Playwright node script.js

3. Сопоставимые скрипты: мы стремились минимизировать разницу в скриптах, которые использовали для бенчмарка. Некоторые инструкции всё ещё нуждаются в добавлении, удалении, настройке, чтобы добиться стабильного выполнения.

4. Самые свежие версии: для тестирования всех инструментов мы использовали их последние версии.

5. Одинаковый браузер: все скрипты выполнялись в headless Chromium.

В следующем разделе представлена дополнительная информация по всем пунктам.

Техническая настройка

Для каждого теста на производительность мы собрали данные из 1000 успешных последовательных выполнений одного скрипта.

В случае Selenium наши скрипты работали на отдельном сервере, то есть мы не запускали новый сервер для каждого прогона (хотя всегда использовали чистую сессию), как делают некоторые фреймворки. Мы приняли такое решение с целью ограничения накладных расходов на время выполнения.

Все тесты мы проводили на MacBook Pro 16 последнего поколения под управлением macOS Catalina 10.15.7 (19H2) со следующими характеристиками:

Модель: MacBookPro16,1

Процессор: 6-Core Intel Core i7

Скорость процессора: 2,6 ГГц

Количество процессоров: 1

Количество ядер: 6

Кэш-память L2 (на ядро): 256 Кб

Кэш-память L3: 12Мб

Технология Hyper-Threading: включена

Память: 16 Гб

Мы использовали следующие зависимости:

bench-wdio@1.0.0 /Users/ragog/repositories/benchmarks/scripts/wdio-selenium

@wdio/cli@6.9.1

@wdio/local-runner@6.9.1

@wdio/mocha-framework@6.8.0

@wdio/spec-reporter@6.8.1

@wdio/sync@6.10.0

chromedriver@87.0.0

selenium-standalone@6.22.1

scripts@1.0.0 /Users/ragog/repositories/benchmarks/scripts

playwright@1.6.2

puppeteer@5.5.0

Скрипты, которые мы использовали вместе с результатами их выполнения, вы можете найти в GitHub-репозитории.

Измерения

Мы получили следующие показатели, все рассчитано на основе 1000 прогонов:

* Среднее время выполнения (в секундах).

* Стандартное отклонение (в секундах): показатель разброса времени выполнения.

* Коэффициент вариации (CV): безразмерный коэффициент, который показывает отклонение результатов от среднего.

* P95 (изменение 95-го процентиля): наибольшее значение, оставшееся после отбрасывания верхних 5% отсортированного списка полученных данных. Интересно было бы узнать, как выглядит не экстремальное, но все еще высокое значение.

Что мы не измерили (пока)

* Надежность: ненадежные сценарии быстро становятся бесполезными, независимо от того, насколько быстро они выполняются.

* Эффективность распараллеливания: параллельный запуск очень важен в контексте инструментов автоматизации. Однако в этом случае мы в первую очередь хотели понять, с какой скоростью может выполняться один скрипт.

* Скорость в нелокальных средах: также, как и распараллеливание, облачное выполнение является обширной темой, которая выходит за рамки этой статьи.

* Использование ресурсов: необходимые объемы памяти и вычислительной мощности помогут определить, где и как вы можете запускать свои сценарии.

Результаты

Ниже вы видите совокупные результаты тестирования производительности. Полные наборы данных вы можете найти в репозитории GitHub.

Запуск на демосайте

Первый бенчмарк запускался на нашем демонстрационном сайте. Эта веб-страница, размещенная на Heroku, создана на основес использованием Vue.js и использует бэкенд на Express. В большинстве случаев данные с бэкенда фактически не извлекаются. Вместо этого фронтенд хранит данные на стороне клиента.

В первом сценарии при выполнении процедуры быстрого входа мы ожидали, что время выполнения составит всего несколько секунд. Это отлично подходит для выявления потенциальных различий в скорости запуска между реальными инструментами.

Общие результаты выглядят следующим образом:

Первое, что обращает на себя внимание это большая разница между средним временем выполнения для Playwright и Puppeteer, причем последний почти на 30% быстрее и демонстрирует меньший разброс в его производительности. Мы задумались, не связано ли это с более длительным запуском со стороны Playwright. Мы не стали рассматривать этот и аналогичный вопросы, во избежание увеличения объема работ для первого бенчмарка.

Вторым сюрпризом стал более низкий общий разброс при запуске WebDriverIO. Также интересно, насколько близки результаты: на диаграмме линии непрерывно пересекают друг друга, поскольку протокол автоматизации, похоже, не оказывает существенного влияния на время выполнения в этом сценарии.

Возможно, менее удивительным является то, что запуск Puppeteer без добавления какого-либо высокоуровневого фреймворка помогает нам значительно сократить время выполнения этого очень короткого скрипта.

Запуск на реальном веб-приложении

Предыдущий опыт научил нас, что разницу между демонстрационной средой и реальным миром почти всегда недооценивают. Поэтому мы очень хотели, чтобы тесты производительности выполнялись на рабочем приложении. В этом случае мы выбрали Checkly для запуска интерфейса Vue.js и бэкэнда, который в значительной степени использует AWS.

Запущенный нами скрипт очень похож на классический тест E2E: вход в Checkly, настроенная проверка API, сохранение и тут же удаление. Мы с нетерпением ждали этого сценария, но у каждого из нас были разные ожидания относительно того, как будут выглядеть цифры.

В этом случае разница во времени выполнения между Playwright и Puppeteer почти исчезла. Playwright теперь выходит на первое место и демонстрирует немного меньший разброс.

Разница между новыми инструментами и обеими разновидностями WebDriverIO тоже соответственно меньше. Стоит отметить, что последние два теперь дают больший разброс в результатах по сравнению с предыдущим сценарием, в то время как Puppeteer и Playwright показывают меньшие отклонения.

Интересно, что наш первоначальный тест для этого сценария включал внедрение файлов cookie в совершенно новый сеанс, чтобы иметь возможность полностью пропустить процедуру входа в систему. Позднее от этого подхода отказались, поскольку мы столкнулись с проблемами на стороне Selenium, когда сеанс переставал отвечать после загрузки определенного количества файлов cookie. WebDriverIO хорошо справился с этим, но этап внедрения файлов cookie резко увеличил разброс времени выполнения. Иногда казалось, что на этом этапе происходит зависание более 5 секунд.

Теперь мы отступим назад и сравним время выполнения в разных сценариях:

Сомневаетесь в результатах? Запустите свой собственный бенчмарк! Вы можете использовать наши сценарии тестирования, представленные выше. Не уверены в настройке? Не стесняйтесь сообщать об этом, чтобы сделать сравнение лучше.

Заключение

Прежде всего, давайте рассмотрим инструменты от самых быстрых к самым медленным для обоих сценариев тестирования:

Наше исследование производительности позволило сделать несколько интересных выводов:

• Хотя Puppeteer и Playwright используют сходные API, похоже, что Puppeteer имеет значительное преимущество в скорости на более коротких скриптах (по нашим наблюдениям, выигрыш составляет около 30%).

• Скрипты Puppeteer и Playwright показывают более быстрое время выполнения (около 20% в сценариях E2E) по сравнению с вариантами Selenium и DevTools WebDriverIO.

• Протоколы автоматизации WebDriverIO, WebDriver и DevTools показали сопоставимое время выполнения.

Выводы

• При запуске большого количества более быстрых сценариев, если нет необходимости в кросс-браузерности, возможно, стоит запустить Puppeteer, чтобы сэкономить время. В более длинных сценариях E2E разница сводится к минимуму.

• Имеет смысл подумать, необходим ли вам запуск установки большего количества barebone-систем. Возможно, что удобство дополнительных инструментов WebDriverIO стоит того, чтобы потратить немного больше времени на ожидание результатов.

• Колебания времени выполнения могут не иметь большого значения в бенчмарках, но в реальном мире они могут накапливаться и замедлять сборку. Помните об этом при выборе средства автоматизации.

• Глядя на прогресс с обеих сторон, мы задаемся вопросом, выйдет ли в будущем DevTools на передний план или WebDriver будет продолжать играть центральную роль в автоматизации браузеров. Мы предлагаем обратить внимание на обе технологии.

К переводу этой статьи нас подтолкнуло то, что мы, как и автор, при автоматизации тестирования наших проектов чаще всего использовали возможности WebDriver. Оценивая результаты данного исследования, мы планируем опробовать новые инструменты, такие как Puppeteer и Playwright.

Спасибо за внимание! Надеемся, что перевод был вам полезен.