Почему умножение матриц такое

Опубликовано 30.11.2022 автором admin

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

Маленькое предисловие

В дальнейшем нам понадобится такая структура, как векторное пространство, а точнее его частный случай $\mathbb{R}^n$ — пространство столбцов высотынад $\mathbb{R}.$ Кратко напомню, что под этим понимается.

Во-первых, $\mathbb{R}^n$ — это следующее множество

$\mathbb{R}^n=\{[x_1,\ldots,x_n] \,|\,x_i\in\mathbb{R}\},$

где таким образом $[x_1,\ldots,x_n]$ обозначен вектор-столбец высотыто есть

$[x_1,\ldots,x_n]=\left(\begin{array}{c} x_1 \\ \vdots \\ x_n \end{array}\right).$

Во-вторых, для любых векторов $x,y \in \mathbb{R}^n$ определено сложение

$x+y = [x_1,\ldots,x_n]+[y_1,\ldots,y_n]=[x_1+y_1,\ldots,x_n+y_n]$

и для любого вектора $x \in \mathbb{R}^n$ определено умножение на скаляр $\lambda \in \mathbb{R}$

$\lambda x = \lambda[x_1,\ldots,x_n] = [\lambda x_1,\ldots,\lambda x_n].$

В-третьих, каждый вектор $x \in \mathbb{R}^n$ единственным образом представим в следующем виде

$x=x_1e_1+\ldots+x_ne_n,$

где $x_1,\ldots,x_n$ — скаляры, а $(e_1,\ldots,e_n)$ — следующая система векторов

$e_1=[1,0,\ldots,0],\,e_2=[0,1,\ldots,0],\ldots,\,e_n=[0,0,\ldots,1].$

Такая система векторов называется базис, а скаляры, участвующие в разложение вектора, называются координатами этого вектора в данном базисе. Стоит отметить, что в $\mathbb{R}^n$ это не единственный базис, но везде далее под «зафиксируем базис» можно понимать именно эту систему векторов.

Умножение матрицы на вектор

Прежде чем переходить к умножению матриц, посмотрим, из каких соображений вводится умножение матрицы на вектор. Для этого рассмотрим линейное отображение $\mathcal{A}$

$\mathcal{A}:\mathbb{R}^n \rightarrow \mathbb{R}^m.$

То, что $\mathcal{A}$ — линейное отображение, означает, что для любых векторов $x,y \in \mathbb{R}^n$ и любого скаляра $\lambda \in \mathbb{R}$ выполняются следующие два условия:

$\begin{array}{l} \mathcal{A}(x+y)=\mathcal{A}x + \mathcal{A}y.\\ \mathcal{A}(\lambda x)=\lambda\mathcal{A}x.\end{array}$

Или их можно объединить в одно

$\mathcal{A}(\lambda_1 x + \lambda_2 y)=\lambda_1\mathcal{A} x + \lambda_2 \mathcal{A}y.$

Нас интересует, как линейное отображение $\mathcal{A}$ действует на произвольный вектор $x \in \mathbb{R}^n.$ Для этого зафиксируем в $\mathbb{R}^n$ базис $(e_1,\ldots,e_n),$ а в $\mathbb{R}^m$ базис $(f_1,\ldots,f_m).$ Теперь мы можем разложить векторпо базису

$x = x_1e_1+\ldots+x_ne_n$

и представить $\mathcal{A}x$ в следующем виде

$\mathcal{A}x=\mathcal{A}(x_1e_1+\ldots+x_ne_n)=x_1\mathcal{A}e_1+\ldots+x_n\mathcal{A}e_n.$

Заметим, что $\mathcal{A}e_1,\ldots,\mathcal{A}e_n \in \mathbb{R}^m,$ а поскольку в $\mathbb{R}^m$ зафиксирован базис, то эти векторы также можно разложить по базису

$\mathcal{A}e_1 = a_{11}f_1+a_{21}f_2+\ldots+a_{m1}f_m, \\ \mathcal{A}e_2 = a_{12}f_1+a_{22}f_2+\ldots+a_{m2}f_m, \\ \ldots \\ \mathcal{A}e_n = a_{1n}f_1+a_{2n}f_2+\ldots+a_{mn}f_m.$

или тоже самое в векторной записи

$\begin{array}{cccc} \mathcal{A}e_1 = \left( \begin{array}{c} a_{11}\\ \vdots \\ a_{m1} \end{array} \right), & \mathcal{A}e_2 = \left( \begin{array}{c} a_{12}\\ \vdots \\ a_{m2} \end{array} \right), & \ldots &, & \mathcal{A}e_n = \left( \begin{array}{c} a_{1n}\\ \vdots \\ a_{mn} \end{array} \right) \end{array}.$

Подставляем в равенство выше и получаем

$x_1\mathcal{A}e_1+\ldots+x_n\mathcal{A}e_n=x_1 \left( \begin{array}{c} a_{11}\\ \vdots \\ a_{m1} \end{array} \right) + \ldots + x_n \left( \begin{array}{c} a_{1n}\\ \vdots \\ a_{mn} \end{array} \right) = \left( \begin{array}{c} x_1a_{11} + \ldots + x_na_{1n}\\ \vdots \\ x_1a_{m1} + \ldots + x_na_{mn} \end{array} \right)$

Но правая часть равенства есть не что иное, как формула умножения матрицы на вектор-столбец

$\left( \begin{array}{ccc} a_{11} & \ldots & a_{1n} \\ \vdots & \ddots & \vdots \\ a_{m1} & \ldots & a_{mn} \end{array} \right) \left( \begin{array}{c} x_{1} \\ \vdots \\ x_n \end{array} \right),$

где столбцы матрицы есть векторы $\mathcal{A}e_1,\ldots,\mathcal{A}e_n$

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

$\small \left( \begin{array}{ccc} a_{11} & \ldots & a_{1n} \\ \vdots & \ddots & \vdots \\ a_{m1} & \ldots & a_{mn} \end{array} \right) \left( \begin{array}{c} x_{1} \\ \vdots \\ x_n \end{array} \right) = x_1 \left( \begin{array}{c} a_{11}\\ \vdots \\ a_{m1} \end{array} \right) + \ldots + x_n \left( \begin{array}{c} a_{1n}\\ \vdots \\ a_{mn} \end{array} \right) = \left( \begin{array}{c} x_1a_{11} + \ldots + x_na_{1n}\\ \vdots \\ x_1a_{m1} + \ldots + x_na_{mn} \end{array} \right).$

И такое определение умножения будет согласовано с тем, как линейное отображение $\mathcal{A}$ действует на вектор

Если теперь обозначить $y= \mathcal{A}x,$ то координаты вектора выражаются через координаты вектора следующим образом

$y_i = \sum_{i=1}^{n}a_{ij}x_j,\quad i = 1,\ldots,m,$

Кроме того, мы получили и другой важный результат, вернёмся к выражению для $\mathcal{A}x$

$\mathcal{A}x=\mathcal{A}(x_1e_1+\ldots+x_ne_n)=x_1\mathcal{A}e_1+\ldots+x_n\mathcal{A}e_n.$

Из него следует, что линейное отображение $\mathcal{A}$ полностью определяется своими значениями на базисных векторах, то есть, если нужно найти $\mathcal{A}x,$ то достаточно знать $\mathcal{A}e_1,\ldots,\mathcal{A}e_n.$

Далее, мы поместили эти векторы в матрицу и определили умножение так, что $\mathcal{A}x$ есть произведение соответствующей матрицынаПолучается, что линейному отображению можно поставить в соответствие матрицу, которая полностью его определяет

$\forall x \in \mathbb{R}^n: \mathcal{A}x = Ax.$

Такая матрица называется матрицей линейного отображения $\mathcal{A}$ в выбранных базисах пространств $\mathbb{R}^n$ и $\mathbb{R}^m.$

Если говорить более строго, то существует взаимно однозначное соответствие между линейными отображениями из $\mathbb{R}^n$ в $\mathbb{R}^m$ и матрицами размера $m \times n.$

Теперь мы можем перейти к умножению матрицы на матрицу.

Умножение матрицы на матрицу

Рассмотрим линейные отображения $\mathcal{A}$ и $\mathcal{B}$

$\mathcal{A} : \mathbb{R}^m \rightarrow \mathbb{R}^s, \quad \mathcal{B} : \mathbb{R}^n \rightarrow \mathbb{R}^m,$

и их композицию $\mathcal{C}$

$\mathcal{C} = \mathcal{A} \circ \mathcal{B}.$

Легко проверяется, что $\mathcal{C}$ будет линейным отображением

$\mathcal{C}(\lambda_1x+\lambda_2y)= (\mathcal{A} \circ \mathcal{B})(\lambda_1x+\lambda_2y)= \mathcal{A}(\mathcal{B}(\lambda_1x)+\mathcal{B}(\lambda_2y))=\mathcal{A}(\lambda_1\mathcal{B}x+\lambda_2\mathcal{B}y)= \\ = \lambda_1\mathcal{A}(\mathcal{B}x)+\lambda_2\mathcal{A}(\mathcal{B}y)=\lambda_1\mathcal{C}x+\lambda_2\mathcal{C}y.$

Поэтому, если зафиксировать в $\mathbb{R}^n, \mathbb{R}^m$ и $\mathbb{R}^s$ базисы, то каждому линейному отображению можно поставить в соответствие его матрицу

$\mathcal{A} \mapsto A, \quad \mathcal{B} \mapsto B, \quad \mathcal{C} \mapsto C.$

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

$(\mathcal{A} \circ \mathcal{B})x =\mathcal{A}(\mathcal{B}(x)) = \mathcal{A}y = z$

и найдём координаты вектора через координаты вектора

Так как $\mathcal{A}y=z,$ то

$z_i=\sum_{k=1}^{m}a_{ik}y_k, \quad i =1,\ldots,s.$

Но из равенства $y= \mathcal{B}x$ следует, что

$y_k=\sum_{j=1}^{n}b_{kj}x_j, \quad k = 1,\ldots,m.$

Подставляем в равенство выше и получаем

$z_i=\sum_{k=1}^{m}a_{ik}y_k= \sum_{k=1}^{m}a_{ik}\sum_{j=1}^{n}b_{kj}x_j=\sum_{j=1}^{n}(\sum_{k=1}^{m}a_{ik}b_{kj})x_j, \quad i =1,\ldots,s.$

С другой стороны, $(\mathcal{A} \circ \mathcal{B})x = \mathcal{C}x=z,$ то есть

$z_i= \sum_{j=1}^{n}c_{ij}x_j, \quad i = 1,\ldots,s.$

Сравнивая первое и второе равенство для координатполучаем такое соотношение

$c_{ij}=\sum_{k=1}^{m}a_{ik}b_{kj} \quad (i=1,\ldots,s;\,j=1,\ldots,n),$

которое является формулой умножения матрицы на матрицу.

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

Другими словами, если линейным отображениям $\mathcal{A}$ и $\mathcal{B}$ поставить в соответствие их матрицыито композиции этих отображений $\mathcal{A} \circ \mathcal{B}$ ставится в соответствие матрица, которая является произведением матриц

Отсюда, кстати, следует, что матрицыиможно умножить только тогда, когда число столбцов матрицыравно числу строк матрицы

Пусть — матрица размера $m \times n,$ а — матрица размера $s\times k.$ Тогда, если в пространствах $\mathbb{R}^n,\mathbb{R}^m,\mathbb{R}^k$ и $\mathbb{R}^s$ зафиксировать базисы, то этим матрицам ставятся в соответствие линейные отображения $\mathcal{A}$ и $\mathcal{B}$

$\mathcal{A}:\mathbb{R}^n \rightarrow \mathbb{R}^m,\quad \mathcal{B}: \mathbb{R}^k \rightarrow \mathbb{R}^{s}.$

Но композиция $\mathcal{A} \circ \mathcal{B}$ определена только тогда, когда то есть число столбцов матрицыравно числу строк матрицы

Заключение

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

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

Ссылки на литературу и различные источники

Основное:

[1] Введение в алгебру. В 3 частях. Часть 1. Основы алгебры. Кострикин А.И.

Дополнительное:

[1] Введение в алгебру. В 3 частях. Часть 2. Линейная алгебра. Кострикин А.И.

[2] Линейная алгебра и геометрия, Кострикин А.И., Манин Ю.И.

Прочее:

Для создания графики использовался manimCE: https://github.com/manimCommunity/manim

Кому интересно, то вот видео к статье:

ссылка на оригинал статьи https://habr.com/ru/post/697934/

Разрабатываем софт через статистику

Опубликовано 30.11.2022 автором admin

Ответить

КДПВ не будет, извиняйте. Значение имеют только текст, тесты и статистика 🙂

Сам термин Statistics Driven Development (сокращенно SDD) я ввел в my.games году в 2017м, но среди очень небольшого количества людей и до сих пор не встречал его в статьях. Самому мне было лень писать куда-то, кроме чатиков. Увы.

Возможно, этот подход давно существует и просто я не в курсе. Скажите, плиз, если это так.

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

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

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

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

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

В моей практике хорошо зарекомендовал себя подход, когда ключевые места в коде отправляют в базу статистики деперсонализированные данные, а на сервере выполняются проверки, соответствуют ли пришедшие данные ожиданиям. Проверки выполняются как вручную, так и с помощью SQL запросов и отдельных скриптов. Разброс интервалов cron-проверок в проектах, где я участвовал, составлял от 5 минут до 4 часов — в зависимости от объемов данных. Чем больше данных приходит за минуту, тем меньше можно делать интервал проверки, чтобы минимизировать вероятность случайных выбросов.

В реализации, использующейся в Игровом центре my.games, запаздывание между отправкой данных клиентом и размещением их в БД в пригодном для анализа виде составляло около 90 секунд. Это время легко сократить в разы, но на практике оказалось, что и 90-секундное отставания комфортно для очень быстрых итераций «тестировщик увидел ошибку — разработчик сразу же посмотрел по базе детали того, что случилось».

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

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

— количество исключений в проекте для последней зарелизенной версии за последние 10 минут не больше 2% от количества запусков;

— количество установок каждой из ключевых игр за последние 30 минут составляет не менее 50% от количества, которое было час назад и не менее 70% от того, что было сутки и неделю назад;

— push-уведомления дошли до пользователя не позднее 20 секунд с момента отправки серверным кодом не менее чем в 80% случаев и не позднее 1 минуты не менее чем в 90% случаев.

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

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

(в каком месте проценты упали до нуля — там и надо искать проблему)

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

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

Ключевые выигрыши от подхода SDD следующие:

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

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

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

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

Если интересно, могу написать продолжение о том, как всё это внедрялось.

ссылка на оригинал статьи https://habr.com/ru/post/702690/

Как приложения заботятся о своих пользователях. Основные принципы хорошего UX

Опубликовано 30.11.2022 автором admin

Ответить

Привет! На связи Катя — UX-дизайнер студии Everest. Сегодня поговорим про заботу о пользователях. Мы хотим рассказать об основных принципах, которые делают приложения живыми и отзывчивыми, а клиентов — более лояльными.

Что такое забота в интерфейсах?

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

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

Примечание

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

Приложения, которые участвовали в анализе

Быть понятным

Путь пользователя начинается с поиска и скачивания нужного приложения. У многих компаний оно бывает не одно. Например, поисковый запрос в AppStore «Перекрёсток» показал два приложения: «Перекрёсток — доставка продуктов» и «Перекресток Впрок — продукты». Даже описание внутри карточки не всегда помогает понять разницу и приходится обращаться за помощью в службу поддержки.

Чтобы понять, через какое приложение заказать из магазина «Перекрёсток», пришлось обратиться в службу поддержки VK

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

А вот «Пятёрочка», напротив, сделала поиск удобным и придумала названия, в которых не запутаешься: «Пятёрочка — скидки и акции» и «Пятёрочка — доставка».

Замечать изменения

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

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

Изменение адреса доставки в разных приложениях

Давать полный ответ на любое действие

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

Начинать разговор первым

Часто пользователь видит пустой экран перед тем, как начать поиск товаров. Но есть приятные исключения: «Пятёрочка» и «ВкусВилл» отображают популярные запросы. Это и есть забота.

Подсказывать

Если для активации услуги или предложения есть какие-то условия, проявлением внимания будет рассказать о них. Например, у «Ленты» и «Азбуки Вкуса» есть минимальная сумма заказа для бесплатной доставки. Поэтому в корзине приложения подсказывают, сколько нужно добавить товара, чтобы воспользоваться этой опцией.

Подсказки для пользователя в разных приложениях

Говорить на одном языке

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

Термины часто встречаются в карточке товара в разделе «Характеристики»: «Лента» использует ТУ, а «Пятёрочка» заменила его на более понятное «Стандарт производства».

Важно, чтобы названия объектов и элементов интерфейса одинаково понимали все пользователи. Например, для первой страницы приложения можно использовать универсальное «Главная» или «Домой».

Использование терминов в разных приложениях

Объяснять свои намерения

«Забота — всё, что делается мне во благо с моего согласия»

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

Делать это можно различными способами: например, использовать не только стандартные алерты, но и полноценные стилизованные экраны, сохраняя образ бренда и свой голос. Как это делает «Лента».

«Перекрёсток» объясняет пользователю, зачем ему заполнять дополнительные поля и оставлять свои данные.

Быть откровенным в разговоре о деньгах

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

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

Показывать статус

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

Приложение может показывать прогресс-бар который дает понимание, где сейчас заказ, и сколько этапов доставки ещё его ждет («ВкусВилл», «Пятерочка») или один обновляемый статус («Лента»)

Быть предсказуемым

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

Информация о заказе после оформления и оплаты

Говорить об ограничениях

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

Запрос адреса доставки до начала выбора продуктов

Быть находчивым

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

Предложение альтернативного решения в разных приложениях

Быть проницательным (предугадывать желания)

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

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

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

Заботиться о чужом времени

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

Заботиться о времени можно и взяв на себя некоторые обязанности пользователя. Например, поиск продуктов. Для этого у «Ленты» есть список покупок, составив который, можно найти несколько товаров сразу.

А в подборке «Рецепты» приложение предлагает автоматически подобрать нужные ингредиенты из каталога.

Быть простым

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

Думая о заботе, не забывайте о главном

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

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

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

Вывод

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

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

ссылка на оригинал статьи https://habr.com/ru/post/702694/

Поездка в Израиль на Nordic Tech Tour

Опубликовано 30.11.2022 автором admin

Ответить

Жизнь удивительно непредсказуема. Еще 4 месяца назад я даже подумать не мог, что придется ехать в Израиль. Дело в том что в нынешнем проекте на работе я активно работаю с микроконтроллером nrf5340 норвежской fabless компании Nordic Semiconductor. Вендор в этом году проводит целую массированную компанию мастер классов по всей Eвропе. Почему Израиль? Дело в том, что Израиль это единственная страна, которая разрешает в нынешней конъюнктуре приезжать гражданам России без визы.
Не каждый день случается поехать на мероприятие из России в Израиль за тысячи километров. Поэтому я решил написать про это приключение на тот случай, если это понадобится другим людям.

Что надо из бумаг?

Документ	Назначение	degree of need
Загранпаспорт	Для пересечения границы и получения посадочного талона	obligatorily
Подтверждение посуточной аренды	Вообще нигде не спрашивали но лучше забронировать заранее	optional
Авиа билеты	Чтобы добраться до Израиля	obligatorily
Наличные деньги	Для оплаты общественного транспорта, такси, продуктов	obligatorily
Медицинская страховка	Для компенсации медицинской помощи при необходимости. На границе не спрашивали	optional

Что надо из вещей?

Предмет	Назначение	degree of need
Телефон большим экраном и функцией GPS	Улицы в Израиле извилистые как лабиринт. Перекрестки через каждые 50 метров. Без GPS новичок просто заблудится и будет ходить кругами	obligatorily
кепку с козырьком	В Израиле очень яркое солнце без кепки вы днем будете ходить как слепой с палочной	obligatorily
визитные карточки	Первый вопрос который вам зададут участники семинара это кто вы и откуда. Подготовьте хотя бы 10 карточек	optional
LapTop зарядное устройство	Для полноценной коммуникации. WiFi будет только в комнате и в аэропорту.	optional

Фаза 1: Подготовка бумаг.

—Медицинская страховка. Никто не спрашивал. Делается быстро надо лишь заграничный паспорт или его фото.

—Найти аренду комнаты. Я решил что сначала надо найти аранду. Далее исходя из этого искать авиабилет. Аренду надо найти на booking.com. Дешевле чем 4400 руб за день я ничего не нашел.

—Авиабилеты. Билеты искал в начале сентября. За 3 месяца до начала поездки. Прямых рейсов не было. Самый дешевый вариант оказался только с 2мя пересадками. Стоило это порядка 37000 RUR.

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

В Израиле время по отношению к Москве меньше на час. Если в Москве 0:40, то в Тель-Авиве 23:40.

Подготовьте тайминг поездки. У меня получился такой тайминг.

—В Москве Израильские Шекели нигде не купишь. Как и турецкие Лиры. Пришлось покупать Шекели и Лиры в аэропорту Стамбула и на месте в районе Ramat Gun в Израиле. Для поездки в Израиль из России в нынешней конъюнктуре надо примерно ориентироваться в пяти валютах.

Фаза 2 Дорога в Израиль

При прохождении пограничного контроля для пересечения российской границы спрашивали куда я еду, с какой целью и сколько везу с собой денег. Я сказал что еду на образовательный семинар для программистов в Израиль и что у меня с собой всего-навсего только 700 USD. В реальности хватило и 300 USD. Меня выпустили из РФ и поставили розовую печать на розовой бумаге паспорта.

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

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

У меня было написано 3 мес без права работы.

Далее на такси можно добраться до арендованной комнаты. Вокруг аэропорта десятки таксистов. Предлагают довести оставшиеся 23 км за от 170(3019 RUR) до 250(4440 RUR) Шекелей.

В Израиле сейчас не расплатиться банковскими картами из РФ. Ни сбер ни raif карты не функционируют ни в аэропортах ни в супермаркетах. Расплата только наличными Шекелями.

Гостеприимство местного хозяина booking квартиры просто поражает. Этот риэлтор оставил ключ от комнаты-студии за дверцей в трансформаторной будке! Я чудом достал из темноты ключ не задев рукой высоковольтные провода. Сама комната-студия больше походила на пенал для кровати. Кухня в прихожей. Вместо стола тумбочка. Зато зачем-то на стене висел огромный плазменный брендовый телевизор. Это явное доказательство, что в стране культ телевизора. При этом лестничная клетка без освещения из-за чего я там даже споткнулся и упал. Вся канализация и электропроводка в здании идет по внешней стороне стен здания, что тоже не очень с точки зрения красоты. Такого Израиля я видеть, конечно же, не ожидал.

Это самое дешевое жилище, которое мне удалось найти на booking.com (4333 RUR/day)

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

Как перемещаться по городу я так и не выяснил. Местное мобильное приложение yango сначала зависало потом по 20 мин не могло найти такси в центре города. Но на 3тий день оно всё же вдруг заработало. Автобус 67 тоже не приезжал минут 10. В результате пришлось много ходить пешком. Уже на мероприятии мне местный русскоговорящий житель сообщил, что на автобусе можно ездить только по именным картам с фото владельца и микрочипом. Якобы так жители должны отчитываться перед государством Израиля за свои ежедневные перемещения и полиция за этим тщательно следит.

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

Фаза 3: Собственно само мероприятие Nordic Tech Tour

Мероприятие Nordic Tech Tour состоялось как и было указано на базе Kfar Maccabiah Hotel, Tel Aviv, Israel. Однако за день до этого (27 ноября), когда я пришлет проверить адрес никто из сотрудников отеля даже понятия не имел, что завтра (28 ноября) должно быть это мероприятие и я уже ошибочно пришел к выводу, что зря приехал из России в Израиль.

Представители fabless компании Nordic Semiconductor показали с какой стороны разработчикам следует подходить к их микроконтроллерам семейства nRF5xxx. Особо подробно рассказали про микроконтроллер nrf5340. Сказали, что надо собирать сборки из-под Zephyr Project. Они также сказали, что у них есть собственные чипы PMIC (nPM1100), WiFi-6 чипы (nRF70xx), LTE модем чипы (nRF9160), микроконтроллеры с Bluetooth LE(nRF5340).

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

Рассказали про свои фирменные отладочные платы: nRF5340-ADK, nRF5340-DK, nRF21540-DK, nRF21540-EK.

Был содержательный доклад про ToolChain и SDK. Nordic провозгласил, что официальный ToolChain для их микроконтроллеров это связка West, Kconfig, DeviceTree, CMake, Ninja, GCC, Git, GitHub, Zephyr RTOS, nrfx, MCUboot, VS Code, GDB. В общем ToolChain для разработки на nRF53 бесплатный и доступный.

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

Среди некоторых посетителей всё же прослеживалось явное негодование, что им предстоит отбросить в сторону все знания про FreeRTOS и срочно становится Junior(ами) и быстро изучать Zephyr RTOS.

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

В самом конце семинара каждому посетителю даже подарили отладочную плату nRF5340-DK.

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

Много ли русскоговорящих в Израиле?

Лично я слышал русскую речь на каждой второй улице. Русскоговорящие работают в аэропорту, русскоговорящие работают в уличных лавках, и даже в местных Hi-Tech компаниях. Я зашел в продуктовый магазин на улице Герцеля и дама сама стала спрашивать что я хочу купить прямо на русском. Они каким-то чудеснейшим образом умеют по внешности прохожего определять на каком языке говорит прохожий. Всего за 2 дня я видел в Израиле среди прохожих русскоговорящих всех возрастов: дети, взрослые и пожилые люди.

Фаза 4: Возвращение
В аэропорте при пересечении границы Израиля была процедура Security check. Сотрудник на английском спрашивал сколько дней я был в Израиле, был ли я в Палестине, есть ли знакомые в Израиле и Турции. Что я делал в Анталии в 2019 году. Потом спросил зачем я приезжал в Израиль и требовал доказательств (приглашения). Я показал письмо благодарности от Nordic Semiconductor за посещения мероприятия и израильского пограничника это полностью устроило.

Именное письмо благодарности от Nordic Semiconductor

Удивило то, что в Израиле не ставят печати в заграничном паспорте. Они по случае выезда просто наклеивают на backward корку паспорта черный 10-значный штрих код на желтом фоне. Затем следовала проверка ручной клади. Мой рюкзак полностью выпотрошили и прощупали какой-то палкой. Видимо это была палка-нюхалка. При этом сотрудник аэропорта, который проверял рюкзак тоже знал русский язык и был очень вежлив. Меня благополучно выпустили из Израиля.

Далее снова рейсы с пересадками и продолжительными ожиданиями в Стамбуле и Анкаре.

Во время полета в РФ из Анкары (столица Турции) нам прямо на борту бортпроводники выдали вот такой лист-опросник и ручки.

Это что-то новенькое. Я его заполнил однако, как выяснилось, зря. В реальности опросник никто не забирал и не проверял.

И вот приземление в Москве аэропорту Внуково. Казалось бы, что все закончилось но нет. Самая утомительная часть поездки это, как оказалось, ожидание паспортного контроля уже на финише на границе с РФ. Там сосредоточилось порядка 1000 человек. В основном это граждане из бывших советских республик, стремящиеся попасть в Россию. Я ждал стоя своей очереди еще около 35 мин.

Сколько стоила поездка в Израиль?

Категория	Значение	Валюта
Аренда комнаты	12772	RUR
Медицинская страховка	500	RUR
Дополнительный Авиабилет	1718	RUR
Такси от дома до аэропорта	858	RUR
сендвич	666	RUR
мороженое	180	RUR
Трансфер от комнаты до аэропорта в Тель-Авив	2160	RUR
Позавтракать в аэропорту Tel-Aviv	1350	RUR
Трансфер от аэропорта до комнаты в Тель-Авав	3060	RUR
Такси от аэропорта до дома	971	RUR
Авиабилеты в с учетом возвращения	34841	RUR
Итого:	59076	RUR

Вывод

Судя по всему в Европе торжествуют культ профессионализма. Спецы разных профессий регулярно устраивают тематические семинары, выставки и встречи. Если говорить про Embedded разработку, то это, например, Embedded Word, Electronica. Плюс каждый вендор чипов (TI, ST, Nordic Semiconductor, NXP) устраивает мастер классы про свои микропроцессоры и ToolChain(ы). Это очень приятно, если учесть, что программисты MK как правило работают в solo режиме и ни с кем не общаться по полгода и более.

Вот вы когда-нибудь видели, чтобы роcсийские электронные fabless компании (Байкал, Ядро, Миландр, ЭЛВИС, НИИЭТ, МЦСТ, Цифровые решения) устраивали бы какие-либо образовательные семинары мастер-классы хотя бы в пределах территории Росcии и при этом еще раздавали гостям отладочные платы с самыми последними своими чипами?

Стоило ли ехать? Перелет, конечно, же весьма утомителен. Шесть рейсов, 4 пересадки и 50 часов в разнообразных аэропортах. Это разумеется не здорово. Фактический ты выпадаешь из работы на трое суток, плюс подготовка 4 дня. Накладные расходы больше чем в мирное время в 3 раза и вообще вся эта затея большой риск.

В целом те кто уже работал с чипами nRF5 больше 2х месяцев едва ли узнал бы на семинаре Nordic Tech Tour что-то уж особенно новое. Однако приятна была сама атмосфера. Можно найти там компаньонов по технологиям. Обменятся бизнес картами (если они есть) и потом коллективно разбираться с тем как работать с ToolChain(ом). Также приятно было получит подарок — отладочную плату. Давно не был в таком приятном коллективе. В перерывах люди общались как с представителями Nordic так и между собой. Видимо там присутствует какая-то негласная культура и западные правила Networking(а) однако как она устроена я слабо себе представляю. Но всё что-то живо обсуждали.

Можно проследить тенденцию, что в современном европейском embedded есть уклон в сторону многоядерности в железе и Open Source(Zephyr RTOS, MCU Boot) решениям в софте.