Блог компании россельхозбанк

Смоделируем ситуацию: Вы являетесь членом команды веб-разработчиков, занимающихся созданием frontend-части молодого интернет-ресурса на базе React. И вот, когда уже начинает казаться что ваша разработка достигла определенной функциональной, качественной и эстетической кондиции, вы сталкиваетесь с достаточно сложным и не менее интересным вопросом: А что делать с SEO? Как добиться качественной конверсии от поисковых систем? Как сделать так, чтобы о вашем ресурсе узнал весь мир, не вкладывая в это огромного количества денег за платные рекламные компании либо сил в крупномасштабную дополнительную разработку? Как заставить контент вашего Single Page Application работать на вас в поисковых выдачах и приносить клиентов? Интересно? Тогда поехали

Привет! Меня зовут Антон и я являюсь full-stack-разработчиком со стажем работы более 12 лет. За время своей трудовой деятельности я работал над проектами различной сложности и с разнообразными стеками технологий. Последние 6 лет я сосредоточил scope своего внимания в большей мере на frontend, который стал в итоге профильным направлением, так как привлек у меня больший интерес по сравнению с backend-ом (не хочу при этом сказать, что backend в целом менее интересен. Просто дело вкуса и особенности развития карьеры исключительно в моём личном случае).

В данный момент я являюсь team-лидером команды разработчиков на проекте Своё.Жильё - это экосистема Россельхозбанка с помощью которой можно выбрать недвижимость, рассчитать стоимость кредита, подать заявку и получить ответ в режиме онлайн. Уже сейчас в экосистеме есть возможность оформить заявку на ипотечный кредит и выбрать недвижимость из более чем 1,2 млн вариантов жилья. Набор онлайн-сервисов позволяет сократить количество посещений офисов банка до одного непосредственно для подписания кредитного договора и проведения расчетов с продавцом.

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

Используемый стек и преследуемые цели

Не буду заострять внимание на полном стеке frontend технологий, используемых экосистеме Своё Жилье, а опишу лишь то, что действительно важно для дальнейшего рассказа, чтобы стало понятно, с чем в результате мы имеем дело. А именно:

• Webpack

• React

• Redux

Из вышеперечисленного сразу становится ясно, что на выходе мы получаем Single Page Application на React, что влечет за собой как безграничное количество возможностей и плюсов данного стека, так и ряд подводных камней, связанных с реализацией SEO-friendly ресурса, который сможет в конечном счёте выполнить ряд задач, важных для продвижения в поисковых системах, социальных сетях и так далее:

• Поисковой робот должен видеть все ссылки на страницы сайта;

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

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

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

Казалось бы, перечень задач не так велик и решался бы практически из коробки на любом обычном относительно стандартном интернет ресурсе Но тут нужно вернуться к тому, что мы имеем дело не с привычным веб-сайтом, у которого все страницы с их контентом отдаются с backend-а, а с Single Page Application, у которого контент страничек рендерится (отрисовывается средствами js) на стороне браузера. А ведь львиная доля поисковых роботов не умеет выполнять js-код при обходе интернет-ресурсов, и поэтому они попросту не увидят наш контент (Google умеет, но делает это пока недостаточно корректно и эффективно. Да и кроме Google, есть еще множество других целевых поисковых систем и кейсов, при которых голый SPA не сможет решить поставленные задачи).

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

Для того, чтобы поисковые роботы увидели страницы сайта, им необходимо иметь возможность прочесть контент страницы, в том числе содержащий ссылки на другие страницы (при этом подход с sitemap я тут описывать не буду, но упомянул, на случай если кому-то станет интересно, можете погуглить. Мы пока обходимся без карт). Из этого вытекает, что поисковой робот всё же должен по старинке загрузить html-разметку, содержащую контент страницы с web-сервера. Ну и конечно же, каждая из страниц, запрашиваемых с web-сервера, должна отдавать код 200 (случаи с необходимостью переадресаций с кодом 301 я тут также рассматривать не буду) и приходить в виде стандартного html-документа, содержащего текстовый и медиа-контент данной страницы, а так же ссылки на другие страницы и, конечно же, необходимые для SEO-оптимизации элементы, такие как ряд обязательных meta-тегов, заголовков и так далее. Общий список необходимого SEO-тюнинга любого веб-ресурса достаточно велик и про него можно написать отдельный материал и не один. Затронем тут обязательный план минимум, который включит в себя следующие пункты:

1 - Каждая из страниц ресурса должна в блоке <head> включать в себя:

• Meta-тег title (заголовок страницы)

• Meta-тег description (описание страницы)

• Meta-тег keywords (перечень ключевых фраз)

2 - Каждая страница должна иметь в блоке <body> основной заголовок внутри html-элемента <h1> расположенный как можно выше перед началом текстового контента.

3 - Каждое изображение, которое присутствует на странице в виде html-элемента <img>, должно иметь атрибут alt, описывающий содержимое данного изображения.

Ну и конечно же, на сайте не должно быть битых ссылок отдающих с web-сервера код ошибки 404 (либо иной) или какой-либо пустой контент вместо ожидаемого.

И тут снова вспоминаем, что у нас SPA (Single Page Application) и с backend-а приходит лишь пустая часть разметки html-документа, включающая в себя информацию для загрузки js и css кода, который после загрузки и выполнения отрисует нам контент запрошенной страницы.

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

Подбор решения и реализация

Что же делать, если у Вас уже есть готовый SPA, либо просто отточенный архитектурный подход, нарушать который ради SEO было бы кощунством?

Ответ: Реализация пререндеринга, как конечного шага сборки приложения. Пререндеринг это процесс выполнения js-кода после его основной сборки и сохранение получившихся html-копий отрисованных страниц, которые в последствии и будут отдаваться с web-сервера при соответствующих запросах.

Пререндеринг

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

Конечно есть такие решения как Next.Js и ему подобные (а также другие способы реализации того же SSR). И я не могу не упомянуть об этом. Но изучив их, я пришел к выводу, что они вносят ряд ограничений (либо усложнений) в процесс конфигурации основной сборки и имеют крайне заметное влияние на архитектуру приложения. Также, есть сторонние внешние сервисы пререндеринга, но для закрытой экосистемы банка лишний внешний инструмент был бы крайне нежелателен (и опять же, зачем перекладывать зону ответственности на внешний инструмент, если можно реализовать его функционал внутри проекта).

После анализа, я пришел к максимально подходящему нам инструменту для покрытия описанных кейсов, реализующему проход по страницам SPA на React (и не только) и создание html-копий страниц.

Выбор пал на React-Snap.

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

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

Установка React-Snap не вызывает никаких дополнительных вопросов, так как его пакет доступен для скачивания стандартным образом из npm (и yarn).

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

Конфигурация запуска React-Snap описывается в корневом файле package.json проекта. Давайте рассмотрим пример минимальной конфигурации:

"scripts": {    // Необходимые команды запуска hot-а, сборки и т.п.    "build:production": "webpack --mode production && react-snap"    // Другие необходимые команды},"reactSnap": {    "source": "dist", // Каталог собранного приложения    "destination": "dist", // Каталог для сохранения html-копий    "include": [ // Список энтрипоинтов для обхода страниц        "/",        "/404",        "/500"        // Другие необходимые энрипоинты    ]}

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

К примеру, запуск React-Snap можно осуществить, просто добавив в блок scripts команду:

"postbuild": "react-snap"

Но тогда он будет запускаться после каждого билда, а в проекте их может быть несколько вариантов (например, для production и тестового стенда, где на последнем нам наоборот, может быть не нужен SEO и какой-либо еще функционал, такой как инструменты аналитики типа Google Analytics и т.п.).

Что касается блока include, его желательно описать, иначе, например, html-копия для странички ошибки (500, либо другая техническая страница, при наличии) не будет создана, так как не на одной из страниц сайта не фигурирует ни одной ссылки на нее. Как следствие, React-Snap не узнает о её наличии. В теории и поисковик на них ходить не должен, но бывают случаи, когда страница создается для распространения ссылки за пределами сайта, а на сайте на нее ссылки может и не быть (к примеру, баннеры для рекламных компаний и тому подобное). Это как раз тот самый случай. Тут стоит проанализировать, нет ли у вас еще каких-то (возможно аналогичных технических) страничек, на которые прямые ссылки на сайте отсутствуют.

Далее, для нормальной работы самого React-приложения у конечного пользователя, поверх DOM который придёт с web-сервера, нам потребуется внести небольшую правку в корневой render:

import { hydrate, render } from "react-dom";//  Ваш кодconst rootElement = document.getElementById("root"); // (или ваш id при олтличии)if (rootElement.hasChildNodes()) { // Если в корневом элементе есть контент, то  hydrate(<App />, rootElement); // "цепляем" приложение на существующий DOM.} else { // Иначе рендерим приложение стандартным образом  render(<App />, rootElement);}

Вот и всё что нам потребуется для начала (а возможно в ряде случаев и в принципе всё что необходимо будет сделать). Уже можно попробовать выполнить build с созданием html-копий страниц вашего ресурса. На выходе (с приведенным выше конфигом) в каталоге /dist вы получите тот же набор js и css файлов (а также других ресурсов), что и ранее, index.html, плюс файл 200.html и другие html-файлы с копиями контента ваших страниц.

Для полноты картины сразу опишу небольшой подводный камень с пояснением, для понимания, что при таком подходе на реальном production-web-сервере вам нужно будет позаботиться о следующем нюансе

Ранее у вас скорее всего по умолчанию на любой запрос, если ресурс отсутствует физически на сервере, отдавалась index.html, которая запускала приложение. Далее, в соответствии с запросом из адресной строки, приложение отрисовывало необходимую страницу, либо страницу 404, если не находило соответствие. Теперь же, наш index.html уже не является пустым, а содержит контент главной страницы. Но страничка с пустой html-разметкой для случая попытки запуска страницы без html-копии всё же существует. Это та самая вышеупомянутая 200.html. Таким образом, на web-сервере необходимо перенастроить дефолтный ресурс для случая 404 с index.html на 200.html, чтобы избежать открытия кривых страниц (с контентом главной страницы поверх которого будет пытаться запуститься наш SPA) при обращении на страницы, html-копий для которых нет, либо просто при некорректном обращении на несуществующую страницу.

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

Meta-теги, заголовки, описания

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

<!doctype html><html lang="ru">  <head>    <meta charset="utf-8">    <!-- ...и т.д. -->    <title>Контент meta-тега Title</title>    <meta name="description" content="Контент meta-тега Description">    <meta name="keywords" content="ключевые фразы для meta-тега keywords">  </head>  <body>    <div id="root">      <div className="content">        <h1>Заголовок страницы H1</h1>        <p>Текстовый контент страницы...</p>        <img alt="Описание изображения" src="...">        <!-- ...и т.д. -->      </div>    </div>    <script src="http://personeltest.ru/aways/habr.com/application.js"></script>  </body></html>

На заголовки <h1> и alt-ы для картинок особое внимание заострять не буду. Тут всё просто: идем по существующему js-коду react-компонентов страниц и добавляем там, где этого нет (а также не забываем это делать в дальнейшем для новых компонентов). А вот относительно meta-тегов title, description и keywords стоит немного поговорить отдельно. Они должны быть уникальными для каждой страницы. О том, зачем нужен каждый из них и как его стоит формировать, будет полезнее почитать более профильные материалы по SEO. Для нас же стоит более прагматичная задача реализовать средствами js изменение контента данных тегов при навигации между страницами (таким образом у каждой html-копии страницы они будут разными как и положено, а при дальнейшей навигации по приложению после его запуска, они так же будут меняться в зависимости от текущей странички, но уже силами js приложения).

В целом, для реализации данного функционала есть готовый инструмент:

React-Helmet

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

В итоге мы добавили необходимые для эффективного SEO элементы на страницы нашего интернет-ресурса.

Подводные камни, нюансы реализации и советы

Хочу в первую очередь затронуть один нюанс, знать о котором будет полезно при дальнейшей разработке. Как правило, при создании html-копий рано или поздно появятся кейсы, при которых поведение приложения для пререндера должно будет отличаться от поведения приложения в браузере у реального пользователя. Это может касаться случаев, начиная от наличия каких-либо прелоадеров, которые не нужны в html-копиях или статистического функционала, который не должен выполняться на этапе создания html-копий (и возможно даже будет вызывать ошибки при их создании) заканчивая банальным объявлением адреса для API backend-а, который вероятно настроен у вас для hot в разделе devServer webpack-конфига как proxy, а в самом приложении указан как относительный, что не заработает, так как во время работы пререндера hot не запущен и нужно ходить на реальный адрес backend-а. Как вариант, могу также привести пример в виде распространенного окошка, которое сейчас есть практически на любом интернет-ресурсе, говорящее о том, что на сайте используются Cookies. Как правило, окошко отображается на любой страничке, пока пользователь в какой-то момент один раз не закроет его. Но вот беда: пререндер то не знает, что что-то нужно закрыть, а соответственно контент данного окошка будет присутствовать на всех html-копиях, что плохо для SEO.

Но не всё так страшно и решение есть. В таких местах в приложении мы можем использовать условие для запуска тех или иных функций (или использования тех или иных переменных, как в примере с адресом API). Дело в том, что у пререндера есть специфическое имя user-agent-а ReactSnap (кстати через параметры можно задать своё при необходимости). К примеру:

const isPrerender = navigator.userAgent === "ReactSnap";

Как и где это можно объявить и использовать, думаю, не нуждается в дальнейшем объяснении. Полагаю, как минимум пара мест, где это пригодится, найдётся в любом проекте.

Также стоит затронуть случай, с которым с большой долей вероятности вам придется столкнуться. А именно: React-Snap обошел не все страницы, либо, нам стало необходимо, чтобы он не заходил в какие-либо разделы или на определенные страницы и не создавал для них html-копии.

Тут сразу стоит внести понимание в процесс работы пререндера React-Snap. Он запускает наше приложение и осуществляет обход по ссылкам, найденным на страницах. При этом учитываются именно html-элементы <a>. Если пререндер не сохранил html-копию для какой-либо страницы (либо мы намеренно хотим этого добиться), то скорее всего переход на эту страницу сделан (либо вы намеренно можете так сделать) с использованием, к примеру, onClick а не через обязательный атрибут ссылки - href. Тут нужно упомянуть, что стандартные компоненты Link либо NavLink из react-router-dom фактически создают в DOM именно html-элемент <a> с href, так что если не отбиваться от классических подходов, то проблем не будет.

Следующим полезным знанием будет то, что нам обязательно необходимо позаботиться о минификации размеров DOM, который будет содержаться в наших html-копиях, так как большой html-документ будет дольше загружаться с backend-а, съедать больше трафика, да и поисковые роботы могут попросту не добраться до необходимого контента, если, к примеру, у вас в <head> документа все стили заинлайнины, как и все svg-изображения в <body>, что раздует каждую из html-копий до огромных размеров. Для понимания: если логотип вашего ресурса рендерится как inline-svg, то в файле каждой html-копии он будет присутствовать именно в таком виде.

Выход: настроить webpack таким образом, чтобы при сборке все стили складывались в css-файлы, а inline-svg заменить на использование <img> (либо средствами css) для отображения картинок (и то и другое будет загружаться один раз, а далее браться из кеша браузера и, что главное, задублированный контент таких ресурсов будет отсутствовать в html-копиях).

Еще один небольшой совет: общее количество и список всех созданных html-копий страниц, либо ошибок создания и различные вызванные редиректы (к примеру 404), а также прочие проблемные места мы сможем сразу увидеть и проанализировать благодаря достаточно понятному и подробному логу, который будет выводиться в процессе работы пререндера React-Snap. Не стоит забывать смотреть в него после сборки, так как на этом этапе мы всегда сможем увидеть те же проблемы на сайте, что увидит поисковой робот, но при этом у нас будет возможность заблаговременно что-то поправить при необходимости.

Заключение

Пожалуй, вышеописанного будет достаточно, чтобы начать и относительно быстро реализовать SEO-friendly сайт, написанный в виде Single Page Application. Далее всё будет зависеть лишь от особенностей конкретно вашего интернет-ресурса и тех целей, которые вы будете преследовать при его создании. Я постарался описать основные нюансы и подводные камни, с которыми пришлось столкнуться в процессе аналогичной разработки.

Основные плюсы данного подхода заключаются в том, что мы получаем инструментарий, который не требует архитектурных доработок приложения, дополнительного обучения программистов в команде и высоких трудозатрат на реализацию. После внедрения технологии, вы просто продолжаете разрабатывать ваше приложение по всем традициям React и придерживаясь ранее реализованной архитектуры. При этом ваше приложение уже не будет являться обычным SPA в привычном смысле, так как старт любой страницы будет сопровождаться загрузкой копии содержимого данной страницы, а дальнейшая навигация по приложению будет осуществляться уже привычным образом средствами SPA, что позволит поисковым роботам полноценно взаимодействовать с вашим контентом и выводить в результатах поиска актуальные ссылки с соответствующими описаниями страниц, а конечным пользователям как и ранее будет доступен весь спектр функционала Single Page Application.

Ну вот мы и добрались до финала. Сейчас вам удалось познакомиться с реально работающим на продакшн-версии проекта Своё.Жильё от Россельхозбанка подходом по реализации SEO-friendly интернет-ресурса на примере React-приложения и рассмотреть основные тезисы и подводные камни процесса создания SEO-эффективного сайта на основе SPA. Надеюсь, что полученные в данном материале знания будут полезны и найдут применение. Спасибо за уделённое на прочтение время.

Всем привет, на связи Лиза, UX-писатель, и Стася, UX-аналитик Центра Развития Финансовых Технологий Россельхозбанка.

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

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

Поиск решения

Для начала мы разделили накопившиеся вопросы по группам. Их оказалось две.
К первой группе относились вопросы по стилистике, используемым словам и орфографии:

• Беды с ё: пишем ли мы Своё Фермерство или допустимо писать Свое Фермерство

• Склоняем ли название бренда?

• Как обращаемся к пользователям: на ты, на вы, а может лучше на Вы?

• Как правильно называть нашу систему: платформа, сайт или площадка?

• Какие аббревиатуры стоит расшифровывать, а какие настолько очевидны специалистам агросферы, что объяснения будут казаться лишними?

• Используем ли мы в наших текстах строгое АПК или радушное сельское хозяйство?

Во вторую группу вошли следующие вопросы:

• Как позиционировать систему для разных целевых аудиторий?

• Как правильно расставить акценты, рассказывая о новых фичах?

• Допустимо ли шутить в текстах интерфейсов? Если да, то какой юмор допустим?

• Нужен ли онбординг и насколько подробно нужно объяснять нашим пользователям, как пользоваться интерфейсом?

Мы поняли, что вопросы из первой группы отпадут, когда мы создадим редполитику. Чтобы найти ответы на вторую группу вопросов, мы решили описать Tone of Voice (голос бренда).

Создание редполитики

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

Верхнеуровневая структура нашей редполитики получилась следующей:

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

2. Используемый стиль и слова.
   В этом разделе решаем, как обращаемся к пользователю (на ты или вы) и как их называем (господа, друзья, коллеги?). Определяемся, используем ли восклицательные знаки, выбираем ли эмоционально-нейтральный или эмоционально-насыщенный тон. При формировании этой части нам очень помог Tone of Voice. Поэтому советуем приступать к этому документу уже после того, как проработаете голос бренда.
   Отрекаемся от слов-паразитов и бесполезных усилителей и прилагаем их список.

3. Веб-элементы.
   Рассказываем, какой текст может быть на кнопках, а какой нет, пишем правила. Также прописываем шаблоны текстов для модальных окон, экранов успеха, согласия с обработкой персональных данных. Это позволит сохранить единообразие во всей системе и сэкономит время UX-писателю.

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

Создание Tone of Voice (голоса бренда)

Tone of Voice отвечает на вопросы что мы пишем и как, но, в отличие от редполитики, акцентирует внимание на эмоциональной стороне текстов.

Определяем целевую аудиторию

Мы начали создание Tone of Voice с определения групп нашей целевой аудитории к кому именно мы будем обращаться? Глобально наши потенциальные пользователи все, кто связан с сельским хозяйством. Мы разделили их на 7 основных групп и выделили наиболее приоритетные:

• Поставщики товаров для фермеров

• Фермеры

• Потребители (те, кто хотел бы покупать фермерскую продукцию в розницу)

По отношению к ним мы и будем выстраивать основной тон. Далее рассмотрим создание Tone of Voice для фермеров.

Вырабатываем правила для Tone of Voice

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

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

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

• Безопасность

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

• Заинтересованность в проблемах пользователей, внимательность к их потребностям

• Уважение к труду и продукту, который производят фермеры

Также, исходя из миссии экосистемы и ценностей, которые мы разделяем с нашими пользователями (приведены ниже), мы выделили основные цели наших клиентов:

• Заинтересованность в агротехнологиях и выходу в онлайн

• Стремление к расширению бизнеса

• Уважение к чужому труду

• Энтузиазм от вовлечения в крупное сообщество единомышленников

Создаем персонажа

Чтобы завершить наш Tone of Voice, придать душевности нашему бренду, а также понять, как и в каком тоне мы будем общаться с пользователями, мы решили описать персонажа, от лица которого будем обращаться к нашей целевой аудитории.

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

Миссия:

• Собрать в одном месте всё необходимое для ведения и развития агробизнеса

• Перевести в онлайн процессы управления бизнесом

• Сделать доступными агротехнологии для всех фермерских хозяйств

• Помогать кооперироваться фермерам друг с другом, находить полезные связи

• Предоставлять лучшие, наиболее выгодные на рынке банковские продукты и предложения

• Популяризировать фермерство среди населения

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

Ценности:

• Агротехнологии это будущее сельского хозяйства

• Любовь к Родине, патриотизм, вклад в развитие сельского хозяйства в нашей стране

• Любовь к природе, земле, животным

• Любовь к семье, забота о благосостоянии семьи

• Пропаганда здорового образа жизни, трудолюбие, активность

Для качественного и комфортного общения с пользователями мы определили голос нашей компании. А точнее, создали персонажа, который олицетворяет нашу компанию. И уже его наделили голосом, которым он будет говорить с пользователями.

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

Оттолкнёмся от последнего:

Как может выиграть фермер от использования нашей платформы?

• Оформить документы удалённо

• Проконсультироваться с ветеринаром через онлайн-сервис

• Узнать о новых агротехнологиях и внедрить их в своё хозяйство

• Подобрать семена под свои земли и получить с них хороший урожай

• Проследить за состоянием хозяйства с помощью сервиса собрать больше урожая

Со всем этим может помочь IT-специалист. Особенно специалист, погружённый в сферу сельского хозяйства.

Мы кратко описали его внешность, биографию и характер.

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

Примеры использования

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

• Переделали экран ошибки 500

• "Почистили" текст о площадке

• Улучшили описания сервисов

У нас ещё много работы: экосистема Своё развивается быстро, выпускает новые проекты и дорабатывает уже выпущенные.

Поэтому много текстов, кнопок и подсказок ждут, когда их проговорит наш персонаж. Будем держать вас в курсе!

_{Соавтор:Кузнецова Юлия Андреевна - UX-писатель Экосистемы РСХБ}

Каким должен быть дизайнер в банке, чтобы и продукт хороший создавал, и коллеги не жаловались. Смотрим через призму софт-навыков вместе с UX-дизайнерами РСХБ.

#1 Коммуникабельность: не просто коллега человек

Дизайнер отличная профессия для интровертов. Рисуешь интерфейсы, слушаешь музыку, ни с кем не общаешься На самом деле, нет!

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

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

Итог: учись разговаривать с людьми и старайся взаимодействовать с коллегами так, как хотел бы, чтобы они взаимодействовали с тобой.

#2 Презентация: готов объяснить свою работу

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

Крутой дизайнер умеет переключить фокус с творческого и ранимого художника на хладнокровного адвоката. Если кто-то говорит: Это плохо сделано, это не значит, что ты плохой. Это значит, что коллега видит в данном решении слабые стороны. Продвинутый дизайнер отключает эмоции и включает голову. Объясняет и обосновывает свою позицию. Задаёт вопросы, внимательно слушает, делает все, чтобы добраться до истины и хорошего продукта.

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

#3 Аналитика: думает не только о красоте

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

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

С одной стороны, ты должен на интуитивном уровне понимать психологию взаимодействия с интерфейсом. А с другой всегда остаешься скептиком и тестировать свои гипотезы. Порой пользователи воспринимают ту или иную функцию абсолютно непредсказуемо и не понимают твоей задумки. Одна только фраза Мне нравится. Думаю пользователям понравится тоже не поможет. Нужна аналитика. Много аналитики.

Итог: относись к своим решениям непредвзято. Любая хорошая идея может оказаться плохой во время теста. Исследования помогут тебе делать качественный продукт и соответственно лучше понимать пользователей.

#4 Понимание бизнес-процесса: переводит с банковского языка на человеческий

Юный дизайнер: мастерски работает в Фигме, любит компоненты, боготворит филигранную верстку.

Продвинутый дизайнер: понимает, как устроен бизнес и финансы.

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

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

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

#5 Любознательность: постоянно учится новому

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

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

В начале каждого года MIT публикует дайджест о 10-ти самых прорывных технологиях грядущего года MITTechnologyReview. В этом году выпуск стал юбилейным, так как традиция рассказывать о технологиях, которые в ближайшем будущем сделают жизни миллионов людей лучше, зародилась еще в далеком 2001 году. Давайте вместе рассмотрим каждую технологию по отдельности и определим её пользу.

1.Мессенджер РНК (мРНК)

Актуальность:Во всем мире более 2 миллионов человек умерли от covid-19. Вакцины на основе мРНК эффективны примерно на 95%

Лидеры рынка:

• BioNTech

• GreenLight Biosciences

• Moderna Therapeutics

• Pfizer

• Strand Therapeutics

Доступность:Сейчас

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

Сообщение (код гена), которое вакцина добавляет в клетки людей, заимствовано из самого коронавируса. Этот белок сам по себе не может сделать человека больным: вместо этого он вызывает сильный иммунный ответ, который, согласно крупным исследованиям, завершенным в декабре, предотвратил около 95% случаевCOVID-19.

Помимо потенциального прекращения пандемии, прорыв вакцины показывает, как РНК-мессенджер может предложить новый подход к созданию лекарств.

Исследователи считают, что в ближайшем будущем прививки, могут привести к вакцинам против герпеса и малярии, лучшим вакцинам против гриппа и, если микробCOVID-19 продолжит мутировать, обновленным вакцинам против коронавируса. Также ученые считают, что в будущем медицинские технологии позволят исправить гены рака, серповидно-клеточных заболеваний и, возможно, даже ВИЧ.

Еще в марте 2020 года, когда начинались программы вакцинации, скептики говорили, что мессенджерная РНК все еще остается недоказанной технологией. Даже в этом журнале говорилось, что на создание подобной вакцины потребуется как минимум 18 месяцев прогноз, который оказался ошибочным на целых девять месяцев.

Действительно ли мессенджерная РНК лучшая вакцина? Возможно. Есть некоторые побочные эффекты, но оба укола эффективны примерно на 95% (то есть они останавливают 95 из 100 случаев), что до сих пор не имеет себе равных среди других вакцинCOVID-19, а также куда эффективнее большинства вакцин против гриппа. Другая инъекция, сделанная AstraZeneca с использованием искусственного вируса простуды, эффективна на 70%. Вакцина, разработанная в Китае с использованием дезактивированных микробовCOVID-19, защитила только половину людей, получивших его, хотя и остановил тяжелую болезнь.

2. GTP-3

Актуальность:Большие компьютерные модели, изучающие естественный язык общения, - это прорывной шаг к изучению ИИ, способному понимать человеческий мир и взаимодействовать с ним

Лидеры рынка:

• OpenAI

• Google

• Facebook

Доступность:Сейчас

Созданная исследовательской лабораторией OpenAI в Сан-Франциско,GTP-3 представляет собой большую языковую модель - алгоритм, оснащенный глубоким обучением и способный использовать тексты из тысячи различных книг, а также свободно пользоваться информацией из интернета, чтобы связывать слова в предложения. Когда он был запущен в 2020 году, его способность имитировать написанный человеком текст со сверхъестественным реализмом казалась многим вехой на пути к истинному машинному интеллекту.

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

Большие языковые модели также имеют много практических применений. Они являются основой для лучших чат-ботов, которые ведут разговоры максимально приближенные к человеческим; они могут генерировать статьи и истории о чем угодно, они могут суммировать фрагменты текста или отвечать на запросы о них. Доступ к GPT-3 возможен только по приглашению, но люди уже использовали его для разных целей, например, генерация идей для стартапов или создание приключенческой игры с применением искусственным интеллектом, действие которой происходит в подземелье.

Способности GPT-3 также затрудняют игнорирование растущих проблем ИИ. Его огромное потребление энергии-плохая новость для климата: исследователи из Копенгагенского университета в Дании подсчитали, что обучение GPT-3 имело бы примерно такой же углеродный след, как вождение автомобиля на расстояние до Луны и обратно, если бы оно было обучено в центре обработки данных, полностью работающем на ископаемом топливе. А затраты на такую подготовку по оценкам некоторых экспертов, в случае GPT-3 они составляют не менее 10 миллионов долларов делают последние исследования недоступными для всех, кроме самых богатых лабораторий.

Еще одна проблема заключается в том, что GPT-3 впитывает большую часть дезинформации и предубеждений, которые он находит в Интернете, и воспроизводит их по требованию. Некоторые разработчики утверждают, что GPT-3 и все человекоподобные языковые модели должны иметь предупреждение о безопасности, наклейку Оберегайся пользователь, предупреждающую людей о том, что они общаются с программным обеспечением, а не с человеком, которое может ошибаться в своих суждениях и убеждениях.

3. Data Trusts

Актуальность:Крупные компании и правительства неправильно обрабатывают и пользуются нашими данными. Доверие к данным может помочь нам вернуть себе свободу действий

Лидеры рынка:

• Data Trusts Initiative

• Digital Public

• Open Data Institute

• National Governments

• European Commission

Доступность:Ближайшие2-3года

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

Трасты данных относительно новое понятие. В 2017 году правительство Великобритании впервые предложило их как способ сделать крупные наборы данных доступными для обучения искусственному интеллекту. В начале 2020 года Европейская комиссия предложила использовать трасты данных как способ сделать больше данных доступными для исследований и инноваций. А в июле 2020 года правительство Индии выступило с планом, в котором они были представлены как механизм, дающий общинам больший контроль над своими данными.

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

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

2017 году дочерняя компания Google Sidewalk Labs приобрела права на развитие прибрежной набережной Торонто в интеллектуальный район, оснащенный датчиками. Но то, что некоторые приветствовали как утопию, другие рассматривали как еще один случай, когда крупные технологические компании вторглись в общественное достояние, пылесося данные жителей в процессе.

Sidewalk Labs предложила создать гражданский информационный фонд, чтобы гарантировать, что данные, собранные и используемые в Quayside, принесут пользу общественности. Предложение состояло в том, что любой субъект, желающий разместить датчик на причале, должен будет запросить лицензию как на сбор, так и на использование данных. Наблюдательный совет, состоящий из членов сообщества, будет контролировать и обеспечивать соблюдение этого сбора и использования.

Сам план был ошибочным, и Sidewalk Labs отказалась от проекта Quayside в мае 2020 года, но предложение компании продемонстрировало обещание доверия к данным. Идея создания их для управления данными, собранными в общественном контексте (например, в умных городах или для инициатив в области общественного здравоохранения), продолжает жить.

4. Lithium-metal batteries

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

Лидеры рынка:

• QuantumScape

• Samsung

• Advanced Institute of Technology

• Solid Power

• 24M

Доступность:2025 год

Несмотря на всю шумиху и надежды вокруг электромобилей, они по-прежнему составляют всего около 2% продаж новых автомобилей в США и чуть больше во всем мире. Для многих покупателей они слишком дорогие, их ассортимент ограничен, а зарядка не такая быстрая и удобная, как заправка у бензоколонки. Все эти ограничения связаны с литий-ионными батареями, которые питают транспортные средства. Они дорогие, тяжелые и быстро изнашиваются. Что еще хуже, батареи работают на жидких электролитах, которые могут вспыхнуть во время столкновений, как это было совсем недавно сTeslaв штате Техас, например.Чтобы сделать электромобили более конкурентоспособными потребуется прорывная батарея, которая исправит эти недостатки. По крайней мере, это аргумент Джагдипа Сингха, исполнительного директора QuantumScape, стартапа из Кремниевой долины, который утверждает, что совместно с командой профессионалов разработал именно такую технологию.

Быстрый заряд и продолжительное использование

В обычной литий-ионной батарее один из двух электродов, анод, сделан в основном из графита. Это форма углерода, которая может легко поглощать и освобождать заряженные ионы лития, перемещаясь между анодом и катодом через электролит. Этот поток заряженных частиц производит электрический ток, который вытекает из батареи для питания механизма. Но графит это просто хозяин для ионов лития, он не накапливает энергию и не производит ток сам по себе. В литий-металлической батарее сам анод сделан из лития. Это означает, что каждый атом в аноде батареи работает, создавая ток. Теоретически литий-металлический анод может хранить на 50% больше энергии, чем графитовый анод того же веса и объема.

В ходе онлайн-презентации в декабре 2020 QuantumScape продемонстрировал серию диаграмм, показывающих, что однослойная лабораторная версия аккумулятора может быть заряжена более чем на 80% своей емкости за 15 минут, расходуется тысячи километров и прекрасно работает при низких температурах. Компания ожидает, что батареи смогут увеличить дальность действия электромобилей более чем на 80%: автомобиль, который проезжает 400 км на одном заряде сегодня, в будущем сможет проехать 720 км.

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

5. Digital Contact Tracing

Актуальность: Технологии по мониторингу контакта сCOVID-19 не соответствовали ранее ожидаемым результатам, однако разработчикам было чему поучиться и сейчас отслеживание и предотвращение заражения работают совершенно на новом уровне

Лидеры рынка:

• Apple

• Google

Доступность:Сейчас

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

Эта идея вызвала замечательную волну развития и сотрудничества. Некоторые программисты запускали системы в течение нескольких недель, открывали источники своего кода и свободно делились им, так, что такие далекие друг от друга страны, как Канада и Монголия, могли по существу использовать одну и ту же систему. Тем временемAppleиGoogle, соперники почти во всех отношениях, сотрудничали над системой, которая работала на смартфонах и сохраняла анонимность и конфиденциальность данных о здоровье. К январю 2021MITTechnologyReviewотследила 77 приложений для уведомления граждан о контакте сCOVID-19, используемых правительствами по всему миру.

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

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

6. Hyper-Accurate Positioning

Актуальность:GPS-системы уже трансформировали многие промышленные отрасли и создали совершенное новые сервисы, например, поиск автомобильных попутчиков. Более точные системы определения геолокации породят больше возможностей.

Лидеры рынка:

• China National Space Administration

• US Air Force

• ColdQuanta

Доступность:Сейчас

Мощный оползень худший за последние десятилетия обрушился на дом Ду Фанмина в южно-китайской провинции Хунань 6 июля. К счастью, он был в безопасности один из 33 жителей деревни, которые были эвакуированы благодаря ранним предупреждениям, включенным передовыми технологиями геолокации, которые могут обеспечить более точные показания, чем когда - либо прежде. С помощью недавно построенной китайской глобальной навигационной спутниковой системы BeiDou (Большая медведица) и ее наземным станциям, датчики положения могут обнаруживать тонкие изменения поверхности земли в подверженных оползням регионах по всему Китаю. Движение на несколько метров можно заметить в режиме реального времени, а точность постобработки может достигать миллиметрового уровня.

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

В июне 2020 года Китай завершил развертывание своей спутниковой системы BeiDou в качестве альтернативы GPS. Расширенная за два десятилетия из региональной в глобальную сеть, BeiDou теперь имеет 44 спутника, работающих на трех различных орбитах. Он предоставляет услуги определения геолокации любому человеку в мире со средней точностью от 1,5 до двух метров.

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

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

7. Remote Everything

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

Лидеры рынка:

• Babyl Rwanda

• Daktari Africa

• Microsoft

• Nerdy

• Teladoc

• Zoom

• Zuoyebang

Доступность:Сейчас

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

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

Онлайн обучение

На пике своего развития в апреле прошлого года пандемия вынудила закрыть школы более чем в 170 странах, затронув почти 1,6 миллиарда детей. По мере того, как традиционное школьное образование стало виртуальным на большей части земного шара, Азия стала свидетелем параллельной тенденции всплеск спроса на услуги, подобные тем, что предлагает гонконгская онлайн-репетиторская компания Snapask. В настоящее время Snapask имеет более 3,5 миллионов пользователей в девяти азиатских странах вдвое больше, чем до пандемии.

Другие компании ed-tech в регионе сообщили об аналогичном росте. Byju's, обучающее приложение и второй по ценности стартап в Индии, увидел, что его число пользователей взлетело на треть, почти до 70 миллионов, когда он предложил свое приложение бесплатно после закрытия школ по всей стране в марте прошлого года. Когда ведущая китайская платформа онлайн-обучения Yuanfudao сделала то же самое в начале 2020 года, ее система рухнула под нагрузкой: подписалось более 5 миллионов человек.

Все это говорит о том, что неравенство является большим препятствием для расширения масштабов как виртуального обучения, так и онлайн-обучения. Например, только 56% людей в Индонезии имеют доступ в Интернет, согласно статистике 2019 года. И даже в более богатых странах, таких как Южная Корея, где 99,5% населения имеет доступ в Интернет, правительству пришлось вмешаться и одолжить компьютеры студентам с низкими доходами.

Дистанционное медицинское обслуживание

За десять лет до начала пандемии Дэвис Мусингузи выдвинул свою грандиозную идею: создать систему, которая позволила бы людям в Уганде набирать бесплатный номер телефона и просить врача перезвонить им для консультации. Многим эта идея казалась дерзкой. Но Мусингузи, в то время студент-медик, был убежден, что это сработает.

Он стал соучредителем Медицинской консьерж-группы в 2012 году, что, как он сейчас признает, было слишком рано. В то время менее половины жителей Уганды владели мобильными телефонами. С годами возможности расширились, включив видео-звонки и сообщения, а также автопарк медицинского персонала, ездящего на мотоциклах, который посещал дома пациентов для проведения анализов крови и доставки лекарств. Группа также распространилась на Кению и Нигерию.

Как вы могли догадаться, с началом пандемии число пользователей увеличилось в 10 раз. Дистанционное медицинское обслуживание это превосходно, аCOVID-19 только усилил внимание к развитию подобных технологий и проблеме их нехватки в отдаленный регионах мира. В Африке проживает около 10% мирового населения и сконцентрированы 25% мировых болезней, однако есть только около 3% мировых докторов, которые трудятся на благо общественности.

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

8. Multi Skilled AI

Актуальность:ИИ, способный чувствовать и говорить, будет гораздо лучше справляться с новыми вызовами и работать вместе с людьми.

Лидеры рынка:

• OpenAI

• AI2

• Facebook

Доступность:Сейчас

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

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

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

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

В прошлом году в этой области было достигнуто несколько впечатляющих результатов. В сентябре исследователи из Allen Institute for Artificial Intelligence, AI2, создали модель, которая может генерировать изображение из текстовой подписи, демонстрируя способность алгоритма ассоциировать слова с визуальной информацией. В ноябре исследователи из Университета Северной Каролины в Чапел-Хилле разработали метод, который включает изображения в существующие языковые модели, что повысило их понимание при чтении.

Более сложные многомодульные системы сделают возможным создание более продвинутых роботов-помощников (подумайте о роботах-дворецких, а не только об Alexa отAmazonили Алисе из Яндекса). Нынешнее поколение роботов с искусственным интеллектом в основном использует визуальные данные для навигации и взаимодействия с окружающей средой. Это хорошо для выполнения простых задач в стесненных условиях, например, работа на складе. Но лаборатории, такие как AI2, работают над тем, чтобы добавить язык и включить больше сенсорных входов, таких как звуковые и тактильные данные, чтобы машины могли понимать команды и выполнять более сложные операции: открытие двери, когда кто-то стучит.

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

9. TikTok Recommendation Algorithms

Актуальность:Прославиться в интернете может кто угодно

Лидеры рынка:

• TikTok

Доступность:Сейчас

С тех пор как TikTok был запущен в Китае в 2016 году, он стал одной из самых привлекательных и быстрорастущих социальных медиа-платформ в мире. Он был скачан более 2,6 миллиарда раз по всему миру и имеет 100 миллионов пользователей в США. И уникальный способ, которым он находит и обслуживает контент, является большой частью его привлекательности.

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

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

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

10. Green Hydrogen

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

Лидеры рынка:

• ThyssenKrupp

• Get H2 Nukleus Nowega

• Nel Hydrogen

• Siemens

Доступность:Сейчас

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

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

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

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

Водородные долины региональные проекты, которые размещают электролизные установки там, где они могут служить различным промышленным целям формируются по всей Европе. Недалеко от Гамбурга, на севере Германии,ThyssenKruppявляется частью консорциума зеленого водорода стоимостью 89 миллионов евро. Планируемый проект включает в себя нефтеперерабатывающий завод, цементный завод, электростанции и морскую ветроэлектростанцию. Первоначально его зеленый водород заменит некоторый серый водород. Затем немецкая группа планирует провести реакцию водорода с углекислым газом, захваченным с цементного завода, для получения как метанола, химического сырья, так и синтетического реактивного топлива.

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

Другие крупные проекты начинаются в Нидерландах, Италии, Испании, Франции, Великобритании, Канаде, Австралии, Японии и Китае. Первоначально водород, который производят эти проекты, будет дорогим. Однако, по оценкам консалтинговой компанииMcKinsey, к 2030 году зеленый водород будет таким же дешевым, как и серый водород, благодаря удешевлению электролиза и возобновляемой генерации электроэнергии, а также росту затрат на углерод.

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

Привет, Хабр. В прошлой статье я рассказал о начальном анализе предметной области и базовом проектировании нашей новой ECM-системы. Теперь я расскажу о первой практической задаче, которую мы решили. А именно - о выборе способа организации структуры хранилища бизнес-атрибутов объектов.

Напомню, что в результате анализа мы пришли к следующей структуре объекта:

Системные и интеграционные поля содержат техническую информацию и редко подвержены модификациям. А вот бизнес-поля - искомые атрибуты объектов - могут и будут различаться для разных типов документов, которых у нас на входе предполагается около 1000. Проанализировав возможность повторного использования полей, мы пришли к выводу, что у разных типов документов может быть не более 15% общих свойств. И при этом всё равно придется скрепя сердце согласиться на неполное соответствие названия и содержания.

Таким образом, есть большое количество сущностей с разнообразным атрибутивным составом, который нужно хранить, тратя как можно меньше ресурсов, и расширять который хотелось бы также с минимальными усилиями.

Какие есть варианты?

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

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

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

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

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

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

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

А что у нас?

Второй вариант - это использование специализированных документоориентированных (или документных, как больше нравится) баз данных, реализующих NoSQL-подход к хранению и обработкенеструктурированной или слабоструктурированной информации. Наиболее часто данные хранятся в виде JSON объектов, но с предоставлением производителями СУБД инструментария для доступа к данным внутри этих структур.

У такого подхода, применительно к проектируемой системе, можно выделить несколько плюсов:

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

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

• проще описывать объекты в коде - иногда можно вообще не описывать структуру документа в коде, а работать прямо с полями в JSON.

Но есть и минусы:

• невозможно нативно реализовать проверки данных при размещении в хранилище.

• валидацию данных придется проводить в коде.

• невозможно организовать внутреннюю связность подчиненных данных, например, справочников.

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

Чтобы продемонстрировать применимость такого подхода, мы решили сравнить, насколько оба варианта будут отличаться друг от друга по производительности, расширяемости и объемам хранилища.

Делаем прототип

Возьмем гипотезу, что NoSQL-подход для нашей системы применим как минимум не хуже, чем классический. Для ее проверки создадим прототип, в рамках которого реализуем оба подхода. В качестве СУБД возьмем Postgre, который уже давно умеет хорошо работать с JSON полями.

Создадим следующие таблицы:

Для описания объектов в табличном виде:

• r_objects, базовые данные по объектам: тип, дата создания и ссылка на хранилище атрибутов.

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

Для описания объектов в виде JSON:

• objects. Данные по объектам, где в поле data формата jsonb хранятся искомые атрибуты.

Остальные таблицы - это различные вспомогательные хранилища.

Реализуем в коде 5 разных типов объектов, для каждого из них описав программную структуру, механизм извлечения данных из хранилища и наполнения этими данными самих объектов.

Методика тестирования

Для тестирования обоих подходов хранения данных используем следующие методы:

• добавление данных по объекту. Критерий успешности: объект с данными появился в хранилище, метод вернул в ответе его идентификатор.

• обновление данных по объекту. Критерий успешности: данные в хранилище были изменены, метод вернул отметку об успехе. Удаление данных в системе не предусматривается, поэтому удаление объекта является операцией, аналогичной обновлению.

• извлечение данных по объекту. Критерий успешности: объект с данными возвращен в ответе на запрос. Извлечение объекта происходит по конкретному идентификатору, по критериям поиска и постранично (пагинация).

Генерация запросов будет происходить в 20 параллельных потоков по 50 запросов в каждом потоке. Для того, чтобы тестирование было действительно показательным с точки зрения производительности, предварительно наполним базу 200 млн. объектов.

Тестирование показало следующие результаты:

Первая (высокая) часть графика - это получение объектов по случайной странице - пагинация. Здесь в обоих случаях пришлось применить небольшой трюк - так как Postgres не агрегирует точное число строк в таблице, то узнать, сколько всего записей на объеме данных теста простым count - это долго, и для получения количества записей пришлось брать статистику данных по таблице. Также время получения данных на страницах свыше 10000-й неприлично велико, поэтому верхняя планка для получения случайного номера страницы была установлена в 10000. Учитывая специфику нашей системы, получение пагинированных данных не будет частой операцией, и поэтому такое извлечение данных применяется исключительно в целях тестирования.

Вторая (средняя) часть графика - вставка или обновление данных.

Третья (низкая) часть графика - получение данных по случайному идентификатору.

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

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

Результаты тестов на 40000 запросов приведу в виде таблицы:

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

Что получилось?

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

Немного истории

С 2013 года, в обиходе аббревиатура UI (точное обозначение User Interface), а в 2015 году добавилась новая UX (точное обозначение User experience).

Под UI понимается дизайн интерфейса, а под UX аналитика, ключевой опыт и удобство в пользовательских интерфейсах.

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

И всё ж, UI и UX, это не только интерфейсы и дизайн в диджитал.

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

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

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

Даже самый большой штат аналитиков не обеспечит идеальный пользовательский опыт.

Почему на смену UI/UX придет UXD

Мы подошли к новой аббревиатуре UXD (User Experience Design). UXD объединяет в себе работу UI и UX и формирует новый подход к проектированию пользовательского взаимодействия.

Пойдем по порядку:

Любая идея UXD продукта создается прежде всего для человека-пользователя, для которого мы работаем. Мы изучаем его предпочтения и привычки, вне зависимости от того, какой предмет создаем. Затем к работе приступают аналитики, которые создают прототип решения, и на следующем этапе подключаются дизайнеры.

Мы в Экосистеме РСХБ, словно скульпторы: придумываем, делаем каркас и украшаем все, соединяя воедино, чтобы получился тот продукт, которым будут пользоваться вечно. Мы стараемся максимально минимизировать негативный фидбэк от конечного потребителя. Делаем это всегда до реализации и запуска продукта.

Что ждет нас в будущем? Или к чему мы идем?

Еще одна новая аббревиатура UXZ, где Z от слова zero (ноль). Эта аббревиатура хорошо подходит под описание развития интерфейсов в VR и AR, где нет мышки, клавиатуры и нет плоского монитора нет ничего, чем мы привыкли пользоваться. Набор кнопок и инструментов в UXZ должен быть минимальным, грубо говоря, ничего лишнего. Это своего рода минимализм в области дизайна и прототипирования. К этому идеалу сейчас стремятся, сознательно или нет, все интерфейсы и все предметы вокруг нас. Это будущее, к которому идут все дизайн-решения, и мы в Экосистеме РСХБ держим руку на пульсе.

Практический пример наших кейсов с использование подхода UXD

Свое | Фермерство (https://svoefermerstvo.ru/) инновационная платформа, которая предоставляет доступ фермам и малым предприятиям к целому ряду сервисов и ресурсов, необходимых для ведения сельскохозяйственного бизнеса. Главное преимущество для аграриев состоит в том, что экосистема включает именно те цифровые решения, которые без дополнительных затрат позволят им автоматизировать многие процессы, сэкономить время, ресурсы и вывести свой бизнес на новый уровень. Все управляют предприятиями, банками, но мало кто помогает фермерам с внедрением готовых технологических решений.

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

Когда перед компанией встаёт вопрос набора дополнительных кадров, она, как правило, сталкивается с дилеммой: нанимать достаточно дорогих специалистов в Москве или поискать в регионах подешевле.

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

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

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

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

Готовим аэродром

Первое, о чём начинают задумываться при открытии регионального центра, А где, собственно?.

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

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

В первый раз, когда мы столкнулись с проблемой выбора места для регионального центра разработки, нам повезло: нам дали на выбор аж три города Хабаровск, Уфа и Владимир. Местные филиалы РСХБ были готовы разместить наших сотрудников, избавляя нас от многих хозяйственных проблем. Справедливо полагая, что Хабаровск слишком далеко и в него не налетаешься, да и разница во времени не позволит работать единой командой, а Владимир, наоборот, настолько близок, что большинство грамотных специалистов наверняка уже переехали в Москву, мы выбрали золотую середину. Как впоследствии показало время середина и в самом деле была золотой. Этот центр не просто взлетел сейчас он самый крупный из наших самолётиков: если в начале в нём было всего три сотрудника, сейчас их более 300.

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

Что же с офисами?

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

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

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

Самолёт не взлетит без Капитана

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

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

Как выявить лидера? Обычно его видно сразу и не только по деятельности на местах, опыту или скилам. В нашей практике часто бывало так, что это не мы искали лидеров, а они сами нас находили. Собирали часть команды и предлагали создать на её основе новый самолётик. Именно так появились некоторые наши региональные центры. Конечно, в этом практически идеальном варианте есть и минус насколько легко капитан привёл команду, настолько же легко он сможет её увести, если что-то вдруг пойдёт не так. Но нам пока везло: потерь среди наших лидеров ещё не случалось, мы стараемся работать так, чтобы люди оставались с нами. Хотя бывали и непредвиденные ситуации.

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

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

Полёт нормальный?

Самолётик полетел а дальше что? Лидер лидером, но присмотр хорошего диспетчера и технических служб тоже важны.

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

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

Процесс работы с центрами непрерывен. И дело не только в наборе новых кадров, но и в развитии уже имеющихся. Рост сотрудника важная задача как для самих центров, так и для нас, потому что в выигрыше в итоге окажутся все. Чтобы помочь им в этом, мы постоянно обучаем людей, причём не только в регионах, но и, бывает, даже приглашаем сотрудников на обучение в Москву.

Что ещё нужно самолётикам для успешного полёта (ну и чтобы не свалиться в пике по ошибке)? Толковое управление. Когда команд так много и задач они решают ещё больше, важно понимать, кто чем занят, насколько загружен, с кем сейчас взаимодействует. В нашей практике бывает, что над одной задачей работают люди не только из разных команд, но и из разных городов. Так что в нашем случае Agile и ещё раз Agile.

Зачем это всё, или Человек существо социальное

А почему именно офисы? Не лучше ли нанимать сотрудников удалённо и не тратить ресурсы на аренду помещений? Сейчас, когда ковид заставил большинство айтишников поработать на удалёнке, я всё чаще слышу мнения, что региональные центры как структуры и не нужны вовсе.

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

Я не призываю совсем вернуть сотрудников в офисы. Удалёнка как опция должна обязательно оставаться, и у нас самих такие сотрудники были ещё задолго до пандемии ковида, и мы их успешно включали в процессы разработки. Это действительно удобно, и карантин научил нас работать вполне продуктивно вдали друг от друга. Но, несмотря на это, от очень многих коллег я слышал, как сильно им хочется назад в офис.

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

В качестве послесловия

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

Мы снова начнём запускать самолётики.

Проблемы аграриев взялись решать биотехнологи

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

Существенную долю рынка мировых биотехнологий, - 51 %, составляют сельское хозяйство, пищевая промышленность и химпром. По прогнозам экспертов, до 2028 года рост рынка биотехнологий в год составит в среднем 15 %.

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

Альтернативный источник кормового белка

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

Проблему нехватки мясных белков и морепродуктов сможет решить белок альтернативного происхождения, ведь для его производства не используется мясо птицы и млекопитающих. Белок этого типа как альтернативный источник кормового белка будет востребован в пищевой промышленности в качестве корма для домашних животных и для нужд человека. По оценкам Продовольственной и сельскохозяйственной организации ООН (ФАО), производство продовольствия должно увеличиться на 70%.

Так, компания Entoprotech делает энтомологический белок из мухи Черной львинки (Black Soldier Fly). Содержащее до 63% белка насекомое служит идеальным кормом для аквакультуры, домашних животных и птицы.

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

Биопластик - польза сразу для двух отраслей сельского хозяйства

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

Биопластик был получен при переработке семян сортов рыжика (лат. Camelina, травянистое растение семейства Капустные), генетически сконструированных для производства. Стоит отметить, что пластик полностью биоразлагаемый, что значительно повышает привлекательность его сельскохозяйственного производства для широкого спектра промышленных и потребительских товаров. Выращенный на фермах биопластик планируют использовать для очистки сточных вод от нитратного загрязнения, а также в качестве ингредиента корма для скота и возобновляемого топлива. Таким образом, он принесёт огромную пользу сразу двум отраслям сельского хозяйства.

Ежегодно во всем мире производится около 380 миллионов тонн пластика, и 50% общего объема производства идет на одноразовые цели. Согласно большинству оценок, синтетический пластик требует 400-450 лет для полного разложения. Разработка американских ученых особенно актуальна в эпоху переизбытка синтетического пластика, превратившегося в экологическую проблему глобального масштаба.

Переработка органических отходов

Ежегодно образуется 1,6 млрд тонн органических отходов. Около 95% из них оказывается на полигонах или сжигается. Вырабатываемый на свалках газ - опасная смесь метана, сероводорода и углекислого газа, оказывающая негативное влияние на окружающую среду.

Энтомофаги - биологическая защита растений

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

Кроссплатформенный фреймворк дает самый привлекательный опыт для веб-разработки.

Современные Web-сайты пишутся на HTML, JavaScript и CSS (и этот сайт в том числе). Наверно, вы сейчас прочитали это и подумали да это же очевидно. А если я вам скажу, что можно написать сайт без использования этих трех технологий, у вас наверняка возникнут вопросы

На протяжении истории на этом поле побывали разные игроки. Был Flash, был Silverlight - конкурирующие технологии, которые пытались отобрать кусок рынка у браузеров и не дать разработчику использовать другие технологии для создания сайта. Правда ни одна из них по-настоящему так и не взлетела. А что, если я вам скажу, что в этой сфере снова может появиться конкурент? И это несмотря на то, что буквально никто из других игроков так и не смог сдвинуться с места, невзирая на годы усилий.

Но давайте сначала отвлечемся чтобы понять, что общего было у всех этих попыток:

1. Для запуска нужен был плагин браузера. Обычно нужен был плагин браузера для запуска на соответствующей платформе. Хороший пример Silverlight. В то время те, кто использовал Linux, не могли смотреть Netflix, так как сайту нужен был плагин Silverlight (который не был доступен для Linux). Конечно, были альтернативные, open source варианты, но среди них не было ничего стоящего.

2. Они представляли угрозу для системы безопасности. Flash был печально известен этим (более 1000 известных уязвимостей). Браузер обязательно должен был загрузить плагин для отображения содержимого, и в этот самый момент ни одна из гарантий безопасности браузера уже не имела значения, так как плагин имел полный доступ к хосту.

3. Производительность была не так хороша, как у чистового HTML. Зачем грузить плагин, чтобы отобразить в нем некоторый текст, если можно использовать чистый HTML и CSS, которые гораздо быстрее?

4. Появился HTML5, и CSS стал лучше. Внезапно создание чего-то прекрасного и захватывающего перестало быть невозможным. И, что еще лучше, браузеры, которые ненавидели стандарты, использовали странные хаки или специфичные для конкретного браузера реализации, вместо их CSS-эквивалентов (как например, Internet Explorer) были попросту уничтожены.

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

Но как мы пришли к этому? Как HTML стал основой веб-разработки в сегодняшнем процветающем веб-пространстве?

Рассвет новой эры

6 августа 1991 годаИнтернет стал доступен всему миру. Затем, пришел и ушел так называемый пузырь доткомов,Представьте себе, что Интернет для общего пользования появился только в 1991 году, а девять лет спустя лопнул пузырь доткомов, стоивший1,7 триллиона долларов (это примерно 15% ВВП США на тот момент)!

Это было время, когда веб начинал становиться все более и более организованным, и способ, которым мы писали веб-сайты, становился все более стандартизированным.Со временем мы выработали стандарты, такие как HTML4, и эти стандарты гарантировали, что HTML, который вы пишете в одной части мира, будет работать для большинства, если не для всех, интерпретаторов HTML.Каскадные таблицы стилей (CSS) вошли в обращение в 1996 году, а годом ранее появился JavaScript.Можете ли вы представить себе, что видите или используете веб-сайт без JavaScript или CSS? Боюсь это произвело бы на вас не лучшее впечатление.

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

Документ

Когда Интернет только появился на свет, люди не использовали приложения, как это делают сегодня. Кто-то из вас, возможно, помнит программы-терминалы, которые, обеспечивали вам физическое соединение с сервером на другом конце. Эти приложения (если их можно так назвать) были лишь немного больше, чем просто строчками текста на экране (прим. переводчика: автор тут видимо имеет ввиду BBS доски и их аналоги). А так как люди привыкли иметь дело с документами, с реальными кусками бумаги в руках, которые они могут листать - неудивительно, что основой HTML-страниц является работа с HTML-документом. Если вы когда-либо использовали JavaScript, вы конечно знакомы с такими функциями, как document.getElementById(). Все, что вы делаете на веб-странице, заключается в создании, а затем преобразовании документа.

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

Если же вы хотите, чтобы определенные части вашей веб-страницы оставались в нужном положении или выравнивались определенным образом, вы используете вещи типа position в CSS, чтобы контролировать расположение элементов. Существует множество свойств CSS (520, если точнее), и, как следует из названия, эти стили каскадируются в свои дочерние элементы. Когда вы попытаетесь заставить определенную часть вашего документа выглядеть так как вам нужно, высока вероятность того, что они станут довольно хаотичными. Если вы используете готовый CSS фреймворк, например, Angular Material, и начинаете переопределять встроенный CSS для достижения нужного вам внешнего вида, это тоже становится довольно пикантным занятием. CSS позволяет вам выполнить переопределение при помощи !override, однако, как только вы начнете это делать, вы уже практически проиграли битву. Если вы читаете это и думаете про себя: Что? Да этот парень совершенно безнадежен в CSS: ОК, я не буду с вами спорить. Но как только ваши дизайнеры начиняют гнаться за определенным внешним видом, ваш CSS может стать довольно сложным в понимании.

Изучение языков

Чтобы создать простой веб-сайт, вам необходимы три разных языка, и это только для самого сайта. Это HTML, JavaScript и CSS. А так как ваш сайт должен быть удобным и отлично выглядеть, этого не произойдет, если вы не знаете, как писать эффективный JavaScript или если ваши навыки в CSS оставляют желать лучшего.

Если вы действительно хотите, чтобы ваш сайт мог делать что угодно, вы можете использовать фреймворк типа Angular или React. Когда вы начнете добавлять пакеты через npm, размер вашего приложения начнет расти. Поэтому вы будете использовать сборщик, такой как webpack, чтобы связать все ваши пакеты вместе и соответствующим образом их минимизировать. Webpack сам по себе отдельная тема (при том огромная), но ее тоже стоит рассматривать, т.к. она играет свою не маловажную роль в создании веб-приложений.

Бандлинг и транспиляция

У вас есть веб-сайт и ваши пакеты, теперь вам нужно использовать bundler для объединения вашего приложения, а затем еще убедиться, что оно работает в нужных браузерах. В зависимости от того, какой браузер использует пользователь, вам потребуется прокладка для определенных функций, чтобы браузер пользователя мог отображать ваш сайт. Если вы используете такой язык, как TypeScript, webpack также преобразует его в JavaScript. В этом нет ничего плохого, но это все еще больше усложняет. Если ваш сайт ломается, возможно это вы накосячили в коде, минификация сломала его, webpack не собрал все должным образом или процесс транспиляции привел к проблеме? Все эти сложные конвейеры могут создать трудности при отладке или поиске основной причины проблем в вашем приложении.

Чем лучше Flutter?

Если вы слышали о Flutter, то, скорее всего, слышали о нем в контексте разработки мобильных приложений. Так какое отношение он имеет к веб-сайтам? С обычной HTML-страницей вы работаете как с документом. Во Flutter страница (или то, с чем взаимодействует пользователь) фактически рисуется на канве (canvas) HTML. Flutter фактически контролирует каждый пиксель, который рисуется на экране, и не использует HTML, JavaScript или CSS для определения его внешнего вида или логики. (Технически говоря, родной код Dart переносится на JavaScript через dart2js, но на самом деле никакая бизнес-логика не пишется на JavaScript.)

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

Рисование на канве вместо работы с документом

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

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

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

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

Использование одного языка

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

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

Простая компоновка вашего приложения

Обычно мы используем наши веб-сайты для отображения данных из какого-то источника: база данных, API или что-то еще, от куда мы получаем данные, которые хотели бы отобразить. Представьте, что у нас есть массив объектов, которые возвращаются из нашего API, и вы используете, например, Angular для их отображения. Вы загружаете эти объекты во вспомогательный компонент, затем используете *ngFor для их итерации и вы скорее всего положите его в div. Но из коробки, для нестилизованного div, это будет выглядеть совсем просто. Вероятно, вы хотите, чтобы ваши элементы в этом списке отображались в столбце или строке, поэтому вам еще придется задействовать некоторые CSS или flexbox для этого.

С Flutter наоборот, вы размещаете дочерние элементы с помощью Column или Row, которые имеют свойство children, которое принимает массив объектов. При использовании этого свойства, вы можете записать ваши массивы в строку (элементы друг за другом) или в столбец (элементы друг под другом). С Flutter, вы можете быстрее получить визуальный макет, который вы хотите, прежде чем перейти к стилизации отдельных элементов в списке. По моему опыту это приводит к более быстрому скаффолдингу и прототипированию сайта без ущерба для конечного результата.

Контроль над каждым пикселем в области просмотра

Поскольку Flutter визуализирует каждый пиксель на экране, это дает дизайнерам и разработчикам большой контроль над тем, что именно они хотят видеть в приложении. Но рендеринг каждого пикселя на экране звучит как нечто, что будет сопровождаться большим ударом по производительности, и да, в наши дни это, конечно, не так быстро, как рендеринг чистого HTML, но такие вещи, как канва с аппаратным (за счет GPU) ускорением, значительно повышают производительность в этой области. Традиционно проектируя веб-страницу в HTML, нужно учитывать различные браузеры, на которые вы ориентируетесь. Однако в случае с Flutter, если вы размещаете виджет Text с определенным шрифтом, он будет выглядеть одинаково, независимо от того, где он отображается, потому что Flutter контролирует, как этот конкретный виджет будет выглядеть на основе каждого пикселя.

Прощай, webpack!

Flutter использует Dart, поэтому приложение компилируется для своей целевой платформы, оно также переносит все зависимые пакеты (также написанные на Dart) в JavaScript. Dart типобезопасный язык, который не поддерживает рефлексию, поэтому компилятор лучше понимает, что ваше приложение вызывает, а что нет. Это способствует лучшему tree-shaking (избавление от неиспользованного кода) и минификации вашего приложения. Flutter не нужен webpack для сборки приложения, что само по себе является довольно сильным аргументом в пользу Flutter (по крайней мере, на мой взгляд). В webpack нет ничего плохого; это высококачественный софт. Но это сложный инструмент и без того в сложном конвейере.

. . .

Но пока это все лишь теория

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

Рисование всего на канве также имеет свои последствия для производительности, но они не так плохи, как вы предполагаете. Я сделал тестовое приложение, которое интенсивно использует визуальные эффекты, и оно работает на моем MacBook со скоростью около 60 кадров в секунду. Даже когда вы тащите лист по экрану, оно все равно работает нормально, постепенно увеличивая размытие на изображении позади. Я ни в коем случае не специалист в Dart, так что, без сомнения, этот процесс можно было бы оптимизировать еще больше.

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

Представьте, если бы вы могли сделать веб-сайт, который работает быстро, и вы бы могли использовать один язык для разработки, стилей и написания бизнес-логики для вашего веб-приложения? Если бы webpack стал не нужен для вашего конвейера разработки? А если бы со временем у вас был серверный рендеринг и все те SEO-блага, которые есть сегодня у традиционных HTML-сайтов?

Если бы Flutter уже обладал всем этим, он мог бы стать непобедимым в вебе.

От переводчика:

Совсем недавно (03.03.2021) Flutter web перешёл в stable ветку! В своем первом релизе Google в первую очередь сосредоточился на вопросах производительности и улучшении точности рендеринга. Более подробно о нововведениях и изменениях можно почитать тут

P.S. Догадываюсь, что эта статья может вызвать много споров и критики, особенно у web разработчиков. Действительно есть много подходов и готовых библиотек для решения описанных выше сложностей. Но я не могу не разделить с автором всех плюсов, которые потенциально дает Flutter, да и впечатляющая скорость, с которой он развивается и завоевывает рынок мобильной разработки тоже вселяет определенную уверенность в успехе его Web составляющей.

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

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

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

Начало работы: концепт

Разработку нового процесса мы запустили ещё в начале пандемии. Наш департамент информационных технологий предложил решение на базе механизма, которым уже пользуются 90 % юридических лиц и индивидуальных предпринимателей, юридически значимый электронный документооборот на базе операторов ЭДО. Это тот самый документооборот и те самые операторы, через которых большая часть организаций и предприятий направляет в ФНС отчётность и взаимодействует с энергосбытовыми компаниями по хозяйственным операциям. Это работает так: при подключении к оператору ЮЗД юридическое лицо или индивидуальный предприниматель получает усиленную квалифицированную электронную подпись (УКЭП) и по ней удостоверяющий центр идентифицирует представителя компании. После этого для банка отправитель документов становится связан с компанией, которую он представляет. Операторы ЭДО связаны роумингом, что позволяет получать заявки и документы от всех абонентов ЮЗД.

Реализация и подводные камни

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

Этап 1. Создание процессов, нормативных документов, закупка лицензий и работ

В первую очередь нам пришлось пересмотреть всю нормативную документацию по дистанционной работе с ЮЗД.

Для взаимодействия с ФНС и другими контрагентами мы уже использовали ряд технических решений ЮЗД, представленных на рынке. Но процессы, использующие ЮЗД, не были централизованными и каждый региональный филиал банка проводил локальные конкурсы на закупку этих решений.

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

• согласовали новый бизнес-процесс;

• подключили работников банка к системе электронного документооборота;

• организовали удалённые рабочие места и настроили доступы к личным кабинетам;

• настроили и запустили бизнес-процесс согласно требованиям банка.

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

Этап 2. Подписание кредитного договора

Со сложностями мы столкнулись на втором этапе, когда организовывали возможность подписания кредитного договора. Процесс выглядит просто: получить договор, загрузить в ИС ЮЗДО, подписать УКЭП со стороны банка и со стороны клиента, направить на регистрацию в Росреестр (для договоров ипотеки) и положить в архив. Но на деле за каждым шагом есть своё но.

Получить договор

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

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

Эти 10 лет для электронного документа значат многое. Из-за развития технологий спустя столько лет могут возникнуть проблемы с открытием файла и проверкой подписей. Даже шрифты в файле договора могут устареть и исчезнуть из операционных систем.

Чтобы исключить проблемы с чтением файлов в будущем, мы предприняли ряд мер. В оформлении документов мы используем только стандартные шрифты, которые применяются уже давно, и нет предпосылок к тому, чтобы они вышли из оборота. Сами договоры хранятся в формате pdf с зашитыми в них нужными шрифтами. Электронная подпись в архиве банка хранится вместе с договором, а не отдельно. Наконец, в банке будут сохранены те версии ПО, которые в настоящее время успешно открывают документы и в будущем смогут работать с устаревшими файлами.

Подписать УКЭП

У РСХБ 62 филиала и более 2 000 сотрудников, участвующих в процессах. Каждый из них должен получить доступ к системе, обучиться и получить УКЭП. В масштабах одного человека это несложная задача, но, когда нужно провести работу со всем штатом, её решение становится очень трудоёмким.

И действительно, это заняло немало времени. Наибольшие сложности возникли с составлением списков сотрудников, уполномоченных работать с УКЭП и документами. Необходимо было собрать фамилии, адреса e-mail, отсеять уволившихся и т. д. Но, когда это было сделано, мы смогли внести их данные и обеспечить доступ не вручную, по одному, а централизованно, всем списком.

Положить в архив

Во-первых, раньше в банке не хранили оригиналы кредитных договоров, подписанные только в электронном виде. Снова может показаться, что проблема не такая и сложная: достаточно воспользоваться инфраструктурой операторов ЮЗД. Но по действующему законодательству оператор ЭДО должен гарантированно хранить только первичку и только в течение 5 лет. Конечно, оператор подтверждает, что он будет хранить и дольше, но либо это влечёт дополнительные непрофильные затраты для оператора, которые он перекладывает на банк, либо документы при оптимизации могут быть удалены. Банк такие условия не устраивают, потому что файл и подписи к нему это единственный подтверждающий сделку документ. А сделки бывают разные и по объёмам, и по длительности.

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

Во-вторых, для хранения подобных документов нужно надёжное электронное хранилище. В РСХБ с 2017 года внедрена и успешно функционирует АСОА автоматизированная система управления хранением документов на бумажном носителе и хранения электронных образов документов. В ней хранятся скан-образы документов клиентов, копии договоров и иные документы по сделкам с клиентами. Но новый процесс требует хранения в системе оригиналов договоров. Поэтому, когда оригинал останется только во внутренней системе банка, потери должны быть исключены. Нужно было вывести всю систему хранения или её часть, в которой размещаются документы, на запредельный уровень SLA.

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

В-третьих, каждая копия кредитного договора, подписанного в электронном виде, эквивалентна оригиналу. Доступ к копии договора и подписи равносилен тому, как если бы злоумышленник получил доступ к его оригиналу. Кредитный договор, подписанный в электронном виде, не должен быть доступен никому, кроме ограниченного круга пользователей. В рамках существующих процессов сотрудникам банка нужно работать с копиями кредитных договоров. И важно, чтобы на копии (печатной форме) были понятные для человека штампы с информацией из УКЭП и датами подписания. Чтобы всё это обеспечить, нужен высоконагруженный сервис, который проверяет соответствие документа подписям, валидность УКЭП на дату подписания и генерирует печатную форму.

На выходе пришлось решать сразу две проблемы. Первая касалась ограничения доступа. Силами IT и Департамента безопасности банка была разработана и внедрена матрица доступов и ограничений доступов к информации и её пересылке. Доступ к оригиналу КОД получили только определённые сотрудники подразделений, которым это необходимо для работы. Остальные же сотрудники могут только загружать договоры в периметр банка (в архив), после чего они утрачивают доступ к этим документам, как и возможность куда-либо пересылать их со своих компьютеров или извлечь на любых носителях. Всё это решается настройкой ролей.

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

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

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

Такой документ сотрудники банка смогут использовать в необходимых им бизнес-процессах. Помимо этого, сервис, возможно, позволит и заёмщику, ставшему клиентом банка, получать по запросу печатную форму документов, которыми он обменялся с банком через ЮЗДО. Сделать это можно будет по каналам дистанционного банковского обслуживания в личном кабинете клиента.

Результаты работы

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

• обеспечить бесперебойность кредитного процесса даже в условиях новых пандемий (но мы очень надеемся, что их больше не будет);

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

• гарантировать юридическую силу документов и правомочность операций;

• наладить простой и прозрачный диалог с надзорными организациями и госслужбами;

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

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

• снизить число ошибок и погрешностей при работе с бумагами.

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

Что мы будем делать дальше

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

Сейчас перед ДИТ стоят более понятные, но не менее важные задачи:

• обеспечить безотказность процесса;

• доработать используемые банком системы и интеграции между ними;

• реализовать новые механизмы по интеллектуальной автоматической обработке, распознаванию и верификации поступающих в банк документов, чтобы снизить нагрузку на операционистов и повысить скорость обработки документов;

• обеспечить работу с использованием ЮЗД и объединить процессы банка, клиента и контрагента в мире электронных документов;

• реализовать то, что ещё не придумано, ведь эта область пока только развивается.

Обратная связь

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

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

Удивительно, но в век самоуправляемых машин, 5G и спутникового интернета многие до сих пор думают, что еда для масс-маркета производится примерно теми же методами, что и 3040 лет назад. Есть трактор, комбайн, борона, и на этом прогресс остановился. Но современная ферма может быть оборудована хай-тек-устройствами не хуже заводского цеха. Давайте разбираться, как современные фермы работают сегодня.

Позабыты хлопоты, остановлен бег, вкалывают роботы, а не человек.

Роботы на ферме

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

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

Зачем нужен агротех

Спрос на продукты питания за всю историю человечества только рос. Ещё Томас Мальтус в 18-м веке сформулировал свой закон: население растёт экспоненциально, а ресурсы только линейно. И хотя оптимисты настаивают, что он был неправ и рост производительности труда решает проблему, тренд ясен: спрос на продукты растёт.

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

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

Naio Technologies

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

Французская Naio Technologies выступает за экологичное земледелие: зачем поливать грядку тонной химии и лишний раз загрязнять почву (а ещё создавать устойчивые к гербицидам и пестицидам виды сорняков и вредителей), когда можно эффективно решить проблему механическим способом. Около 150 умных роботов Oz, Dino и Ted от Naio уже впахивают на французских и американских землях, а сам стартап привлёк более 14 млн инвестиций на создание фабрики по производству таких машин, так как первые экземпляры (на которые уже было собрано 3 млн) были изготовлены чуть ли не вручную.

Планы у компании наполеоновские: в течение 10 лет они собираются поставить роботов на каждое поле в США и Европы, говорят, что по эффективности их продукт просто не оставит шансов альтернативным технологиям. То есть либо у тебя ферма с роботами-пропольщиками, либо ты не вписался в рынок и твои конкуренты производят еду дешевле и качественнее. Причём вынудит фермеров обновляться не только растущий спрос, но и давление госрегуляторов, стремящихся уменьшить применение химикатов на полях.

BlueRiver

По сути, Lettuce Bot решает ту же проблему, что и предыдущий стартап, но чуть иным методом. Компания решила не отказываться от гербицидов в полной мере, просто применять их точечно, а не заливать всё поле без разбора. Робот ездит по полям, оценивает растущую на них зелень и прицельно опрыскивает специальным раствором только сорняки.

В результате те не мешают росту салата, а на сам салат не попадает всякая химия. Стартап не такой молодой, поэтому и подход к решению проблемы был попроще, и результат соответствующий: известный (в том числе и кабальным DRM) производитель сельхозтехники John Deere купил стартап за $300+ млн.

Животноводство и роботы от Lely

В одной только России уже больше 130 молочных ферм используют робототехнику. Для чего? Задачи у ботов самые разные. Чаще всего в контексте такой автомазиации вспоминают продукцию голландской фирмы Lely (неудивительно, что стартап именно из этой страны много лет считается лидером в молочной отрасли).

У компании есть бот Juno, чем-то напоминающий гигантский робот-пылесос весом в добрых полтонны. Он ездит по помещению сам, старается ни во что жёсткое не врезаться, только вместо уборки подравнивает насыпанный на пол свежий корм, чтобы коровам не пришлось далеко за ним тянуться. Работает 24/7, не просит отпусков и не требует медицинской страховки. Сплошные плюсы.

Другой бот, Lely Discovery 90, занимается чисткой коровника. Собирает и вывозит навоз, моет дощатый пол, дезинфицирует труднодоступные места. Фермеры, внедрившие робоуборщика, отмечают улучшение здоровья подопечных коров: отсутствие кислотной среды и жидкостей на полу предотвращает болезни копыт и различные дерматиты. Сами же парнокопытные быстро привыкают к механическому товарищу и спустя какое-то время воспринимают его как неотъемлемую часть их дома: спокойно отходят с маршрута робота и не мешают ему убираться.

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

Саму Lely нельзя назвать стартапом компания основана в 1997 году и не только занимается производством техники, но и успешно инвестирует в молодые предприятия, создающие инновационные системы для фермерских хозяйств.

Hans-Christian Fritsch, управляющий компании-партнёра Ilmsens, отмечает, что в современном мире стартапам всё сложнее довести прототип изобретения до серийного продукта. Иногда идея успевает устареть, иногда крупный бизнес ведёт себя нечестно и ворует идеи. Вдобавок специфический рынок фермерской автоматизации накладывает особые ограничения на свободу творчества создателей: технику надо сертифицировать, привести в соответствие определённым требованиям безопасности и стандартам определённых стран нюансов много.

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

Рой в стальном доме от BeeWise

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

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

Система BeeHome помещается в стандартный 20-футовый морской контейнер и обеспечивает безопасным жильём до 40 колоний пчёл. Натренированный ИИ сохраняет в контейнере идеальные условия для развития пчелиных семей: контролирует влажность, освещённость, температуру и состав воздуха. Если система заметит отклонения параметров от нормы, на которые не сможет повлиять сама (например, обнаружит влияние пестицидов или паразитических клещей на пчёл), она моментально сообщит владельцу о выявленной проблеме.

Стартап успешно привлёк инвестиции, с первой же попытки заработав около $10 млн на производство роботизированных пчелиных домов + $6 млн в виде различных грантов и премий от европейских и израильских государственных программ и частных инициатив.

Робоферма навсегда

К 2050 году учёные прогнозируют рост населения планеты до 10 млрд человек. И если мы не хотим наблюдать ландшафты в духе Безумного Макса, к потреблению ресурсов надо подходить ответственно. Умные технологии для сельского хозяйства могут улучшить обстановку на планете, не только сделав еду доступной и безопасной, но и решив экологические вопросы. Большинство парниковых газов производят не заводы и автомобили, а фермы. Поэтому роботизация агропромышленности неизбежный тренд ближайших десятилетий.

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

Задачи: почему мы вообще в это ввязались

О Flutter мы были наслышаны. Нам давно хотелось опробовать эту перспективную технологию, и в начале этого года новый проект представил такой случай. Задача состояла в следующем: за 34 месяца разработать кроссплатформенное приложение, с помощью которого фермеры могли бы продавать свою продукцию конечным потребителям. Эта новая торговая площадка должна предоставлять участникам удобные инструменты:

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

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

Поиск решения: почему выбрали Flutter

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

По большому счёту, выбирали между нативом и Flutter. React Native и Xamarin отбросили почти сразу, с ними уже имелся опыт не очень удачный. Также рассматривали PWA, но этот вариант тоже пришлось забраковать: на момент выбора там было не всё хорошо с поддержкой нативных функций системы, особенно в iOS. К тому же для хорошей поддержки требовались свежие версии OS, что тоже могло стать проблемой. В общем, изучив вопрос поглубже, решили не собирать грабли.

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

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

• виджетный (компонентный) подход, сродни React

• кроссплатформенный меньше кода, потенциально упрощает тестирование

• богатый инструментарий разработчика IDE и прочее

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

• продукт, который развивает и продвигает Google и большое Open-source community

• крупные компании Google, Groupon, Alibaba разрабатывают на нём свои приложения

Были и минусы:

• мало разработчиков всего 121 резюме, 11 лидов/сеньоров в Москве

• дорогие лиды/сеньоры

• относительно мало технической информации stackoverflow и т.п.

• пока мало готовых (сложных) компонентов стандартные/системные тут не используются

• язык новичкам придётся учить Dart (но легко переходить, если есть опыт разработки на Java или JavaScript)

• сложно найти подрядчиков с опытом

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

Пришлось фантазировать: формирование команды

После выбора решения одним из главных вызовов стало формирование команды под новый проект. О поиске Flutter-разработчиков можно написать отдельную статью. На момент старта проекта весной 2020 года подходящих специалистов на рынке было, мягко выражаясь, не густо. HH по запросу Flutter выдавал несколько десятков резюме, в которых значился некоммерческий опыт: Мне было интересно, и я начал разрабатывать своё приложение или Уговорил попробовать сделать какой-то простенький внутренний проект в компании.

И всё же через HH мы нашли нашего первого разработчика, Михаила. Ему так понравился Flutter, что он по собственной инициативе сделал на этом фреймворке приложение для своей компании но развития оно, к сожалению, не получило. Михаил хотел работать с Flutter дальше, поэтому он вышел на рынок, где мы и нашли друг друга. Вместе с ним формировать команду мобильной разработки стало немного проще: появилась своя компетенция.

Основная масса специалистов по Flutter это младшие разработчики, которые только начинают свой путь, а также старшие или ведущие, у которых есть время изучать современные технологии и пробовать их в виде proof of concept. Проще всего адаптироваться к Flutter тем, кто имеет опыт Android-разработки. На втором месте web-разработчики: react, vue.js здесь близкий по духу компонентный подход.

И всё же людей на рынке было крайне мало, а в активном поиске ещё меньше. С начинающими разработчиками мы решали и решаем вопрос в т.ч. за счёт нашей стажёрской программы для студентов старших курсов вузов, где под руководством опытных наставников ребята становятся полноценными джунами. Так было с Евгением, который пришёл к нам на стажировку по мобильной разработке. Обучался под руководством Михаила почти со старта проекта и достаточно быстро дошёл до продуктовых задач.

Однако с синьорами и мидлами дело было совсем плохо, обычные каналы поиска не работали. Пришлось фантазировать: искали людей в тематических telegram-каналах и через Хабр, среди авторов статей по Flutter. С подходящими кандидатами списывались, общались, давали тестовые задания. Это вынудило нас расширить географию на всю Россию, что стало новым опытом: до этого мы рассматривали только кандидатов из городов, в которых есть наши офисы но с Flutter это не работало.

На сегодняшний день география команды довольно обширна: кроме москвичей, у нас работают жители Петрозаводска, Елабуги, Барнаула. Есть кандидаты технических и физико-математических наук. Таким образом, команда формировалась постепенно, параллельно с активной разработкой приложения. Сейчас у нас уже 7 разработчиков, появляются новые проекты на Flutter мы растём.

Изначально работу выстраивали по принципу feature-driven development (FDD, разработка, управляемая функциональностью). Но впоследствии решили перейти на унифицированный процесс разработки на основе OpenUP: такой способ лучше подходит для управления разработкой всего продукта и координации нескольких команд архитекторов, аналитиков, разработчиков, тестировщиков. Внутри команд разработки используем Scrum.

Особенности разработки на Flutter

Когда говорят о кроссплатформенной мобильной разработке, часто сравнивают React Native и Flutter. Однако нужно понимать, что React Native это не история про один код на все платформы. Недаром официальный слоган проекта Learn once, write anywhere. Дело в том, что в React Native пишут код на JavaScript, который использует нативные для каждой платформы компоненты и они довольно сильно отличаются. Да, есть общие компоненты, вроде Text и View: под обе платформы, хотя и с нюансами. Но много и таких, что работают только на одной ОС. Поэтому в React Native нередко можно встретить выражения:

if (Platform.OS == 'ios') ...`

При использовании Flutter разработка ведётся на языке Dart, который компилируется в нативный для платформы код. При этом вместо нативных компонентов используется собственная библиотека виджетов, которые выглядят как нативные Material и Cupertino для Android и iOS соответственно. Вы можете использовать виджеты из обеих библиотек в одном приложении, кроме того, их очень легко кастомизировать.

В результате код действительно выходит кроссплатформенным. Целевую платформу необходимо учитывать лишь изредка. Например, у нас была ситуация с отображением маркеров на google-карте. У этих изображений должен быть разный исходный размер, а значит механика отрисовки должна учитывать устройство, на котором запущено приложение.

Бывает и так, что есть уникальная для платформы функциональность. Подстановка СМС-кодов верификации на iOS работает по умолчанию, от программиста не требуется никаких действий. А на Android нужно использовать системные методы, чтобы получить этот код программно и подставить в нужное поле. Хотя даже для этой задачи уже существуют Flutter-библиотеки, например, sms_user_consent. Весь платформенный код в ней уже создан, остаётся только добавить свой listener для получения сообщений.

if (Platform.isAndroid) {  listenForCode();}void listenForCode() {  smsUserConsent = SmsUserConsent(      phoneNumberListener: () {},      // Действия при получении смс-сообщения      smsListener: () {        Log('code is updated to ${smsUserConsent.receivedSms}');        final sms = smsUserConsent.receivedSms;        _smsCodeController.text = sms.substring(sms.lastIndexOf(' ') + 1);      });  smsUserConsent.requestSms();}

Одна из не очень удобных особенностей Flutter достаточно динамичный релизный цикл. Как и во всех подобных активно развивающихся фреймворках, почти каждое крупное обновление приводит к необходимости внесения изменений в уже написанный код. Например, при переходе с версии 1.20 на 1.22 пришлось потратить несколько часов из-за конфликтов имён классов проекта и встроенных классов Flutter. Тем не менее такие серьезные изменения скорее редкость, они происходят не чаще трёх раз в год.

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

Разработка на Flutter значительно быстрее, нежели нативная. Если говорить о кодовой базе, то нативный мобильный код по объёму для каждой платформы по отдельности был бы примерно аналогичен Dart-коду, но за счет того, что платформ две, получаем существенное увеличение трудозатрат.

Результаты и выводы: стоит ли разрабатывать на Flutter

Новый фреймворк не подвёл: после полугода разработки MVP доступно в магазинах приложений для Android и iOS. Проект по-прежнему развивается, и в этом очень помогает фидбэк пользователей: мы активно взаимодействуем с фермерами, которые делятся своими впечатлениями от использования платформы. В ближайшем будущем хотим подключить к нашему маркетплейсу сторонние сервисы доставки, внедрить онлайн-платежи, организовать процесс совместных покупок. Для реализации этого нам понадобятся не только мидлы и сеньоры, специализирующиеся на Flutter, но и PHP-разработчики (Senior и Team Lead с опытом Magento 2), а также опытные специалисты по Vue.js. Если видите себя членом нашей новой команды обязательно пишите!

Нам очень понравилось работать с Flutter. Тем не менее это решение пока нельзя считать универсальным: для нашего проекта оно подошло на 100%, но при разработке какой-нибудь игры или продукта, использующего более сложные и передовые технологии VR, AR, ML и т.п., всё могло бы сложиться не так гладко. Впрочем, со временем эта функциональность наверняка подтянется.

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

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

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

Мнесверхувидновсё, -тытакизнай!

Первым ярким событием, которое хотелось бы отметить, это начало тиражирования технологий БПЛА (беспилотные летательные аппараты, дроны) для проведения сельскохозяйственных работ в Китае.

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

В связи с существенным оттоком работников Китая из глубинки в города начинает образовываться дефицит низкоквалифицированных ресурсов. В связи с этим фермеры начали искать другие подходы.

Очевидная мысль покупки тракторов является неподъемной тратой для фермеров малых и средних хозяйств. Получение кредитов и рассрочек для них затруднительно. Потому многие обратили внимание на новые более дешевые способы автоматизации БПЛА. По данным AsiaTimes сейчас на полях Китая летают более 42000!!!! дронов, которые делают более 1,2 млн полетов в день.

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

Основной резонный вопрос, возникающий при обсуждении дронов, это обучение операторов. Для решения этой задачи в Китае сейчас работает более 600 центров по обучению, которые уже обучили более 20000 квалифицированных операторов.

Очень хочется надеяться, что в 2021 году получится обеспечить внедрение подобной технологии и в нашей стране.

Кто не работает то ест!

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

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

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

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

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

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

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

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

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

Все выше и выше!

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

Так в чем же особенность этой фермы в Копенгагене? Она самая большая? Нет, вертикальная ферма, расположенная на сталелитейном заводе в Нью-Джерси больше обсуждаемой. Американская ферма производит более 900 тонн продукции ежегодно и она считаетсясамой большая в Мире. Указанная мной ферма по расчетам создателей должна давать самый большой урожай при относительно компактных размерах. По оценкам создателей это чудо инженерной мысли должно обеспечить производство до 1000 тонн зелени ежегодно.

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

Мясо с грядки

Другим интересным кейсом изменения агротехнологий производства в АПК стал пример Beyond meat - продажа растительного мяса. Характерной особенностью котлет этого производителя является почти полная идентичность настоящим мясным котлетам.

Зачем изобретать мясо? Ответ на этот вопрос до безобразия прост - чтобы произвести одну мясную котлету нужно ~1200 литров воды и 4 кв.м земли, а на растительный бургер тратится на 99% меньше воды, на 93% меньше земли и на 46% меньше электроэнергии. Думается, что цифры говорят сами за себя.

Очевидно, что Beyond meat далеко не первый производитель растительного заменителя мясо, но это первый производитель, который смог практически полностью воспроизвести вкус настоящего мяса! Приведу цитату с сайта одной известной сети питания России:

По вкусу, текстуре и консистенции это практически точь-в-точь обычное мясо и даже ведет себя так же: при приготовлении аппетитно румянится и шкворчит, только вместо крови свекольный сок! #Немясо делается из горохового белка, воды и масла. По содержанию белков, жиров, аминокислот и углеводов растительное мясо Beyond Meat близко к обычному, при этом не содержит сои, холестерина, антибиотиков, гормонов и паразитов.

К слову сказать, отечественный производитель растительного мяса ГК ЭФКО уже в сентябре 2020 приступил к продажам своей версии котлет хайбургер (от английской аббревиатуры Healthy Innovations - здоровые инновации) и по предварительным подсчетам до конца года должна была реализовать более 2 тонн продукции.

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

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

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

Привет! Представляю вашему вниманию перевод статьи про возможности пакета FIC(Fast Immutable Collections, Быстрые неизменяемые коллекции). FIC - конкурент для таких пакетов как built_collection и kt_dart, но он намного быстрее и проще в использовании.

Оригинал: https://medium.com/flutter-community/announcing-fic-fast-immutable-collections-5eb091d1e31f

Массивы, к которым вы, возможно, привыкли в других языках, в Dart называются списками (List), и они изменяемые по умолчанию - вы можете добавлять в них новые элементы, удалять и т.д.

var list = [1, 2];list.add(3); // list: [1, 2, 3].

Существует способ создать неизменяемый список с помощью List.unmodifiable, список, по прежнему, будет иметь метод add, который выдаст ошибку во время исполнения, при попытке данный метод вызвать:

var list = List.unmodifiable([1, 2]);list.add(3); // Ошибка во время выполнения программы.

Однако можно делать изменения в копии такого списка:

var list = List.unmodifiable([1, 2]); // Этот список нельзя изменять.var newList = list.toList()..add(3);print(newList); // [1, 2, 3].

Есть способ лучше

Как вы поняли, обычный List можно использовать как неизменяемый, но при этом приходится писать шаблонный код, его становится трудно читать. Существует другой, более хороший способ: использование IList вместо List. IList неизменяемый - неизменяемый список, с простым API для использования.

Чтобы создать IList вы можете просто использовать extension-метод lock над обычным List:

IList<int> iList = [1, 2].lock;

Изменить содержимое IList не получится. Метод add будет возвращать новый IList с добавленным элементом:

var myList = [1, 2].lock; // Его изменить не получится.var newList = myList.add(3));print(myList); // [1, 2].print(newList); // [1, 2, 3].

FIC

Пакет FIC (Fast Immutable Collections, Быстрые неизменяемые коллекции) предоставляет неизменяемые списки. FIC - конкурент для таких пакетов как built_collection и kt_dart, но он намного быстрее и проще в использовании.

По ссылке https://pub.dev/packages/fast_immutable_collections Вы можете посмотреть сравнения по скорости с альтернативными пакетами. Иногда FIC даже быстрее, чем родные коллекции в Dart:

Использование

Неизменяемые коллекции имеют имена IList, ISet и IMap. Чтобы создать неизменяемую коллекцию, Вы просто можете "заблокировать" изменяемую:

IList<int> iList = [1, 2].lock;ISet<int> iSet = {1, 2}.lock;IMap<String, int> iMap = {"a": 1, "b": 2}.lock;

Любой Iterable также может быть заблокирован в неизменяемый список(List) или набор(Set) с помощью toIList() и toISet() соответственно, или используя конструкторы:

IList<int> iList = myIterable.toIList();ISet<int> iSet = myIterable.toISet();// С помощью конструкторов:IList<int> iList = IList(myIterable);ISet<int> iSet = ISet(myIterable);

Также можно "разблокировать" неизменяемые коллекции и получить изменяемые:

List<int> list = iList.unlock;Set<int> set = iSet.unlock;Map<String, int> map = iMap.unlock;// Работает и это:List<int> list = iList.toList();Set<int> set = iSet.toSet();// Работает и это:List<int> list = List.of(iList);Set<int> set = Set.of(iSet);

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

var iList1 = [1, 2].lock;var iList2 = iList1.add(3); // [1, 2, 3].var iList3 = iList2.remove(2); // [1, 3].print(iList1); // Все еще [1, 2].

Благодаря этому методы можно выстраивать в цепочку:

var iList = [1, 2, 3].lock.add(4).remove(2); // [1, 3, 4].

Равенство

По умолчанию, FIC равны, если их содержимое одинаковое и находится в одном порядке:

var iList1 = [1, 2].lock;var iList2 = [1, 2].lock;print(identical(iList1, iList2)); // false.print(iList1 == iList2); // true.

Это является полной противоположностью для обычных списков(List), которые сравниваются по идентичности:

var list1 = [1, 2];var list2 = [1, 2];var list3 = list1;// Обычные списки(List) сравниваются по идентичности:print(identical(list1, list2)); // false.print(identical(list1, list3)); // true.print(list1 == list2); // false.// В то время как ILists сравниваются по содержимому:print(list1.lock == list2.lock); // true.

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

// Эти ILists сравниваются по содержимому:var iList1 = [1, 2].lock;var iList2 = [1, 2].lock;print(iList1 == iList2); // true.// Теперь эти же ILists сравниваются по идентичности:var iList3 = [1, 2].lock.withIdentityEquals;var iList4 = [1, 2].lock.withIdentityEquals;print(iList3 == iList4); // false.

Сортировка

Порядок объектов в ISet и IMap может быть и тем, который Вы изначально ввели, а может быть и отсортирован в зависимости от конфигурации:

var iSet = {2, 4, 1, 9, 3}.lock;print(iSet.join(", ")); // [2, 4, 1, 9, 3].var iSet = {2, 4, 1, 9, 3}.lock.withConfig(ConfigSet(sort: true));print(iSet.join(", ")); // [1, 2, 3, 4, 9].

IMapOfSets

При блокировке Map<K, V>, Вы получаете IMap<K, V>.

Однако заблокированная Map<K, Set<V>> становится IMapOfSets<K, V>:

// Map в IMap.IMap<K, V> map = {'a': 1, 'b': 2}.lock;// Map в IMapOfSets.IMapOfSets<K, V> map = {'a': {1, 2}, 'b': {3, 4}}.lock;

"Map of sets" - это вид мультисловаря(multimap). IMapOfSets позволяет добавлять и удалять объекты, не думая о наборах(sets), которые содержатся внутри.

К примеру:

IMapOfSets<K, V> map = {'a': {1, 2}, 'b': {3, 4}}.lock;print(map.add('a', 3)); // {'a': {1, 2, 3}, 'b': {3, 4}}.

По этой ссылке можно найти пример класса, называющийся StudentsPerCourse, который распределяет студентов по курсам. Каждый студент может быть записан в один или несколько курсов. Такую модель можно получить с помощью словаря(map), в котором ключами будут курсы, а значениями - наборы из студентов.

ListSet

Несмотря на свое название, FIC предлагает и изменяемые типы. К примеру, ListSet сразу же:

1. Изменяемый, упорядоченный набор(Set) фиксированного размера.

2. Изменяемый список(List) фиксированного размера, в котором значения не повторяются:

ListSet<int> listSet = ListSet.of([1, 2, 3]);expect(listSet[2], 3);expect(listSet.contains(2), isTrue);List<int> list = listSet;Set<int> set = listSet;expect(list[2], 3);expect(set.contains(2), isTrue);

Если рассматривать ListSet как Set и сравнивать с LinkedHashSet, то ListSet также является упорядоченным и имеет схожую производительность. Но ListSet занимает меньше места в памяти и может быть отсортирован, так же как и List. Также, у Вас есть доступ к его элемента по индексу за константное время.

Минусом, конечно же, является, что ListSet имеет фиксированный размер, а LinkedHashSet - нет. ListSet эффективен и как List, и как Set. Поэтому, к примеру, у него есть эффективный sort метод, в то время как LinkedHashSet требует конвертации в List, сортировки, а затем обратного преобразования в Set.

Расширения, хелперы и компараторы

FIC также предоставляет:

Iterable хелперы и расширения:

• combineIterables - высокоуровневая функция, которая объединяет два Iterable в один.

• Iterable.isNullOrEmpty, Iterable.isNotNullOrEmpty и Iterable.isEmptyButNotNull.

• Iterable.deepEquals сравнивает два объекта по порядку с помощью оператора ==.

• Iterable.deepEqualsByIdentity сравнивает все объекты по порядку с помощью identical.

• Iterable.findDuplicates ищет повторяющиеся значения и возвращает Set с дубликатами.

• Iterable.removeNulls убирает все объекты, равные null, из Iterable.

• Iterable.removeDuplicates убирает все повторяющиеся объекты. Дополнительно, можно использоваться by функцию для сравнения объектов. Если добавить аргумент removeNulls равное true, то уберутся и null-объекты.

• Iterable.sortedLike возвращается список, отсортированный в соответствии с Iterable сортировки. Объекты, которых нет в сортировочном Iterable, встанут в конец.

Расширения над List:

• List.sortOrdered похож на метод sort, но использует сортировку слиянием(merge sort). В противовес sort, orderedSort стабильный, что означает, что различные объекты, которые сравниваются как равные, остаются в начальном порядке.

• List.sortLike сортирует список в соответствии с ordering Iterable. Объекты, которых нет в ordering, встанут в конец в определенном порядке.

• List.moveToTheFront перемещает первое вхождение элемента в начало списка.

• List.moveToTheEnd перемещает первое вхождение элемента в конец списка.

• List.whereMoveToTheFront перемещает все элементы, которые удовлетворяют предоставленным требованиям, в начало списка.

• List.whereMoveToTheEnd перемещает все элементы, которые удовлетворяют предоставленным требованиям, в конец списка.

• List.toggle Если элемента нет в списке, добавляет его и возвращает true. Если уже есть, то удаляет первый необходимый и возвращает false.

• List.compareAsSets возвращает true если в списке есть требуемые элементы (в любом порядке). Не берутся во внимание повторяющиеся элементы.

• List.mapIndexed преобразует каждый элемент списка. Функция принимает изначальный элемент и его индекс.

• List.splitList убирает элементы из списка, которые удовлетворяют условию.

• List.divideList возвращает несколько списков, разделенных по выбранным элементам.

• List.addBetween возвращает новый список, добавив разделение между изначальными элементами.

• List.concat возвращает эффективное слияние до 5 списков.

• List.splitByLength делит список на один или несколько списков с максимальным количеством элементов length.

• List.update возвращает список, в котором новые элементы добавляются или обновляются в зависимости от порядкового номера.

• List.distinct удаляет повторяющиеся объекты, оставляя только уникальные.

• List.reversedView возвращает список объектов в обратном порядке.

Расширения над Set:

• Set.toggle Если объекта нет в Set, то он добавляется и возвращается true. Иначе, если объект уже есть в Set, то он удаляется и возвращается false.

Расширения над Iterator:

• toIterable, toList, toSet, toIList, и toISet преобразуют Iterator в Iterable, List, Set, IList, и ISet, соответственно.

Расширения над Boolean:

• compareTo делает true > false.

Компараторы

• compareObject

• compareObjectTo

• sortBy

• sortLike

• if0

Пакет разработан Philippe Fanaro и Marcelo Glasberg.

Другие Flutter пакеты от автора:

• async_redux (на Medium: Асинхронный Redux: Нешаблонная версия Flutter Redux https://medium.com/flutter-community/https-medium-com-marcglasberg-async-redux-33ac5e27d5f6)

• i18n_extension (на Medium: Потрясающе легкие переводы и интернационализация для Flutter приложений https://medium.com/flutter-community/i18n-extension-flutter-b966f4c65df9)

• provider_for_redux

• image_pixels

• network_to_file_image

• matrix4_transform

• back_button_interceptor

• indexed_list_view

• animated_size_and_fade

• align_positioned

• assorted_layout_widgets

https://github.com/marcglasberg

https://twitter.com/GlasbergMarcelo

Читайте сообщество Flutter в Twitter: https://www.twitter.com/FlutterComm

История проекта OpenAg MIT

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

Как раз для таких целей и был создан проект OpenAg (Открытое сельское хозяйство) в рамках медиа-лаборатории Массачусетского технологического института (MIT) в 2005 году. Основным направлением OpenAg было создание мини-теплицы с контролируемой средой, которая бы использовала технологии беспочвенного земледелия, включая гидропонные и аэропонные системы для выращивания сельскохозяйственных культур в помещении. Такая платформа получила название Food Computer (Продовольственный/Пищевой компьютер). При его работе использовалось огромное количество датчиков для мониторинга внутреннего климата, а настройки подбирались таким образом, чтобы условия окружающей среды оставались постоянными и оптимальными.

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

Термин "Food Computer" обычно применялся к любой из систем контролируемой окружающей среды проекта OpenAg. Однако важно отметить, что существовало несколько размеров этих самых мини-теплиц. Например, устройство размером со столешницу предназначалось для использования в домах, классах и небольших экспериментальных лабораториях. Модель среднего размера была похожа на международный стандартизированный транспортный контейнер и должна была использовать вертикальные сельскохозяйственные системы. Она предназначалась для использования в кафетериях, ресторанах, местных бакалейных лавках и крупномасштабных экспериментальных лабораториях. А самые большие версии должны были стать складскими центрами обработки пищевых данных, которые функционировали бы на уровне промышленного растениеводства.

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

Идея создания мини-теплиц с контролируемой средой без почвы и солнечного света получила положительные отклики со стороны общественности. Калеб Харпер, ведущий специалист проекта, заручившись поддержкой региональных спонсоров и крупных международных компаний, таких как Target, Unilever и Welspun, совместно с командой ученых и небольших стартапов отправился воплощать мечту в реальность. На протяжении нескольких лет Харпер кормил публику фальсифицированными промежуточными результатами. Перед каждой демонстрацией работоспособности мини-теплиц для спонсоров он приказывал подчиненным помещать в устройства растения, выращенные в других местах. Например, одного из младших сотрудников попросили купить травы на соседнем цветочном рынке, смахнуть пыль с земли, в которой она была выращена, и поместить ее в теплицу для фотосессии. И так происходило каждый раз с разными сельскохозяйственными культурами.

По словам сотрудников, цель состояла в следующем: сделать все возможное, чтобы устройства соответствовали заявлениям Харпера в СМИ. Среди частых выступлений Калеб также упомянул о том, что теплицы способны выращивать такие продукты, как брокколи, в четыре раза быстрее традиционных методов. Эти утверждения вызвали общественный резонанс и привели Харпера и его команду к публикации статей в различных популярных изданиях, начиная от Wall Street Journal и заканчивая Wired и National Geographic.

Спустя 15 лет с начала проекта, ученые, работавшие в лаборатории, подтвердили изданию Business Insider информацию о том, что устройства никогда не работали так, как задумано, и вместо того, чтобы признаться в этом спонсорам или в интервью, Харпер продолжал настаивать на их уникальности и эффективности. Зачастую сотрудникам лаборатории отдавали приказ купить растения в магазине, смахнуть с них грязь и поместить в пищевые компьютеры перед презентацией публике.

Однако наряду с научной ложью, Калеба Харпера и его проект обвинили и в нанесении вреда окружающей среде. Дело в том, что какие-то опыты и исследования все-таки проводились, но больше для галочки. А отходы, которые оставались по окончании процессов сливали в сточные воды города Массачусетс. В сентябре 2019 года бостонская радиостанция WBUR опубликовала отчет с подробным описанием обвинений в том, что лаборатория OpenAg в исследовательском и инженерном центре Бейтса Массачусетского технологического института в Мидлтоне сбрасывала азотсодержащий гидропонный раствор в систему сточных вод в несколько раз выше установленных государством норм. Это в свою очередь заинтересовало Департамент охраны окружающей среды города Массачусетс. Он провел собственное расследование, по итогам которого обязал MIT выплатить штраф в размере 25 000 тысяч долларов.

Как можно было догадаться, проект закрыли, Калеб Харпер покинул научную лабораторию, Массачусетский технологический институт понес определенные репутационные риски, а уровень доверия к разработкам в области сельского хозяйства значительно упал. Теперь к проектам медиа-лаборатории общественность и СМИ относятся с пристальным вниманием, дабы не попасться на еще одну утку. Вот к каким последствиям приводит погоня за уникальностью. Это был пример неудачных проектов в сельскохозяйственной сфере. Оставайтесь с нами, чтобы не пропустить новые истории.