Русский
Русский
English
Статистика
Реклама

Интерфейсы

Перевод Многократное использование UI-компонентов в масштабах организации

15.06.2020 18:18:41 | Автор: admin
Хотя React и другие библиотеки и фреймворки для веб-разработки упрощают многократное использование компонентов, сама собой такая схема работы не налаживается. В этой сфере всё ещё существуют сложные задачи, которые особенно характерны для тех случаев, когда речь идёт о масштабах крупных организаций. Решение этих задач подразумевает необходимость траты сил и времени на согласование деятельности команд разработчиков, занимающимися в организациях различными проектами. В реальности даже найти нужный программисту компонент, разработанный другой командой, это уже очень непросто.



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

  • Реализация возможности поиска компонентов. Где можно найти компонент?
  • Упрощение процесса предоставления общего доступа к компонентам. Как мне предоставить общий доступ к созданным мной компонентам?
  • Улучшение качества компонентов. Соответствует ли компонент требованиям PayPal (речь идёт о доступности, локализации, производительности, о возможностях по рендерингу компонента в мобильных средах)?
  • Поддержка совместной работы над компонентами. Как наладить совместную работу над пользовательским интерфейсом?

Почему возможность многократного использования компонентов это важно?


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


Поле для ввода денежной суммы

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

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

  • Сокращение времени вывода продуктов на рынок. Компонент просто работает, поэтому разработчики могут сосредоточиться на задачах более высокого уровня. В этом исследовании говорится, что многократное использование компонентов способно сэкономить до 40-81% времени технических специалистов.
  • Увеличение скорости исправления недостатков. Для устранения ошибки в компоненте, который используется в десятках мест проекта, достаточно исправить один общий компонент, а не множество самостоятельных компонентов.
  • Поддержание единообразия интерфейса при реализации различных сценариев работы с проектом.

Почему организация многократного использования компонентов это непросто?


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


Вопросы о компонентах

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

Существующие решения


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

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

Платформа Bit


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

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

Шаблоны компонентов


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

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

Специализированные среды для работы с компонентами


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

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

Наше решение



Обзор решения

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

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

Component Explorer это собственное решение PayPal, применяемое в компании для организации общего доступа к компонентам. Это решение, на высоком уровне, позволяет находить компоненты. Оно отвечает за хостинг компонентов и за их вывод с использованием единообразного интерфейса. Component Explorer использует Storybook и инструмент командной строки component-cli для публикации компонентов. Для автоматизации работы используется GitHub-приложение component-bot. Другими словами, компоненты создают и документируют с помощью Storybook, после чего они автоматически выкладываются в общий доступ с использованием component-cli и component-bot. Более того, автоматически выполняется аудит качества компонентов. Делается это с помощью набора аддонов Storybook, включённых в наш заранее настроенный storybook-preset.

Организация поиска компонентов



Component Explorer

Component Explorer (Cx) содержит в себе все компоненты и служит, в деле поиска компонентов, единым источником достоверных данных. Вот некоторые из его наиболее интересных возможностей:

  • Компоненты интерактивны. Экспериментировать с ними можно, не устанавливая их в свой проект. Работать с Cx, например, исследуя дизайн компонентов, могут и специалисты, программированием не занимающиеся. Например это дизайнеры и продакт-менеджеры.
  • Компоненты документированы. Документация генерируется с помощью аддона Storybook docs. В документацию входят сведения о том, как пользоваться компонентом, о том, какие свойства он принимает, и о том, в каких сценариях он применяется.


Компоненты

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

Упрощение предоставления общего доступа к компонентам


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

  • component-cli это созданный нами инструмент командной строки, предназначенный для развёртывания Storybook и регистрации компонентов в Cx. Это средство собирает метаданные компонента (название, версию, снепшот и так далее) и выдаёт ссылку на развёрнутый компонент.
  • component-bot это GitHub-приложение, которое автоматизирует процесс публикации компонента. Когда открывается PR, оно развёртывает компонент и выдаёт ссылку на страницу предварительного просмотра, пользуясь которой члены команды могут выполнять предварительный просмотр изменений интерфейса в ходе ревью кода. Кроме того, после включения PR в репозиторий, бот автоматически публикует новый компонент в Cx. Благодаря этому документация к компоненту всегда остаётся актуальной.


Ссылка для предварительного просмотра компонента, сгенерированная с помощью component-bot

Совместный доступ к компонентам, представленным в виде npm-пакетов, и к неупакованным компонентам


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

Более того, организация общего доступа к неупакованным компонентам позволяет избавиться от проблемы предварительного проектирования компонентов, о которой мы уже говорили. Это делает возможной особую модель сотрудничества разработчиков. Компонент выкладывается в общий доступ по умолчанию: команде нужно лишь приложить некоторые усилия в том случае, если к ней обратятся члены другой команды, решившие использовать у себя её компонент. Или, что ещё интереснее, благодаря технологии module federation из Webpack 5 можно открывать общий доступ к компонентам напрямую из Cx, не публикуя их в npm.

И наконец, организация общего доступа к неупакованным компонентам применима и к компонентам, которые не планируется использовать многократно. Такие компоненты, например страницы, представленные в виде компонентов, удобно использовать для организации простого и быстрого доступа к каким-то материалам.

Страницы, представленные в виде компонентов



Что такое компонент?

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

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

Сообщество


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

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

Итоги


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

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



Подробнее..

Перевод Обзор технологий скроллинга

04.07.2020 16:09:21 | Автор: admin
Анимации, имеющие отношение к скроллингу веб-страниц, существуют уже многие годы. В последнее время подобные анимации стали распространённее. Возможно, дело тут отчасти в том, что устройства, используемые для работы в интернете, стали мощнее. Эти устройства способны нормально обрабатывать и выводить больше визуальных эффектов, чем раньше.



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

Технологии для реализации специфических механизмов скроллинга


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

CSS-свойство position: sticky


Если вам нужно, чтобы некий элемент не прокручивался бы вместе с остальным содержимым страницы, то при стилизации этого элемента достаточно применить свойство position: sticky. Это простой и понятный приём, его поддержка встроена в современные браузеры. Но для того, чтобы это работало бы в IE и в некоторых мобильных браузерах, понадобится полифилл. Если вам интересна эта тема взгляните на данный материал.


Синий элемент упирается в верхнюю часть контейнера и не прокручивается вместе с остальными элементами

Вот демонстрация такого скроллинга.

Эффект параллакса


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


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

Вот демонстрация эффекта параллакса.

Прокрутка с привязкой к определённым точкам


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


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

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

Плавная прокрутка


Плавный скроллинг поддерживается средствами браузера при прокрутке страницы до определённого раздела с использованием метода window.scrollTo() в JavaScript, или даже с применением CSS-свойства scroll-behavior. В настоящее время для реализации плавного скроллинга со сглаживанием движений колеса мыши требуются специальные JavaScript-библиотеки. Но при применении таких библиотек нужно обеспечить их нормальное взаимодействие с другими технологиями скроллинга. Кроме того, использование плавного скроллинга это далеко не всегда хорошая идея.

Технологии скроллинга общего назначения


В настоящее время нет способа, применяя лишь CSS, запускать какие-либо анимации скроллинга общего назначения, основываясь на позиции прокрутки (хотя имеется предложение, в соответствии с которым в отдалённом будущем в нашем распоряжении могут появиться некие анимации, основанные на технологиях скроллинга общего назначения). В результате, если вы хотите анимировать элементы при скроллинге, вам нужно, как минимум, использовать некоторый объём JavaScript-кода для достижения требуемого эффекта. Существуют два метода применения JavaScript для анимирования элементов при скроллинге. Первый заключается в использовании API Intersection Observer, второй в обработке события scroll.

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


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

Использование события scroll


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

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

Инструменты для создания механизмов скроллинга общего назначения


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

ScrollMagic


Библиотека ScrollMagic даёт нам сравнительно простой API, позволяющий создавать различные эффекты при скроллинге. Эта библиотека может работать совместно с различными библиотеками для анимации, наподобие GSAP и Velocity.js. Правда, в последние несколько лет эта библиотека недостаточно хорошо поддерживается. Это привело к тому, что была создана библиотека ScrollScene.

ScrollScene


ScrollScene это, в сущности, обёртка, которая направлена на то, чтобы повысить удобство работы с библиотекой ScrollMagic и (или) с API IntersectionObserver. Здесь используется собственная версия ScrollMagic, которая отличается лучшей поддержкой, чем обычный вариант библиотеки. Тут имеются и дополнительные возможности, наподобие проигрывания видео и поддержки контрольных точек, влияющих на анимацию. Кроме того, эта библиотека использует GSAP.

ScrollTrigger


Библиотека ScrollTrigger это официальный GreenSock-плагин для GSAP. Эта библиотека отличается большим набором возможностей, её API кажется мне самым простым из API существующих библиотек для скроллинга. Используя эту библиотеку, вы полностью контролируете то, где именно начинается и заканчивается анимация скроллинга, вы можете анимировать при прокрутке всё что угодно (WebGL, canvas, SVG, DOM), можете закреплять элементы на время выполнения анимации. Этим возможности данной библиотеки не ограничиваются. Кроме того, эту библиотеку поддерживает GreenSock, получить помощь по её использованию можно на форумах GreenSock.

Библиотека, достойная упоминания: Locomotive Scroll


Библиотека Locomotive Scroll не стремится к реализации столь же широкого набора возможностей, как другие библиотеки, о которых мы говорили. Её основная цель реализация плавной прокрутки. Используя её, кроме того, можно анимировать некоторые свойства DOM-объектов, используя атрибуты data-*, или пользоваться обработчиком onscroll для анимирования объектов других видов.

Сравнение технологий и инструментов


Вот сравнение технологий скроллинга.

API Intersection Observer Плавная прокрутка Точки привязки в CSS CSS-эффект параллакса CSS-свойство position: sticky
Закрепление элементов - - - - +
Эффект параллакса - - - + -
Управление динамикой анимации - - -
Использование контрольных точек - + - -
Динамическая пакетная обработка элементов + - - - -
Поддержка эффектов горизонтального скроллинга + + + + +
Подходит для продакшна (хорошая браузерная поддержка) +
Полная свобода в анимировании - - - - -
Поддержка разработчиком n/a n/a n/a n/a n/a
Работа с DOM, Canvas, WebGl, SVG + - - - -
Поддержка изменения размеров элементов + + + + +
Ограничивает анимацию только релевантным разделом + + + - +
Различает направления скроллинга - - - -
Технология, встроенная в браузер + + + + +

Вот сравнение рассмотренных библиотек.

ScrollTrigger Locomotive Scroll ScrollScene ScrollMagic
Закрепление элементов + + +
Эффект параллакса + + + +
Управление динамикой анимации +
Использование контрольных точек +
Динамическая пакетная обработка элементов + - + -
Поддержка эффектов горизонтального скроллинга + + + +
Подходит для продакшна (хорошая браузерная поддержка) + + +
Полная свобода в анимировании + + +
Поддержка разработчиком + + + -
Работает с DOM, Canvas, WebGl, SVG + + +
Поддержка изменения размеров элементов + + +
Ограничивает анимацию только релевантным разделом + -
Различает направления скроллинга + + +
Технология, встроенная в браузер - - - -

Итоги


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

Я обычно, для настройки скроллинга, рекомендую использовать библиотеку ScrollTrigger. Она позволяет достичь всего, на что способен чистый CSS, а так же многого другого. Эта библиотека берёт на себя заботу о браузерной поддержке тех или иных технологий, облегчает выполнение вычислений, что позволяет тому, кто её использует, просто заниматься своими делами.

Какие технологии вы используете при настройке скроллинга в своих проектах?

Подробнее..

Из песочницы Как верстать веб-интерфейсы быстро, качественно и интересно

24.06.2020 18:08:11 | Автор: admin

image


Всем привет! Давно хотел и наконец написал небольшую книжку бодрое пособие по своей профессиональной области: актуальным подходам к разметке интерфейсов, экранному дизайну и доступности. Она о моем оригинальном подходе к созданию GUI, препроцессорам CSS (для объективности, немного и об альтернативных подходах), и его эффективном практическом использовании с javascript и популярными реактивными компонентными фреймворками Vue и React. Материал представлен аккуратно последовательно, но безумно интенсивно и динамично ничего лишнего или даже слишком подробного для того чтобы увлеченный и подготовленный читатель не потерял интереса и проглотил на одном дыхании. С другой стороны, текст, достаточно сложный ближе к концу, и на всем протяжении густо насыщенный идеями, ссылками на технологии и подходы поэтому, очевидно, будет на вырост начинающим. Но, в любом случае, как и если вы только начали интересоваться данной тематикой, так и если уже давно занимаетесь веб-дизайном, версткой и программированием фронтенда вам может быть полезно на него взглянуть.


Мотивация


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


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


Реальный жизненный кейс: будучи начинающим специалистом я работал удаленно в одном приятном стартапе. Когда проект запустили, после презентации многие присутствовавшие на ней высказались о том, что кегль основного текста и полей ввода в интерфейсе мелковат. Получив задачу в трекере, я потратил всего пару минут, поправив одну переменную своей системы чтобы поднять кегль на всех нужных полях и контролах, и еще 15 минут чтобы удостовериться что ничего действительно не сломалось ни на одном шаблоне. Ваша система изначально должна быть написана так, и только так, чтобы ее было можно легко скорректировать и улучшить, поддерживать и расширять. По-настоящему лаконичный и выразительный качественный код невероятно мощно экономит время и нервы даже если вы работаете с проектом в одиночку. Кроме того, уважаемые авторитеты в коммерческом программировании утверждают [см. Роберт Мартин Чистая архитектура] что то что сделано изначально плохо в реальности, не только никогда не будет переписано, но и приводит к постоянному крутому росту стоимости дальнейшей доставки нового функционала, а в перспективе способно полностью блокировать прогресс по проекту!


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


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


Кому будет полезен текст?


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


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


Дизайнерам. Вы веб-дизайнер, но хотите начать верстать.


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


Препроцессор


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


Препроцессор, JavaScript и фреймворки


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


Левон Гамбарян.
Июнь 2020 года.



Препроцессор




Простейший пример плохого кода


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


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


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


Давайте посмотрим на самый простейший пример плохого кода на CSS:


/* Примитивнейший пример обычного плохого кода на CSS *//* Где-нибудь в файлах стилей: */.selector--1 {  width: 200px;  height: 200px;  border: 1px solid #ADADAD;  border-radius: 3px;  /* ... и дальше еще огромное количество самых разных правил */}.selector--2 {  width: 200px;  height: 400px;  border: 1px solid #ADADAD;  border-radius: 3px;  /* ... и дальше еще огромное количество самых разных правил */}

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


А как надо?


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


Справедливости ради, нужно упомянуть, что последние годы, в связи с стремительным ростом популярности компонентных js-фреймворков и их подходов, все больше сторонников набирают также различные CSS-in-JS-реализации (например: Styled Components). Скоро, вероятно, можно будет спокойно использовать переменные в самом CSS (CSS Custom Properties). Тема холиварная, существуют контексты и ситуации когда подобный CSS-in-JS подход может оказаться более оправданным и изящным, без сомнения. И даже существует масса реалистичных кейсов когда проще всего будет действительно обойтись несколькими наборами правил на CSS, а любое его расширение будет излишним. Но в общем случае, в реальной коммерческой практике, имхо, для верстки сложных дизайнов и интерфейсов удобнее и эффективнее всего сейчас использовать любой препроцессор, и, шок даже с компонентным фреймворком, дальше я планирую показать как именно это лучше всего делать. Препроцессоры дают максимум возможностей и позволяют стремиться к максимальной выразительности и переиспользуемости. Вот во что превратился бы плохой код выше в SCSS-синтаксисе, наверное самого популярного на сегодняшний день препроцессора Sass:


// В @/src/scss/utils/_variables.scss:$colors__border: #adadad;$border-radius: 3px;// В @/src/scss/utils/_placeholders.scss:%border-block {  border: 1px solid $colors__border;  border-radius: $border-radius;}// В @/src/scss/utils/_mixins.scss:@mixin size($width, $height) {  width: $width;  height: $height;}// В любом месте проекта:.selector {  $selector--1__size: 200px;  $selector--2__width: 200px;  $selector--2__height: 400px;  &--1,  &--2 {    @extend %border-block;    /* ... включение других сущностей препроцессора      и специфическиих правил общих для селекторов */  }  &--1 {    @include size($selector--1__size, $selector--1__size);    /* ... включение других сущностей препроцессора      и специфических правил уникальных для селектора */  }  &--2 {    @include size($selector--2__width, $selector--2__height);    /* ... включение других сущностей препроцессора      и специфических правил уникальных для селектора */  }}

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


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


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


// В @/src/scss/utils/_variables.scss:// Paths$images__path--root: "../../assets/images/";// Sizes $icons__size: 100px;// Views$icons: 20;// В любом месте проекта (в папке В @/src/scss/project/):.icon {  // корректируем путь до картинок  $image-path: $image_path--root + "icons/";  @include size($icons__size, $icons__size); // эта примесь уже создана выше  @for $i from 1 through $icons {    &.icon--#{$i} {      background: url("#{$image-path}icon--#{$i}.svg") center center no-repeat;    }  }}

Пример предполагает что в вашем проекте следующая структура:


. src    assets      images         icon--1.svg         icon--2.svg         ...    sscs       project         ...       utils          _mixins.scss          _variables.scss

Теперь в шаблонах мы можем использовать:


<div class="icon icon--1"></div>

Если вы желаете чтобы картинки были с осмысленными именами можете перебирать список:


.icon {  $image-path: $image_path--root + "icons/";  $images: "name1", "name2", "name3"; // Список имен  @include size($icons__size, $icons__size);  @each $image in $images {    &.icon--#{$image} {      background: url("#{$image-path}#{$image}.svg") center center no-repeat;    }  }}

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


.selector {  $width: 100px;  width: calc(100vw - #{$width});}

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


Абстрагируй все!


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


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


// В @/src/stylus/utils/variables.styl:$colors = {  mint: #44c6a8,  // ... другие конкретные значения цветов}// Создаем "основной цвет", абстрагируясь от конкретного цвета$colors['primary'] = $colors.mint// ... другие "функциональные" цвета

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


.selector  color $colors.primary

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


Структура и стилевая база препроцессора


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


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


Но давайте уже организуем препроцессор, если с SCSS:


. src    sscs       core // обшие и компилируемые сущности препроцессора         _animations.scss // keyframes         _base.scss // минимальная нормализация основных HTML-элементов         _grid.scss // сетки         _typography.scss // типографика         _utilities.scss // быстрые удобные классы-утилиты для включения прямо в разметку       libraries // папка с файлами стилизаций сторонних модулей         _modal.scss - например какая-нибудь готовая модаль       project // стили конкретного проекта         _elements.scss // отдельные простые элементы-компоненты         _fixes.scss // этот файл всегда должен быть практически пустой, и предназначен только для редких общеизвестных "собственных проблем браузеров"         _layout.scss - стили общей для всех страниц GUI-обертки над контентом интерфейса         _widgets.scss - сложные составные комбинации простых элементов-компонентов       utils // обшие и некомпилируемые основные сущности препроцессора         _functions.scss // на практике нужны крайне редко         _mixins.scss // параметризируемые и способные принимать контент примеси-микстуры         _placeholders.scss // повторяющиеся наборы правил - растворы         _variables.scss // самый важный файл с переменными )       _main.scss // точка сборки всех стилей препроцессора       _stylebase.scss // стилевая база

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


// В @/src/scss/_stylebase.scss:// Stylebase////////////////////////////////////////////////////////////////////////////////////////////////////////////// Uncompiled kitchen@import "./utils/_functions";@import "./utils/_variables";@import "./utils/_mixins";@import "./utils/_placeholders";// Core base normal style and common utils@import "./core/_animations";@import "./core/_typography";@import "./core/_base";@import "./core/_grid";@import "./core/_utilities";// В @/src/scss/_main.scss:// Project styles////////////////////////////////////////////////////////////////////////////////////////////////////////////// Stylebase for components@import "_stylebase";// App styles@import "./project/_fixes";@import "./project/_elements";@import "./project/_widgets";@import "./project/_layout";/* External libraries customization */@import "./libraries/_modal";

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


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


    1. функции
    2. переменные
    3. параметризуемые примеси
    4. включения-плейсхолдеры

  2. Компилируемые глобальные стили:


    1. анимации keyframes
    2. типографика
    3. базовая нормализация основных HTML-элементов
    4. сетки
    5. утилитарные классы-помощники для разметки


В папки @/src/scss/project и @/src/scss/libraries вы можете добавлять файлы по необходимости.


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


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



Читать книжку дальше можно пройдя по ссылке: Как верстать веб-интерфейсы быстро, качественно и интересно.

Подробнее..

Минифицируем приватные поля в TypeScript. Доклад Яндекса

13.06.2020 14:36:10 | Автор: admin
Меня зовут Лёша Гусев, я работаю в команде разработки видеоплеера Яндекса. Если вы когда-нибудь смотрели фильмы или трансляции на сервисах Яндекса, то использовали именно наш плеер.

Я сделал небольшую оптимизацию размера бандла минификацию приватных полей. В докладе на Я.Субботнике я рассказал об использовании Babel-плагинов, трансформеров TypeScript и о том, насколько в итоге уменьшился размер продакшен-сборки проекта.


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

С точки зрения структуры наш видеоплеер довольно типичный фронтенд-проект. Мы используем webpack для сборки, Babel для транспиляции кода, скин нашего плеера мы пишем на React, весь код написан на TypeScript.

Мы также активно используем опенсорсные библиотеки, чтобы реализовывать адаптивный видеостриминг. Одна из таких библиотека shaka-player, которая разрабатывается в Google, и нужна она для того, чтобы поддерживать в вебе адаптивный формат MPEG-DASH.

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



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



Кто-то, может быть, использовал плагин webpack-closure-compiler. Здесь на слайде сравнение webpack-closure-compiler с другими инструментами минификации webpack, и, как видно, closure-compiler по этому сравнению лидирует.



Почему он такой классный? Дело в том, что в closure-compiler есть так называемый advanced-уровень оптимизации. На этой страничке он кроется за переключалкой в radio button.

Что из себя представляют advanced-оптимизации и почему они такие классные? Это некоторый набор оптимизаций, которых нет в других инструментах. Рассмотрим некоторые из них.



Closure-compiler умеет инлайнить функции. Здесь он просто заинлайнил тело функции f и удалил объявление самой функции, так как она больше нигде не используется.



Он умеет удалять неиспользуемый код. Здесь объявлен класс A и класс B. По факту используется только один метод из класса A. Класс B был удален совсем. Из класса A method() был заинлайнен, и мы в итоге получили только console.log.



Closure-compiler умеет инлайнить и вычислять значения переменных на этапе сборки.



Еще он умеет минифицировать поля объектов. Здесь объявлен класс A со свойством prop, и после обработки closure-compiler свойство prop заменилось на короткий идентификатор a, за счет чего код стал меньше весить.

Это не все оптимизации. В статье можно подробно почитать, что еще может closure-compiler. Там довольно много чего крутого.

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



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

Почему мне понравилась идея минифицировать приватные поля?



У нас в проекте довольно много React-компонентов, написанных в ООП-стиле с классом. И есть TypeScript-код, в котором используются классы и приватные поля.

Давайте рассмотрим вот такой компонент. В нем есть приватное поле clickCount.



Сейчас при сборке и компиляции кода TypeScript оставляет название этого поля как есть, просто удаляет модификатор private. Было бы клево, если бы clickCount заменился на короткий идентификатор A.

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

И тут можно столкнуться с проблемами. Давайте рассмотрим пример. Объявлен объект с полем foobar. Обратимся к этому полю. Здесь все хорошо. Closure Compiler отработает такой код корректно. Поле foobar будет переименовано.


Ссылка со слайда

Но если мы вдруг зачем-то будем обращаться к этому полю через строковой литерал, то после сборки получим no reference, ошибку в коде. Она связанна с тем, что в поле идентификатор foobar Closure Compiler переименует, а строковые литералы оставит как есть.


Ссылка со слайда

Следующий пример. Здесь мы объявляем метод у объекта, который внутри использует ключевое слово this. После сборки с помощью Closure Compiler и удаления мертвого кода, как видно на слайде, идентификатор this станет глобальным. Вы опять же получите ошибку в коде.

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


Ссылка со слайда

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

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

Но выходит, что advanced-оптимизации в общем случае не безопасны. Их можно сделать безопасными, если вы используете Closure Compiler на полную мощность.



Я немножко слукавил. Closure Compiler не просто минификатор, а целый комбайн. Он заменяет собой webpack, Babel и TypeScript. За счет чего и как ему это удается?


Ссылка со слайда

В Closure Compiler есть своя модульная система goog.provide, goog.require.


Ссылка со слайда

Есть своя транспиляция и вставка полифиллов для различных таргетов, для разных версий ECMASCRIPT.


Ссылка со слайда

Еще там есть свои аннотации типов. Только описываются они не как в TypeScript, а в JSDoc. Точно так же там можно пометить, например, модификаторы доступа public, private и подобные.



Если сравнивать микросистему webpack-Babel-TypeScript с Closure Compiler, то, на мой вкус, Closure Compiler проигрывает. У него чуть хуже документация, им умеют пользоваться меньше разработчиков. В целом не самый удобный инструмент.

Но я все-таки хочу оптимизации. Может, можно как-то взять Closure Compiler, взять TypeScript и объединить их?



Такое решение есть. Называется оно tsickle.


Ссылка со слайда

Это проект, который разрабатывается в Angular и занимается тем, что компилирует TypeScript-код в JS-код с аннотациями Closure Compiler.


Ссылка со слайда

Есть даже webpack loader, tsickle-loader называется, который внутри использует tsickle и заменяет собой tsickle loader. То есть он подгружает TypeScript-код в webpack и эмитит JavaScript с аннотациями. После чего можно запустить Closure Compiler как минификатор.



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

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



Какие еще есть варианты? В TypeScript есть issue про предложение о минификации. Там идет обсуждение похожей реализации на Closure Compiler: оптимизировать код, используя знания о типах. Проблема в том, что этот issue открыт 15 июля 2014 года, там до сих пор ничего не происходит. Вернее, там происходит 145 комментариев, но результатов пока нет. Судя по всему, команда TypeScript не считает, что компилятор TypeScript должен заниматься минификацией. Это задача других инструментов.

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



Не так давно в Babel появилась поддержка TypeScript. Существует babel/preset-ypescript, который добавляет в Babel возможность парсить TypeScript-код и эмитить JavaScript. Он делает это путем удаления всех TypeScript-модификаторов.



Мы, кстати, не так давно перешли с ts-TS loader на Babel с использованием babel/preset-typescript и этим сильно ускорили сборку. Наконец-то настроили конкатенацию модулей в webpack, сделали еще некоторые оптимизации и настроили разные сборки под ES5- и ES6-браузеры. Про это можно узнать подробнее из доклада моего коллеги.

Окей, давайте попробуем написать babel-plugin, который будет минифицировать приватные поля, раз Babel умеет работать с TypeScript.


Ссылка со слайда

Как Babel работает? На эту тему есть много хороших материалов, статей и докладов. Можно начать, например, с этого материала на Хабре. Я лишь бегло расскажу, как происходит процесс обработки кода через Babel.

Итак, Babel, как и любой транспойлер кода, сначала парсит его и строит абстрактное синтаксическое дерево, abstract syntax tree, AST. Это некоторое дерево, которое описывает код.



Давайте попробуем на коротком кусочке кода посмотреть, как строится AST. Наша маленькая программа состоит из двух выражений. Первое выражение это Variable Declaration, объявление перемены. Из чего оно состоит? Из оператора VAR на схеме это Variable Declarator. У оператора есть два операнда идентификатор A, мы создаем переменную A, и Numeric Literal, мы присваиваем им значение 3.

Второе выражение в программе это Expression Statement, просто выражение. Оно состоит из бинарного выражения, то есть операции, у которой есть два аргумента. Это выражение +, первый аргумент a, второй 5, числовой литерал. Примерно так строятся абстрактные статические деревья.



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

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


Ссылка со слайда

Когда мы построили AST, мы его трансформируем. Трансформация это превращение одного AST в новое, измененное. Как происходит трансформация? Это тот самый процесс, который вы описываете с помощью настроек Babel в файлике .babelrc или где-то еще.

Вы задаете список плагинов, которые вы трансформируете в ваше AST дерево.



Что такое плагин? Это просто функция, которая имплементирует паттерн Visitor. Babel обходит AST в глубину, в том порядке, как указано на схеме на слайде. Babel вызывает функцию вашего плагина, который возвращает объект с некоторыми методами.

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

Подробно об этом можно узнать из документации Babel и воспользоваться AST Explorer, чтобы понять, какие операции в коде каким узлам в AST- дереве соответствуют.


Ссылка со слайда

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

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

Как будет работать наш плагин? Давайте возьмем какой-нибудь класс, в котором есть приватное поле. Наш плагин Visitor будет заходить во все узлы AST-дерева, соответствующего классу, и в MemberExpression. Это узел, соответствующий операции доступа к полю в объекте.


Ссылка со слайда

Если объект, к которому мы обращаемся, this, то надо проверить, является ли поле приватным.


Ссылка со слайда

Для этого нужно подняться вверх по AST-дереву и найти декларацию этого поля. Тут нам повезло: она имеет модификатор private, значит, можно переименовать это поле.


Ссылка со слайда

Магия! Все работает, классно. Плагин готов.

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


Ссылка со слайда

Рассмотрим пример. Тут мы добавили в наш класс еще один метод, внутри которого обращаемся к приватному полю не this, а другого инстанса этого класса. Это валидный код, мы обращаемся к приватному полю внутри класса, здесь все ок.

Но мой плагин при обработке этого кода делал вот такое. Почему так происходило? Потому что я сделал так, что мы ищем доступы к объекту this. Если же мы обращаемся к другому объекту, эти узлы AST-дерева мы не рассматриваем.

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

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


Ссылка со слайда

Рассмотрим еще один пример. Здесь мы this присваиваем переменную и обращаемся к полю bar из этой переменной. Это тоже валидный код. Но в итоге я получал такое. Здесь тоже нужен костыль, который будет разбирать такие обращения, искать, что this foo на самом деле this, что у него тип foo. И в этом случае bar нужно точно так же переименовать.

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

Я расстроился и уже было похоронил эту идею.



Но потом я вернулся в тот долгий тред про минификацию в TypeScript и увидел там комментарий Евгения Тимохова.



Он писал, что реализовал TypeScript в трансформер, который занимается минификацией приватных полей. И этот трансформер вроде бы даже работает.



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



Чтобы потом минифицировать такие поля, он предлагает использовать uglifyJS или terser, то есть uglifyJS с поддержкой ES6, и настроить минификацию полей, название которых соответствует регулярным выражениям.

Почему трансформер Евгения работает, а подход, который выбрал я, ни к чему не привел?


Ссылка со слайда

Тут нам потребуется немножко поговорить о том, как работает TypeScript. TypeScript это ведь тоже транспойлер. Он занимается тем, что берет TypeScript-код и парсит его. Но вместе с парсингом TypeScript еще запускает Type Checker. И при построении AST-дерева TypeScript обогащает его информацией о типах идентификаторов. Это как раз та самая информация, которой мне не хватало в моем Babel-плагине.

Дальше компилятор TypeScript может трансформировать AST-дерево точно так же, как Babel. Построить новое AST-дерево и эмитить из него JavaScript-код.

На этапе трансформации можно подключить кастомный трансформер. Это точно такой же плагин, точно такая же сущность, как плагин Babel, только для TypeScript. Она использует такой же паттерн Visitor и реализует примерно те же идеи.

Как это все использовать? Проблема в том, что в CLI компилятора TypeScript нет возможности подключать кастомные трансформации. Если вы хотите такое делать, вам потребуется пакет ttypescript.


Ссылка со слайда

Это не опечатка, а обертка над компилятором TypeScript, которая позволяет в настройках компилятора в tsconfig указать возможность использовать кастомную трансформацию. Здесь кастомная трансформация будет просто браться из node_modules.


Ссылка со слайда

Такая фича есть и в ts-loader. Там тоже можно задать функцию getCustomTransformers, которая позволит вам применить кастомный трансформер на этапе сборки.



Когда я решил попробовать этот подход, то столкнулся с проблемой. У нас-то в проекте используется Babel и babel/preset-typescript. Как вы помните из рассказа, мы на него переехали из ts-loader и получили кучу профита, сделали кучу оптимизаций. Откатываться обратно и терять все это мне не хотелось.

Окей, будем делать свой велосипед еще раз. Как выглядит сейчас пайплайн сборки в моем проекте? Мы подгружаем TypeScript-код в Babel loader и эмитим из него JS. Тут мне нужна сущность, которая перед Babel позволит запускать TypeScript-трансформер.

В Babel этого сделать нельзя, потому что он не запускает компилятор TypeScript. Как я говорил, он просто вырезает модификаторы TypeScript из кода.


Ссылка со слайда

Идею такой сущности я подсмотрел в проекте react-docgen-typescript-loader. Это такой loader для webpack, который пригодится, если вы используете Storybook. Storybook инструмент, который позволяет строить визуальные гайды и документацию к вашим React-компонентам.



Чем занимается этот loader? Он подгружает TypeScript-код, обрабатывает его и эмитит TypeScript-код с дополнительными полями у React-компонентов. Поля называются docgenInfo, и в них содержится информация для Storybook, чтобы построить документацию к React-компоненту, используя не propTypes, а аннотации TypeScript.

Потом этот код, заэмиченный в react-docgen-typescript-loader, как-то обрабатывается. Например, с помощью TS loader и Babel. В итоге, когда он попадает в Storybook, тот успешно строит документацию по полям docgenInfo.

Мне нужна похожая штука. Мне нужен webpack loader. Как это сделать?


Ссылка со слайда

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

Здесь на слайде очень глупый loader, который занимается тем, что все ваши файлы превращает в код, содержащий console.log(Hello World!).


Ссылка со слайда

Loader может быть и синхронный. Можно получить callback, сделать асинхронную операцию. Вернее, что-то прочитать с диска или сделать что-то подобное и вызвать callback с новым модифицированным source.



Какой пайплайн должен быть у меня? Мне нужен loader, который подгружает TypeScript, запускает на нем кастомный трансформер. Я хочу применить трансформер, который минифицирует приватные поля и эмитит TypeScript.

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

Окей, мы разобрались, как писать loader. Функция, которая обрабатывает source. Теперь нужно понять, как применить на наш файл кастомную TypeScript-трансформацию.


Ссылка со слайда

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

Примерно как это работает? Сначала нужно получить TS program, это объект, который содержит коллекцию файлов и настройки компилятора TypeScript. Нам нужно распарсить исходный файл и получить для него AST. Потом мы трансформируем это дерево и подключаем здесь myCustomTransformer, нашу кастомную трансформацию. И получаем в переменной result новое AST. Дальше мы его можем сериализовать обратно в TypeScript-код. Этим занимается компонент printer.

Кажется, ничего не мешает использовать это в webpack loader. Единственная проблема: документация по Transformation API не очень хорошая. И вообще, документация по внутренним сущностям компилятора в TypeScript сильно проигрывает аналогичной документации Babel. Но если вы захотите окунуться в это, начать можно с пул-реквеста в репозитории в TypeScript, где Transformation API сделали публичной.



Итак, что в итоге делает мой loader? Подгружает TypeScript-код и с помощью TypeScript Transformation API применяет на него кастомную трансформацию. Эмитит уже модифицированный TypeScript-код обратно. Дальше я скармливаю его Babel, который эмитит JavaScript.

Итоговую реализацию loader я выложил в npm, можно посмотреть исходный код на GitHub и даже подключить и использовать в вашем проекте:

npm install -D ts-transformer-loader

Всю эту прекрасную конструкцию мы даже покатили в продакшен.



Какой профит дала вся эта возня? Сырой непожатый код нашего бандла уменьшился на 31 килобайт, это почти 5%. Результаты в gzip и brotli не такие классные, потому что код и повторяющиеся идентификаторы там и так хорошо сжимаются. Но выигрыш порядка 2%.

Уменьшение непожатого кода на 5% не очень крутой выигрыш. Но 2% в минифицированном коде, который вы гоняете по сети, можно даже заметить на мониторингах.

Вот ссылка на мои заметки. Спасибо.
Подробнее..

Минимизация кликов и горячие клавиши для жизни разработчика Темнее Тёмной Темноты

02.07.2020 08:05:44 | Автор: admin
Хороший разработчик/аналитик/просто пользователь ПК стремится к оптимизации любого процесса. Будь то хоть включение чайника на кухне, пока снимаешь куртку зимой, а также к улучшению и модернизации рабочего места или ПО.
Медленный компьютер, тормозящие приложения, узкое использование инструментов с огромнейшими возможностями всё это демотивирует.
Попробуем расширить кругозор и оптимизировать каждый клик.



В статье разобраны 5 IDE, 2 приложения для работы с БД, 2 ОС, 2 браузера и 2 SSH программы и хранитель паролей.



Навигация
PhpStorm 2020.1.2
Notepad++ v7.8.7
Apache Netbeans 12
Sublime Text 3
Visual Studio Code 1.46.1
Redmine
Atlassian (Trello, Bitbucket, SourceTree 3.3.9, Jira, Confluence)
Windows 10
Linux
Google Chrome 83.0
Mozilla (Firefox 78.0b9, Thunderbird 68.9.0)
PL SQL Developer 13
DBeaver 7.1.0
Keepass 2.45
WinSCP 5.17.6
Putty 0.73
Прокачиваем мобильник

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

Вот основные подпункты:
  • Описание. Основное, что делает программа либо выжимка с Википедии
  • Горячие клавиши Совокупность клавиш, при одновременном нажатии которых происходит запрограммированное действие
  • Главное меню Оптимизация рабочего пространства
  • Выравнивание/Табуляция Автоформатирование отступов
  • Шаблоны кода Заранее написанные блоки кода, вызываемые по аббревиатурам и запрограммированной клавише, обычно Tab
  • Ссылки Ссылки на официальный сайт, сайт откуда можно скачать, описание в Википедии, мобильная версия если такая есть, а также просто полезные ссылки, допустим на статьи о приложении


ТТТ
Отдельно хочу выделить подпункт, который я везде называю ТТТ Темнее Тёмной Темноты.
Окрашивание в тёмный цвет всего, что можно + полезные ссылки, в основном на тёмные
темы с userstyles.org (почему-то прямая ссылка даёт иногда 504 ошибку, а ссылки на темы работают нормально), предварительно поставив плагин Stylus в Chrome или в Mozilla
Общие примеры:
Глобальные темы для браузеров:
darkreader
global-dark
ВК
Google Script
скрин



IDE


PhpStorm 2020.1.2




ТТТ
File Settings Editor Color Scheme Material Darker

Выравнивание/Табуляция
  • Code Reformat Code или CTRL+ALT+L
  • File Settings Editor Code Style


Горячие клавиши

Главное меню
File Settings Menus and Toolbars

Шаблоны кода
File Settings Editor Live Templates

Тестирование REST запросов внутри программы
Очень удобно если важна не визуальная составляющая ответа, внутрянка.
Tools HTTP Client Test RESTful Web Service


БД
View Tool Windows Database



SSH
Tools Deployment Browse Remote Host

GIT
  • Если установлен гит, то правой кнопкой мыши в любом файле GIT
  • VCS Git
  • В нижней панели Version Control


Экспорт настроек


Командная строка
Снизу вкладка Terminal

Тайм-трекинг
File Settings Tools Tasks Servers




Notepad++ v7.8.7



Плагины
Плагины Управление плагинами. Есть полезные:
  • XML Tools
  • QuickText (Это шаблоны кода)
  • Snippets
  • Customize Toolbar (Это настройка главного меню)
  • Compare (Diff)


Выравнивание/Табуляция
Опции Настройки Синтаксисы

Горячие клавиши
Опции Сочетание клавиш

ТТТ
Опции Определение стилей




Apache Netbeans 12




Горячие клавиши
Tools Options Keymap

Выравнивание/Табуляция
Tools Options Editor Formatting

Шаблоны кода
Tools Options Editor Code Templates (бонусом выставление курсора)

Главное меню
Tools Options Appearance Document Tabs, а также в вкладке Window

Командная строка
Window IDE Tools Terminal

ТТТ






Sublime Text 3




ТТТ
  • Preferences Color Scheme Monokai
  • Preferences Theme


Горячие клавиши
Preferences Key Bindings

Шаблоны кода
Tools Snippets




Visual Studio Code 1.46.1




Горячие клавиши
File Preferences Keyboard Shortcuts

Консоль
Terminal New terminal

Расширешия
View Extensions

Репозиторий
View SCM


Ссылки



Аналитика


Redmine


новый




ТТТ
При создании нового проекта есть выбор светлой или тёмной темы.


старый


ТТТ
Не забываем подправлять URL если он у нас домашний



Шаблоны
Скачиваем и устанавливаем Redmine.
Создаём, что надо, проекты и т.д.
Допустим нам надо заполнить по шаблону поля при создании новой задачи.
Для этого нам опять помогут UserScript`ы.
Устанавливаем TamperMonkey по аналогии с статьёй habr.com/ru/post/504664 (пункт Юзерскрипты в браузере), вставляем
код
// ==UserScript==// @name         redmineTemplate// @namespace    http://127.0.0.1/redmine*// @version      0.1// @author       You// @match        http://127.0.0.1/redmine*// ==/UserScript==var d = document.createElement('span');document.querySelector('#issue_tracker_id').parentNode.appendChild(d);d.style['color'] = 'red';d.style.width = '100px';d.style.cursor = 'pointer';d.style.paddingLeft = '30px';d.textContent = 'Шаблон'; d.addEventListener('click', function () {   //Трекер   $('#issue_tracker_id :contains(\'Поддержка\')').attr('selected', 'selected');   // Описание   $('#issue_description').val('Полное описание. \nПример:...');   // Срок завершения   $('#issue_due_date').attr('value',$('#issue_start_date').attr('value'));   // Готовность   $('#issue_done_ratio :contains(\'30 %\')').attr('selected', 'selected'); });



Появляется кнопка, жмём, автозаполняются поля теми значениями, которые мы указали.


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




Atlassian


У Atlassian есть хаб в хабре, некоторые статьи будут из него

Confluence








Trello




Горячие клавиши

Шаблоны



Bitbucket







SourceTree 3.3.9




ТТТ
Инструменты Настройки Общее Theme

Шаблоны кода
Инструменты Настройки Пользовательские действия

Горячие клавиши
Подсвечены в главном меню у каждого пункта



Jira




Шаблоны кода
Через TamperMonkey по аналогии с старым редмайном (выше)
document.querySelector('#summary').value = 'Новая тема'







ОС


Windows 10




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


ТТТ


Пуск Параметры Персонализация Цвета Тёмный.
Как изменить цвет выделения в Windows 10
Как изменить цвет окон Windows 10

Ускорение


Оптимизация действий
  • Автозагрузка нынче перенеслась из WIN+R msconfig в Диспетчер задач (CTRL+SHIFT+ESC либо переходим в Пуск Параметры Приложения Автозагрузка).
  • Скрипт настройки Windows 10


Отключаем ненужные приложения
Если мы хотим, чтоб при запуске Windows сразу открывались нужные нам приложения, добавляем их в папку автозагрузки.
Обычно она по адресу C:\Users\ВАШ_ПОЛЬЗОВАТЕЛЬ\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, либо можно так: WIN+R Вводим shell:startup, в папку вставляем приложения (лучше ярлыки)
Добавить приложение для автоматического запуска при начальной загрузке Windows 10
Отключить подтверждение перед установкой приложений (UAC контроль учётных записей). Жмём лупу справа от Пуска, вводим UAC, жмём Изменение параметров контроля учётных записей, бегунок вниз.

Внешний вид
Приводим рабочий стол в порядок, удаляем лишнее, переносим ярлыки, чтоб все были под рукой. Тоже самое делаем и с папками, сколько бы временных затрат это ни стоило. Упорядоченные папки, без шуток, экономят массу времени (но я до сих пор не могу разобрать злосчастную папку На потом).
Если вам мало места или вы ведёте двойную/тройную жизнь, допустим дизайнер и БДшник, используйте несколько рабочих столов



Linux




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




Браузеры


Google Chrome 83.0




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




Mozilla


Firefox Developer 78.0b9


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


Ссылки



Thunderbird 68.9.0


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

ТТТ
Инструменты Дополнения Темы Dark




Database


PL SQL Developer 13




Шаблоны кода
Они чуть другие, чем обычные шорткаты. Вставляются либо двойным кликом либо перетаскиванием в рабочее окно.
Вид Список шаблонов





DBeaver 7.1.0




ТТТ
  • Окна Настройки Общие Внешний вид Dark
  • Окна Настройки Общие Внешний вид Цвета и шрифты


Горячие клавиши
Окна Настройки Общие Клавиши

Выравнивание/Табуляция
  • Окна Настройки Общие Текстовые редакторы
  • Окна Настройки DBeaver Редакторы Редактор SQL Форматирование


Шаблоны кода
Окна Настройки DBeaver Редакторы Редактор SQL Templates

Диаграммы связей
Собственно из-за чего я и оставил DBeaver. Жмём на таблицу с CTRL, выбираем вкладку Диаграмма и видим все соединения с выбранной таблицей.




Храним пароли


Keepass 2.45




Храним пароли в одном месте.



FTP + SSH


WinSCP 5.17.6




Чтоб меняться подключениями между рабочими местами, пользуемся выгрузкой Инструменты Экспорт настроек
ТТТ
Внешний вид Интерфейс Theme Dark

Горячие клавиши
В главном меню Команды





Putty 0.73




Обмен подключениями между рабочими местами нашёл пока только такой способ через реестр Computer\HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions
ТТТ
Window Colours




Прокачиваем мобильник


Уделяем внимание папкам и объединению приложений. Лишний клик забывается, как только привыкаешь и запоминаешь, где что.
Если у вас уже настроена почта по папкам, то с мобильного телефона удобней смотреть уже сортированное. То есть настраиваем на компьютере, пользуемся на компьютере и на мобильном.
Боты в телеграм. Скептически к ним относился, пока пару штук не сделал и не понял всех возможностей. Склеивать их с различными Google-сервисами можно на ура, главное придумать, как оптимизировать время, создав или найдя уже существующего полезного бота.
Календарь. Тут всё просто. Используем его везде.
Чеклист допустим TickTick
Список дел, допустим Простой список дел или Задачи: Список задач. Нужны, чтоб не держать всё в голове и если не нравится календарь.

Итог


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

Полезные ссылки, которые также могут пригодится


Tabsbook
www.tabsbook.ru Пока для меня самый удобный менеджер закладок, работающий как в Chrome, так и в Mozilla. Если есть инструмент, объединяющий закладки кроссбраузерно, буду признателен поделившимся.


Adminer
www.adminer.org очень хорошая альтернатива www.phpmyadmin.net, умещается в один файл php.


Heroku
www.heroku.com облачная PaaS-платформа

Miro
Miro (до 2019 года RealtimeBoard) платформа для совместной работы распределенных команд (в том числе при дистанционной работе отдельных сотрудников), разработанная в России и вышедшая на международный рынок.
Официальный сайт
Википедия
Андроид

Airtable
Airtable представляет собой гибрид базы данных и электронной таблицы.
Официальный сайт
Википедия
Андроид

AWD - Android Web Developer
AWD PHP/HTML/CSS/JS IDE Android Web Developer (AWD) это IDE (интегрированная среда разработки) для веб разработчиков. Поддерживаются следующие языки и форматы: PHP, CSS, JS, HTML, JSON
Подробнее..

Автоматизация тестирования на максималках. Доклад Яндекса

27.06.2020 12:11:16 | Автор: admin
Это снова Владимир Гриненко, тимлид в поисковом портале Яндекса. Я решил рассказать, как у нас устроено тестирование интерфейсов: о формате описания сценариев, способах их актуализации, о нашем собственном опенсорсном проекте и тестировании силами внешних тестировщиков. А ещё пофантазировал о неожиданных способах применения этой системы.


Сергей Бережной veged уже несколько раз поднимал эту тему и рассказывал про тестирование в Поиске. Вот ссылки на доклады в 2016-м и 2017-м. Многое из того, что он тогда рассказывал, де-факто стало стандартом для большинства компаний. Но несмотря на это, все еще остаются вещи, которые пока нигде особо не применяются. Именно на них я и сосредоточусь.

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



Если ввести запрос [коронавирус карта России], помимо привычных результатов поиска мы увидим сверху такую большую красивую карту.

Давайте проследим, как выглядит flow разработки такой фичи.

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



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



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



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



Заглядываем внутрь. Здесь тоже все хорошо. Здесь мы проверяем, что JS-функциональность в порядке.



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

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



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



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



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



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

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



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



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

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

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

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

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

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

Наверняка многие догадались, что для этого нам потребуется Test Management System. У нас есть свое решение, оно называется TestPalm.



Что в ней видно? У нас есть список проектов.



Открываем проект интерфейсов Поиска.



Находим все тест-кейсы, которые затрагивают тот самый колдунщик коронавируса, и смотрим на конкретный кейс.



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



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

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

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

Делается это просто. Нам всего лишь нужно хранить все эти тесты рядом с кодом. Окей, в случае с тестами всё очевидно и все так делают. Что же делать с тест-кейсами, которые должны храниться в отдельной системе? Ровно то же самое. Выглядит это примерно так.



Вот папка с колдунщиком карты коронавируса. Здесь есть папка CovidMap.test.



Внизу лежит куча файлов. Нас в первую очередь интересует файлик под названием testpalm.yml.



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

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



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

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

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

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

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



Файлы, на которые мы ссылались из testpalm.yml, находятся здесь же, рядом. Это Hermione.e2e.js с e2e-тестами.



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



И точно так же мы храним рядом функциональные тесты на замоканных данных.



Здесь, помимо самого факта открытия колдунщика, мы можем сделать и проверку скриншота.

Хорошо. Теперь давайте вернемся к самому сложному вопросу. Как же все-таки вручную протестировать гигантский проект во всех окружениях и успевать делать полные регрессы каждый день. Если вы еще не догадались, ответ прост.

Нужно нанять очень много тестировщиков! Пара-пара-пам.



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

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

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

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

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

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



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

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

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

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

Помимо проверки тест-кейсов эту же схему можно применить и для других видов задач.

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

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

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



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

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



Я подготовил этот доклад для последнего Я.Субботника. Следующий Я.Субботник по разработке интерфейсов пройдёт 4 июля, и там я тоже выступаю.
Подробнее..

API портал на что обратить внимание при дизайне. Опыт Wrike

16.06.2020 18:07:02 | Автор: admin


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

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

В ходе редизайна нам удалось:

  1. Создать интуитивно понятную навигацию.
  2. Создать сетку для оптимального отображения контента на десктоп и мобильных устройствах.
  3. Обновить дизайн портала в соответствии с текущей дизайн-системой и создать недостающие компоненты.
  4. Соблюсти требования доступности уровня АА и внедрить тематизацию.


1. Интуитивно понятная навигация


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

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


Навигация на предыдущей версии портала

Чтобы оптимизировать структуру портала, мы выделили основные разделы и подразделы, а также отделили технический контент от информационного. Так, в новом портале мы выделили 5 основных разделов: Introduction, API Documentation, API Reference, BI Export и Support, а раздел API Community закрепили отдельной ссылкой в нижней части боковой панели, чтобы пользователь мог при необходимости быстро обратиться за помощью.

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



Обновление навигации на портале (было стало)

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


Навигация на новом портале

2. Сетка для оптимального отображения контента


Dev-портал Wrike состоит в основном из статичных страниц с разнообразным контентом. Таблицы и текстовые блоки занимают всю ширину сетки, поэтому количество колонок не имеет значения.

Мы уделили особое внимание странице с методами. Построить эту страницу можно двумя способами:

  1. Поделить контентную часть на два блока: слева описание и таблицы, справа примеры.
  2. Сделать единый блок с контентом: примеры внутри каждого метода.

На предыдущей версии портала использовался первый способ.


Страница метода на предыдущей версии портала: описание и запрос слева, а слайдер с ответом и примерами справа

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


Страница метода на новом портале

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

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

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



Принцип работы сетки на новом портале

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

3. Обновление дизайна портала в соответствии с текущей дизайн-системой и создание недостающих компонентов


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

HTTP методы


HTTP методы (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH) одна из важнейших сущностей API. В зависимости от вида действия сущность имеет определённый HTTP метод. При дизайне HTTP методов старайтесь следовать следующим рекомендациям.

  1. Присвойте каждому из 9 существующих HTTP методов цветовой идентификатор, чтобы визуально можно было отличать их, не заставляя пользователя долго фокусироваться.
  2. Для большего удобства добавьте в компонент HTTP метода URL, чтобы упростить жизнь разработчикам: им не нужно будет совершать дополнительные действия для просмотра этой информации.
  3. Предоставьте возможность видеть запрос и пример одновременно. В новой версии API портала Wrike примеры размещены внутри метода, а не спрятаны в слайдер, как это было ранее.
  4. Не располагайте на отдельных страницах методы, которые относятся к одной сущности: в старой версии Query Tasks, Create Task, Modify Task отдельные страницы. Вместо этого разделите страницы по сущностям: Contacts, Users, Tasks и т.д. Это также упростит взаимодействие с порталом.


HTTP методы на новом портале

Таблицы


Все запросы, отправляемые на сервер, представлены в виде таблиц с большим объемом данных.

Таблица на предыдущей версии портала

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


Таблица на новом портале

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


Вложенность на предыдущей версии портала

На новом портале шеврон относится к самому параметру и помогает пользователю понять, что внутри спрятан контент.

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

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


Вложенность на новом портале

Примеры


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

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

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

Примеры на новом портале

4. Соблюдение требований доступности и тематизация


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

Контрастность обычного текста, заголовков и графических элементов соответствуют стандартам WCAG.

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

К каждому графическому объекту есть описание. Так, для кнопок копирования информации в буфер, рядом с иконкой расположен текст Copy, при нажатии на кнопку текст меняется на Copied CURL example.

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

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

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



Тематизация на dev-портале Wrike

Подводя итог


Для создания удобного интерфейса dev-портала необходимо:

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

Посмотреть, как получилось у нас, можно на dev-портале Wrike.

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

Sign in with Apple дедлайн уже 30 июня

17.06.2020 10:12:43 | Автор: admin

Как мы уже писали в прошлой статье, к 30 июня 2020 все новые аппстор приложения и апдейты должны поддерживать функцию Sign in with Apple.



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


Все надо делать по ГОСТу


Гайдлайны по дизайну кнопок от эппла нельзя нарушать ни в коем случае. Но не факт, что вы узнаете об этом сразу. Сначала мы отправили на ревью билд вот с такой кнопкой для Sign in with Apple.



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


Your app uses Sign in with Apple as a login option but does not use the appropriate Sign in with Apple button design, branding, and/or user interface elements as described in the Sign in With Apple Human Interface Guidelines. Specifically:
-The Sign in with Apple says Apple but should use the following version: Sign in with Apple.
-The custom Sign in with Apple button in your app does not follow Apple button design, branding and/or user interface elements.
Next Steps
To resolve this issue, revise the Sign in with Apple button design, branding and/or user interface elements in your app so that it follows all the Sign in With Apple Human Interface Guidelines.

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



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


Приватные имейл адреса


При логине с айфончика, пользователь может выбрать опцию Hide my email. В этом случае вы получите его прокси имейл, созданный эпплом вида random_chars@privaterelay.appleid.com. Документация утверждает, что по умолчанию на такие адреса нельзя ничего отправить, не сделав дополнительных телодвижений.


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


Но на деле все оказалось несколько иначе:


  • Мне удавалось отправить письмо с личного ящика на прокси имейл, хотя домен моей почты не был прописан в эппловской админке.
  • Некоторые прокси имейлы переставали получать нашу рассылку с ошибкой reason: 550 5.1.1 Relay not allowed; type: bounce. При отправке с личной почты, приходило уведомление Undeliverable. XXX was not found on privaterelay.appleid.com

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


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


Люди не хотят аутентифицироваться каждый раз


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


User interaction is required any time a new identity token is requested. User sessions are long-lived on device, so calling for a new identity token on every launch, or more frequently than once a day, can result in your request failing due to throttling.

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


Вместо вывода


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


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


Если вы нашли еще какие-то интересные особенности Sign in with Apple добро пожаловать в комментарии!


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


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

Подробнее..

Дайджест продуктового дизайна, май 2020 (100)

18.06.2020 18:21:58 | Автор: admin
Дайджест собирает свежие статьи по дизайну интерфейсов, а также инструменты, паттерны, кейсы, тренды и исторические рассказы с 2009 года. Я тщательно фильтрую большой поток подписок, чтобы вы могли прокачать свои профессиональные навыки и лучше решить рабочие задачи. Предыдущие выпуски: апрель 2010-апрель 2020.

Дайджест продуктового дизайна, май 2020


Кстати, это сотый выпуск! Около 10 000 ссылок за 10 лет. Предыстория и благодарности всем, кто помогал в разные периоды. Сейчас его суммарно читают порядка 250 000 человек на разных площадках:

Паттерны и лучшие практики


Online Shopping for Food and Groceries During Covid-19

Raluca Budiu из Nielsen/Norman Group разбирает проблемы интернет-магазинов с доставкой продуктов, которые вскрылись во время карантина и нереального спроса. Как учитывать такие пограничные ситуации.



A case study of complex table design

Годный кейс о редизайне сложной таблицы с интересным взаимодействием.



How Search Engines Shape Gaze Patterns During Information Seeking

Feifei Liu из Nielsen/Norman Group анализирует интерфейсы поисковой выдачи от Google и Baidu. Как они устроены и как это влияет на поведение пользователей.

Paul Boag Click! Encourage Clicks Without Shady Tricks

Smashing Magazine выпустили книгу Paul Boag Click! о лучших паттернах и практиках для повышения конверсии и других бизнес-метрик. Выдержка из главы о тёмных паттернах.

Form design Multiple inputs versus one input

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


What the challenger banks did differently Opening an account

Peter Ramsey разбирает интерфейсы британских банковских приложений. В первой части он смотрит на сложность открытия счёта, во второй первый платёж, в третьей приостановка счёта.



Text fields & Forms design UI components series

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

Thinking About The In-between Design Cases

Ahman Shadeed размышляет на тему поддержки промежуточных состояний адаптивности, которые лежат между популярными точками разрыва.



Nice! UI Components & UX Patterns Examples

И снова новая коллекция интерфейсных паттернов.



Inspired Design Decisions With Max Huber Turning Mundane Subjects Into Exciting Visual Communication

Andy Clarke продолжает серию экспериментов с интересной журнальной вёрсткой в вебе. В девятом выпуске разбирает работы Max Huber.



7 ошибок проектирования интерфейса электронного терминала

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



Case Study of Facial-Recognition Payment in China

Feifei Liu из Nielsen/Norman Group анализирует китайские сервисы для оплаты по лицу в магазинах и кафе. Это пока ещё непривычное решение и оно вызывает много вопросов у пользователей.



Luke Wroblewski Mobile First

Книга Luke Wroblewski Mobile First теперь доступна бесплатно в онлайне.



COVID-19 Content on Your Intranet

Kara Pernice из Nielsen/Norman Group описывает лучшие практики по представлению информации в интранетах компаний о ситуации с пандемией и удалённой работе в целом. Советы по информационной архитектуре.



Дизайн-системы и гайдлайны


Useful Sections for a Design System Reference Site

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



Microsoft Fluent Design

19-21 мая прошла ежегодная конференция Microsoft Build 2020. Как и вся жизнь в этом году, в онлайне.



Большинство выступлений посвящено разработке, но дизайн-команда сделала обзор текущего состояния дизайн-системы Microsoft Fluent UI, которая заменила в том числе Office Fabric UI.



Во-первых, кросс-платформенные библиотеки для React, iOS и MacOS, Android, React Native и Windows. Обещают поддержку токенов для тематизации. Во-вторых, шаблоны для Figma: Android, iOS, веб и пиктограммы.

Сама идеология Fluid станет основой и для модульных документов в MS Office.

Тёмная тема оформления


How we created a dark UI for GitLabs Web IDE

Marcel van Remmerden и Jeremy Elder из GitLab рассказывают о создании тёмной темы оформления. Для редакторов кода это стандарт, но сам веб-интерфейс нужно было проработать.



Your dark mode toggle is broken

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

Color Theme Switcher

Max Bck показывает, как быстро и дёшево сделать переключатель темы оформления на сайте (причём не только обычной и тёмной).

Шрифт Darkmode

Вариативный шрифт от Dalton Maag, оптимизированный для светлой и тёмной темы оформления.

Design System Interview Questions

Brad Frost описывает свой опросник, с которым он приходит к клиентам при работе над дизайн-системой.

Raising our voice

Clay Derk рассказывает, как создавались гайдлайны по текстам в интерфейса Shopify. Интересные детали о поиске характера например, они перестали пытаться угадать настроение пользователя.



Building a local design system

Ricardo Vazquez и Tobias Negele из Shopify рассказывают о создании ветки дизайн-системы Polaris для кассовых терминалов. Интересные детали о принципах дизайна для среды, которые определяли интерфейс.

An introduction to accessible data visualizations with D3.js

Рекомендации по поддержке accessibility в визуализации данных на базе движка D3.js от Sarah L. Fossheim. Более общие советы.

IBM Equal Access Toolkit

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



XP.css A design system for building faithful recreations of old UIs

CSS-фреймворк для стилизации интерфейсов под Windows XP.

How to Find Device Metrics for Any Screen

Liam Spradlin из Google рассказывает, как рассчитать размер экрана для любого устройства на Android, при том что их многообразие бесконечно.



Понимание пользователя


Different Information-Seeking Tasks Behavior Patterns and User Expectations

Feifei Liu из Nielsen/Norman Group описывает три вида поведения пользователей при поиске информации: получить, сравнить или выбрать, понять.



Responsible Innovation

Набор фреймворков от Microsoft для этического отношения к пользователям при инновационной деятельности. Анонс.

Информационная архитектура, концептуальное проектирование, контент-стратегия


Untools Tools for better thinking

Коллекция методов системного мышления и анализа проблем при концептуальном проектировании интерфейсов (и не только).



Jim Kalbach The Jobs to Be Done Playbook

Rosenfeld Media выпустили книгу Jim Kalbach The Jobs To Be Done Playbook. UXmatters и A List Apart публикуют выдержки из главы 4 и 5.

Stephen Anderson & Karl Fast Figure It Out

Rosenfeld Media выпустили книгиу Stephen Anderson & Karl Fast Figure It Out о концептуальном проектировании. A List Apart публикуют выдержку из главы 8.

Новые инструменты дизайна интерфейсов


Sketch 66

Совсем мелкий тюнинг.



Adobe XD

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

Framer Web

Версия для браузера вышла из беты. Как её создавали.

Figurative A Figma app for iPadOS

Сторонний клиент Figma для iPad.



Плагины



Шаблоны



Artify

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

Easings

Простой генератор CSS-кода кривых Безье для анимации.

Origami 3

Вышла бета-версия. Новый интерфейс, адаптивность, интеграция со Sketch и Figma.



Zeplin

Интеграция с Visual Studio Code. Быстрый доступ к макетам и связанным задачам в Jira.

Fabula

Приложение позволяет экспериментировать с анимацией для iOS и MacOS. На выходе родной код.

Miroverse Miro Community Templates Gallery

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



Quarkly

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



AR Copy & Paste

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



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


5 baby steps on the path towards a research repository

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

How To Run The Right Kind Of Research Study With The Double-Diamond Model

Steve Bromley приложил методы пользовательских исследований к основным этапам модели двойного алмаза. Как и на какой стадии проверить гипотезы.

How Well Discovery Phases Are Performed in UX Projects

Maria Rosala из Nielsen/Norman Group рассказывает об опросе UX-специалистов на тему проведения разведочных пользовательских исследований.

Approximating Task Completion When You Cant Observe Users

Jeff Sauro и Jim Lewis описывают способы опредлить процент успешно завершённых сценариев в удалённом немодерируемом юзабилити-тестировании. Они предлагают аппроксимацию из ответов на SUS и SEQ.



How to Test the Usability of Documents

Caroline Jarrett и Janice Ginny Redish описывают подходы к юзабилити-тестированию документов. Можно попросить респондентов кратко описать суть после прочтения, отметить отдельные абзацы плюсами и минусами, попросить найти ответ на конкретный вопрос.

Визуальное программирование и дизайн в браузере


Web Vitals

Google предложили базовый набор метрик для оптимизации производительности сайтов. Это сильно влияет на восприятие продукта и работу интерфейса.

Новые скрипты



Метрики и ROI


Business Software UX & NPS Benchmarks (2020)

Jim Lewis и Jeff Sauro провели свежее сравнительное исследование корпоративного ПО. Они сравнили их по метрикам SUS и NPS.



Benchmarking UX: Tracking Metrics

Обзор использования сравнительных метрик Kate Moran из Nielsen/Norman Group. Зачем, когда и какие использовать.

Дизайн-менеджмент и DesignOps


Фреймворк Паттерны дизайн-менеджмента

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



Inside Figma: The product design teams process

Noah Levin описывает все способы синхронизации дизайн-команды Figma. Регулярные встречи, сессии дизайн-критики, совместные выезды, обучение и другие форматы.

Два подхода к дизайн-менеджменту

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



Applying UX-Workshop Techniques to the Hiring Process

Rachel Krause из Nielsen/Norman Group предлагает использовать половину двойного алмаза для процесса найма. Он и так происходит в таком формате, но аналогия интересная.



Как мы отбираем дизайнеров и проводим технические собеседования

Александр Всехвальнов из Ситимобила рассказывает о процессе найма дизайнеров в компании. От отбора и собеседований до тестового задания.

DesignOps Value

Kate Kaplan из Nielsen/Norman Group приводит результаты опроса дизайнеров интерфейсов и дизайн-менеджеров на тему их понимания DesignOps.



Its Experience Agility not a crystal ball that helps you adapt to changing customer needs

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



Командное взаимодействие


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

Продолжаю пополнять коллекцию материалов.

Journey Mapping for Remote Teams A Digital Template

Sarah Gibbons из Nielsen/Norman Group опубликовала шаблон CJM, который адаптирован для заполнения распределённой командой.

Продуктовый менеджмент и аналитика


Построение прогноза аудитории и дохода с помощью когортного анализа в Excel/Google Spreadsheets

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

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

Байрам Аннаков из App in the Air перечисляет навыки менеджера продукта, которые по-хорошему должны быть у всех членов продуктовой команды.

Методологии, процедуры, стандарты


User-Centered Design and Design Thinking Different Origins, Similar Practices

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



UX Design Methods In A Mind Map

Карта методов дизайна интерфейсов и UX-исследований от Mei Zhang. Всё сразу в Miro.



Брендинг цифровых продуктов


Wonder Blocks on the creation of Khan Academys Design System

Nefaur Khandker и May-Li Khoe из Khan Academy рассказывают о поиске единого визуального языка на базе принципов дизайна.



YouTube Sans The Making of a Typeface

Дизайн-директор YouTube Chris Bettig рассказывает о работе над фирменным шрифтом YouTube Sans.



OLX

Ребрендинг международной доски объявлений OLX от Design Studio. Динамический логотип с конструктором под разные ситуации, хотя применения на интерфейсы нет.



Mentimeter

Ребрендинг аналитического сервиса Mentimeter от скандинавской Bold. Графики и диаграммы здорово провязаны с визуальной рифмой и логотипом.



История


Responsive web design turns ten

25 мая исполнилось 10 лет концепции адаптивного дизайна, которую предложил Ethan Marcotte. Он описывает краткую предысторию.

Biggest Wins and Fails in 25 Years of UX Columns

Jakob Nielsen вернулся к своим прогнозам 1995-2001 годов и посмотрел, какие из них сработали, а какие были ложными.



Тренды


The Need for Speed, 23 Years Later

Kathryn Whitenton из Nielsen/Norman Group рассказывает о свежем исследовании скорости работы сайтов, которое они делают уже 23 года. Всё плохо несмотря на увеличение скоростей доступа, сами сайты грузятся также долго (теперь из-за плохой оптимизации кода). Она приводит серию выкладок из экспериментов компаний, показывающих плохое влияние на конверсию.



Алгоритмический дизайн


Portrait AI и AI Gahaku

Сервисы генерируют художественный портрет на основе фото.



Business Designers Bringing User Focus to Business Needs

В IBM назвали проектировщиков интерфейсов бизнес-дизайнерами.

Для общего и профессионального развития


Designer Slack Communities

Каталог дизайнерских сообществ в Slack.

Нон-фикшн клуб: что такое креативность?

Подборка бесплатных или почти бесплатных фильмов о креативности.

Scott Berkun How Design MAKES THE WORLD

Scott Berkun выпустил книгу How Design Makes the World о роли дизайна в повседневных предметах и явлениях. Интервью с ним.

Материалы конференций


The Best Online Design Events

Сервис Design Calendar дополнил свой каталог онлайновыми конференциями и митапами по дизайну.

Adobe 99U Conference

Конференция Adobe 99U пройдёт 17 июня 2020 года в онлайне и бесплатно.

Подпишитесь на дайджест в Facebook, ВКонтакте, Телеграме, на vc.ru или по почте там свежие ссылки появляются каждую неделю. Спасибо всем, кто делится ссылками в группе, особенно Геннадию Драгуну, Павлу Скрипкину, Дмитрию Подлужному, Антону Артемову, Денису Ефремову, Алексею Копылову, Тарасу Бризицкому, Евгению Соколову и Антону Олейнику. Отдельный благодарчик команде Сетки за редактор и Александру Орлову за визуальный стиль.
Подробнее..

Выбор оборудования для системы контроля доступа

19.06.2020 12:20:11 | Автор: admin
При построении системы контроля доступа определяющими параметрами являются быстродействие, надежность, удобство использования и соответствие поставленным задачам.



Архитектура СКУД


В современных СКУД связь между контроллерами, рабочими местами пользователей и сервером системы осуществляется по сети Ethernet. Интерфейс Ethernet обеспечивает высокую надежность работы системы за счет применения типовых IT- решений и работы всех устройств системы в едином адресном пространстве по единому протоколу. Ethernet также дает возможность использования технологии PoE (Power over Ethernet) привлекательного альтернативного способа электропитания сетевых устройств, существенно облегчающего монтаж оборудования СКУД.

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

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

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

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

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

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

Важным параметром при выборе контроллеров для СКУД является количество управляемых исполнительных устройств. Универсальные контроллеры в зависимости от настроек могут управлять турникетами, шлагбаумами или замками. Применение контроллеров второго уровня позволяет организо-вать на базе одного сетевого контроллера, например, доступ через турникет и в 10 внутрен-них помещений или через два турникета и в 8 внутренних помещений, существенно снизив затраты на внедрение СКУД.

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



Контроллер как сервер


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

Контроллеры нового поколения позволили встроить программное обеспечение, что дало возможность использовать контроллер как сервер. Такая архитектура упрощает внедрение системы и снижает ее стоимость. Например, система PERCo-Web, построенная на без такого контроллера, может обработать данные 500 сотрудников и 500 посетителей и иметь в соста-ве до 10 контроллеров. Контроллер подключается к сети по интерфейсу Ethernet. Для кон-троля доступа в компании численностью до 100 сотрудников будет достаточно бесплатной версии ПО.
Развитие интернет-технологий и пропускной способности каналов позволяет говорить о том, что Web-технологии в скором времени заменят традиционный подход к разработке не только программного обеспечения СКУД, но и вообще любых систем. По мере появления все более мощных контроллеров все возможности ПО систем контроля доступа можно будет реализовать в них самих, без установки сервера системы на компьютер.

Web-интерфейс контроллеров


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

Возможности интеграции


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

Выбор способов идентификации


При выборе оборудования для системы контроля доступа необходимо определить, какие способы идентификации будут использоваться на объекте: карты доступа форматов EMM/HID или MIFARE с защитой от копирования, мобильный доступ, доступ по штрих-коду, отпечаткам пальцев, распознаванию лиц. Характеристики контроллеров и считывателей должны позволить реализовать выбранный способ идентификации.

Для связи контроллера и считывающих устройств применяются интерфейсы Wiegand, RS-485 и USB. Wiegand применяется в СКУД для чтения магнитных карт и RFID-идентификаторов. Среди достоинств интерфейса: простота, распространенность, дальность действия до 150 метров, совместимость оборудования различных производителей. Среди недостатков уязвимость для взлома за счет отсутствия двухсторонней аутентификации и шифрования данных, отсутствие контроля целостности передаваемых данных и линии между контроллером и считывателем.

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

Для использования сразу нескольких способов идентификации, например, доступа по картам EMM/HID и MIFARE с защитой от копирования, а также мобильного доступа можно выбрать мультиформатные считыватели. При выборе считывателя важно обращать внимание на такие характеристики, как рабочий диапазон температур (при использовании на открытом воздухе), степень защиты IP и вандалозащищенность.

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

7 cмертных грехов Slack в большой компании (и как победить их автоматизацией)

19.06.2020 12:20:11 | Автор: admin
Так как многие, похоже, останутся на удаленке на лето, Slack станет центром пересечения буквально всех процессов и коммуникаций. Хотим поделиться набором мини-приложений, которые помогут решать типовые проблемы разных команд.


Например, вы можете сделать себе бота, который будет будит CTO.

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

1. Люди спрашивают все подряд и делятся субъективно важными вещами в основном канале


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

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

В Slack есть своя версия этого греха зайти в канал #general и спросить что-нибудь почти личное. Плюс вишенка на торте тегнуть всех.

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

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

  • При попытке написать в #general бот моментально удаляет пост из канала но для автора это незаметно: кажется, что тебе просто не дают опубликовать сообщение. При этом робот сохраняет текст и данные об авторе.
  • Бот напоминает, зачем нужен канал и предлагает подумать, стоит ли писать именно в него.
  • Если автор упорствует, бот отправляет текст на проверку модератору.
  • Дальше модератор обычно это кто-то из внутреннего PR или опубликует текст в канале, указав автора оригинала, или напишет автору в личку, объяснит, почему его сообщение нерелевантно каналу, и где лучше публиковать такие запросы или новости.

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

А для частых вопросов мы завели канал с говорящим названием #faq кстати, отвечают в нем уже люди, а не боты.


2. Никто не читает закреп перед тем, как написать в канал


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

Скажем, вы вбиваете в поиске что-то вроде #mobile, чтобы найти, где поделиться замечанием или предложением по работе одного из приложений. И видите примерно такой список:


С недавних пор завели правило неактивные в течение 90 дней каналы архивируются.

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


Раньше мы указывали типы запросов, которые можем обработать, в закрепленном сообщении. Но (surprise!) его никто не читал.

Теперь у нас есть бот, который присоединяется к каналу и при добавлении любого новичка отправляет ему эфемерное (это которое 'Only you can see this message') сообщение с правилами.

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


3. Задают вопросы, которые есть во внешнем FAQ. И вообще не любят выходить во внешние информационные системы


На этот счет мы написали целый взвод ботов. Каждый помогает в своем кейсе.

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


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

Мы поступили просто: если кто-то не идет в вики, то она должна прийти к нему. Так как вопросы часто типовые, написали бота, который:

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


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


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


Общение команд разработки и инфраструктуры идет через канал, в который за день падают по 30-50 сообщений. Ребятам из инфры есть чем заняться, помимо создания тикетов в Jira. Поскольку любое сообщение в канале #infra будет или запросом, или отчетом о проблеме, есть бот, который автоматически создает таски из сообщений вида привет, вот-что-случилось-или-нужно, помогите, пожалуйста.


Реакции под сообщениями это не просто так. Это статусы тикетов в общей системе управления задачами.

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

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


5. Тратят время на ручную выгрузку и визуализацию данных из внешних систем


Целый выводок ботов, наоборот, помогает доставать данные из сторонних систем. Так, у тимлидов в ходу три помощника:

Slack-burndown-bot берет спринт в Jira и формирует диаграмму сгорания: вот сколько всего задач, вот сколько вы сделали, вот сколько осталось.


А команда может по вечерам вместе любоваться на горящий закат горящий спринт в своем канале.

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

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


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


6. Говорят, ну я же написал вот там... или Бот, который может разбудить CTO


Иногда бывает такое, что что-то легло. Особенно, ночью.

Для критичных падений мы завели отдельный канал и подключили к нему бота, который дублирует дежурного. Мы используем сервис Opsgenie для алертинга: говоришь ему следить за набором серверов и, если какой-то упал, то сервис присылает дежурному сообщение на пейджер звонит дежурному на мобильный. Если дежурный не реагирует, спустя 20-30 секунд ему звонит робот и когда трубка поднята, робот сообщает что-то вроде: Там лежит, ужас, нажмите 1, если вы это услышали и чините.


Процесс на гифке ускорен, но отражает суть.

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

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


7. А еще все хотят своего бота для слэка


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

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

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

Как мы пересмотрели стандартный подход к тендерам и получили 300 дизайн-проектов интерфейса medtech-сервиса по 3000 руб

23.06.2020 20:12:31 | Автор: admin
Мы в Globosphere Russia работаем над тремя медтех проектами. Один из них MY DATA. Это электронная медицинская карта нового поколения на основе big data. Сервис будет собирать информацию о здоровье человека из разных источников, анализировать данные, находить корреляции и приводить информацию к единому формату, выдвигая гипотезы о состоянии здоровья.

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

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

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



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


image

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

Агентствам нужно четкое ТЗ, у нас его не было и пока не может быть.

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

Аутсорс это всегда риски.

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

Найм приносит мало идей.

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

Тендеры отсеивают многих.

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

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

Но мы прикинули рентабельность, взвесили все за и против. Выходило, что на предыдущие варианты мы потратим аналогичное количество времени и ресурсов, но при этом получим меньше идей, чем если проведем конкурс. Так мы решились запустить конкурс для UX/UI на создание электронной медицинской карты нового поколения Future Health Design 2020.

Механика конкурса


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

Условия

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

Призовой фонд

Чтобы сделать конкурс максимально привлекательным, мы объявили общий призовой фонд в 2 600 000 рублей. Из него 600 000 рублей распределяются между 1, 2 и 3 местом. А победителю гарантируется контракт на сумму не менее 2 000 000 рублей.

ТЗ

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

  • Интерфейс врача
  • Интерфейс пациента
  • Анализ данных
  • Хранилище информации
  • Взаимодействие с клиниками и врачами
  • Телемедицина
  • Лекарства


Необязательные блоки для конкурсной работы:

  • Расписание
  • Визуализация человеческого тела


На втором этапе мы отбирали ТОП-15 самых перспективных работ и отправляли исполнителям детальные комментарии для доработки.

Система оценивания

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

Мы поступили следующим образом: первые этапы отбора проходили внутри компании. Силами своей команды мы отобрали из 300 проектов сначала ТОП-15, а потом ТОП-10 финалистов. А вот уже победителей из ТОПА-10 выбирало внешнее жюри, в которое мы пригласили основателей известных российских medtech-проектов (Best Doctor, Третье мнение, Doc+, Мобильные Медицинские Технологии, Кнопка жизни), фарм-проектов (Pharma.Global), экспертов в сфере дизайна (специалисты Skillbox, Дизайн государственных систем).

image

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

image

Продвижение

Мы использовали два основных направления в продвижении:

  • таргетинговая реклама
  • pr-инструменты


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

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

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

С рекламных источников мы получили 53% заявок, с pr-активнсотей 47%.

Этапы

1 этап: 1 28 апреля прием заявок на участие, выполнение ТЗ 1. Отбираем ТОП-15 работ.

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

2 этап: 1 25 мая выполнение ТЗ 2. Отбираем ТОП-10.

На этом этапе мы отправляли ТЗ с уже конкретизированными рекомендациями по доработке проектов тем, кто прошел в ТОП-15. После новой итерации правок отобрали ТОП-10 финалистов.

3 этап: 25 31 мая голосование членов Жюри из разных областей. Выбор ТОП-3.

Определение 1, 2 и 3 места путем общего голосования жюри.

Что мы получили?


Нам прислали около 2300 заявок дизайнеры из 15 стран, из которых мы получили 320 дизайн-проектов конверсия из заявки в конкурсную работу почти 14 %.

Работы оценивались по 10-бальной шкале. Из 320 дизайн-проектов, больше всего работ набрали по 4-5 баллов 33%. А самые высокие баллы получили 9%.

Вот так выглядит полная картина оценки качества работ:
плохо. Баллы: 1-4: 82 работы
средне. Баллы 5-6: 104 работы
хорошо. Баллы 7-8: 74 работы
отлично. Баллы: 9-10: 30 работ


Когда мы планировали конкурс, мы рассчитывали на 1000 заявок и около 150 работ. Исходя из текущей конверсии, выходит, что на 1000 заявок в конкурс со сложным проектом реально получить около 6-7% работ. Мы же перевыполнили KPI в два раза!

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

1 место Нестерова Мария

image
Пример экрана интерфейса из конкурсной работы

2 место Сидорец Кирилл

image
Пример экрана интерфейса из конкурсной работы

3 место агентство Nimax

image
Пример одного экрана интерфейса из конкурсной работы

Со всеми работами финалистов можно познакомиться на сайте конкурса.

Что можно улучшить?


Предусмотреть больше времени на работы

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

Хотя бы за 1 день до окончания: 11%
Последний день: 89%
Последний час: 62%


А по результатам опроса почему на первом этапе дизайнеры не стали принимать участие большинство ответили, что не хватило бы времени сделать хорошую работу 42%.

Давать больше обратной связи участникам

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

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

Перевод Алан Кей История SmallTalk (1960-1969)

24.06.2020 10:13:26 | Автор: admin
У меня есть цель разобраться в том, что же происходило в 60-70-е годы в Xerox PARC и в окрестностях, как так вышло, что несколько коллективов инженеров, работая рука об руку, создали невероятные технологии, которые определили наше настоящее, а их идеи будут определять будущее. Почему этого не происходит сейчас? (а если происходит, то где?). Как собрать подобный коллектив? Где же мы повернули не туда? Какие идеи мы пропустили, а стоило бы к ним повнимательнее присмотреться?

Предлагаю вашему вниманию перевод начала большого текста Алана Кея (150 000 знаков), на который он неоднократно ссылается во всех своих выступлениях и ответах на Quora и HackerNews.

Кто готов помогать с переводом пишите в личку.



I. 196066 Становление ООП и другие новые идеи 60-х


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

Любая новинка проходит несколько стадий принятия как своими создателями, так и всеми остальными. Вот как это происходит у создателей. Сначала они замечают, что в разных проектах используется будто бы тот же подход. Позднее их предположения подтверждаются, но пока никто не осознает грандиозного значения новой модели. Затем происходит великий сдвиг парадигмы и модель становится новым способом мышления. И наконец она превращается в закостенелую религию, от которой сама и произошла. Все остальные принимают новинку по Шопенгауэру: сперва ее осуждают, называя безумной; через пару лет ее уже считают очевидной обыденностью; в конце концов те, кто ее отвергал, объявляют себя ее создателями.

То же было со мной. Будучи программистом ВВС США, я не раз замечал в программах намеки на ООП. Впервые на компьютере Burroughs 220 тренировочного авиационного командования (TAK) в способе переноса файлов с одной инсталляции на другую. В те времена не было стандартных операционных систем и форматов файлов, поэтому какой-то программист (я до сих пор не знаю кто) нашел изящное решение: каждый файл он делил на три части. Сами данные лежали в третьей части она могла быть любого размера и формата. Во второй части хранились процедуры B220, которые умели копировать данные, в том числе отдельные поля, и складывать их в третью часть. Ну а первая часть представляла собой массив относительных указателей на точки входа процедур второй части (исходные указатели хранились в стандартном порядке и имели ясное предназначение). Что и говорить, идея была отличная и использовалась во многих последующих системах. Она благополучно исчезла, когда пришел COBOL.

image

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

После ВВС я, доучиваясь в университете, работал в Национальном центре атмосферных исследований и в основном занимался системами извлечения для больших массивов погодных данных. Я заинтересовался симуляцией как одна машина может симулировать другую, но времени хватило, только чтобы создать одномерный вариант поблочной пересылки битовых полей (bitblt) на CDC 6600, чтобы симулировать разные размеры слов. Остальное время уходило на учебу (а если честно, на студенческий театр). Когда я работал в Чиппева-Фолс и помогал отлаживать Burroughs 6600, то наткнулся на статью Гордона Мура, в которой он пророчил экспоненциальный рост плотности и снижение стоимости интегральных схем на много лет вперед. Предсказание потрясающее, но вряд ли я мог его постичь, стоя перед занимавшим целую комнату B6600 с его 10 МГц и фреоновым охлаждением.

image

Графическая система Sketchpad и Симула


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

Такую папку получал каждый новичок. Назывались они все одинаково Sketchpad: графическая система коммуникации между человеком и компьютером. Система была удивительная и весьма отличалась от всего, что мне попадалось раньше. Вот ее три заслуги, которые проще всего осознать: 1) изобретение современной интерактивной компьютерной графики; 2) описание сущностей с помощью эталонных чертежей, по которых затем можно производить конкретные экземпляры; 3) графические рамки, применяя которые к эталонам, можно создавать наборы связанных сущностей и с их помощью управлять машиной. Структуры данный в этой системе понять было сложно. Единственное, что казалось немного знакомым, это передача процедурам указателей для перехода по ним в подпрограммы (так называемая обратная индексация, как в файловой системе B220). Это первая оконная система с отсечением изображения и изменением масштаба. Ее виртуальный холст простирался на полкилометра по обеим осям!

image

image

image

image

image

image

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

Понять документацию было просто невозможно. Язык был вроде как Алгол для Case-Western Reserve 1107, но основательно переработанный и названный Симулой. Документация такая, будто кто-то написал ее на норвежском, а затем транслитерировал на английский (между прочим, так оно и было). Некоторые слова, например activity и process, использовались вообще в другом смысле.

Вместе с еще одним аспирантом мы раскатали 25-метровый рулон в коридоре и стали ползать по нему, изучая код и перекрикиваясь, когда находили что-то интересное. Самой странной частью кода был распределитель памяти, который, в отличие от Алгола, не использовал стек. Пару дней спустя мы поняли почему: в Симуле память отводилась под структуры, которые очень походили на экземпляры объектов Sketchpad, а еще там имелись своего рода описания, по которым и создавались независимые друг от друга объекты. То, что в Sketchpad было эталонами и экземплярами, в Симуле называлось activity и process. Более того, Симула оказалась процедурным языком для управления Sketchpad-подобными объектами, то есть опережала Sketchpad с его рамками в плане гибкости (но уступала ему в изящности).

Симула удивила и изменила меня навсегда. Она стала последней каплей: очередная встреча с идеями ООП позволила мне осознать их в общем смысле, я словно испытал катарсис. В математике я занимался абстрактными алгебрами, то есть небольшими наборами операций, универсально применимых к самым разным структурам. В биологии клеточным метаболизмом и высокоуровневым морфогенезом, где простые механизмы управляют сложными процессами, а универсальные кирпичики организма могут превращаться в то, что нужно именно здесь и сейчас. Файловая система B220, сам B5000, графическая система Sketchpad и, наконец, Симула использовали ту же идею для разных целей. За несколько дней до этого главный конструктор B5000 и профессор в Университете Юты Боб Бартон на одном из выступлений сказал так: Базовый принцип рекурсивного проектирования состоит в том, что сущности на любом уровне вложенности должны обладать равными возможностями. Тогда я впервые примерил эту идею к компьютеру и понял, что совершенно зря его делят на более слабые концепции структуры данных и процедуры. Почему бы не делить его на маленькие компьютеры, как в системах с разделением времени? Только не на десять, а сразу на тысячи, каждый из которых симулировал бы полезную структуру.

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

II. 196769 FLEX: первый ПК на основе ООП


Дейв Эванс считал, что в аспирантуре многому не научишься и, как и многие подрядчики ARPA, хотел, чтобы мы занимались настоящими проектами и не тратили слишком много времени на теорию, а диссертации посвящали лишь новейшим разработкам. Обычно Дейв устраивал своих подопечных консультантами. Так в начале 1967 года он познакомил меня с дружелюбным Эдом Чидлом настоящим гением аппаратного обеспечения. Эд тогда работал в местной аэрокосмической фирме над, как он выражался, маленьким компьютером. Конечно, первый персональный компьютер, LINC, создал не он, а Уэс Кларк, зато Эд хотел сделать машину для некомпьютерщиков. Например, он хотел запрограммировать ее на языке высокого уровня, например на Бейсике. Может, лучше на JOSS? предложил я. Ну давай, ответил он. Вот так и начался наш с ним приятный проект, который мы назвали FLEX. Чем глубже мы забирались в разработку, тем лучше осознавали, что хотим добиться динамической симуляции и расширяемости. JOSS (да и никакой другой известный мне язык) не особенно подходил ни для первого, ни для второго. Симула отпала сразу наш компьютер был слишком мал для нее. Красота JOSS заключалась в невероятном уровне внимания к пользователям в этом плане его не превзошел ни один язык. Но для серьезных вычислений JOSS был слишком медленным, а еще в нем не было настоящих процедур, областей действия переменных и т. п. Эйлер, язык созданный Никлаусом Виртом, походил на JOSS, но имел гораздо больший потенциал. Он представлял собой обобщение Алгола по идеям, впервые высказанным ван Вейнгаарденом: типы убраны, многие моменты унифицированы, процедуры стали объектами первого класса и т. д. Что-то вроде Лиспа, но без особых мудреностей.

image

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

Мы думали, что наибольшее влияние на семантику FLEX должна оказать Симула, а не Алгол или Эйлер, но выходило иначе. А еще не было понятно, как же пользователи будут взаимодействовать с системой. Даже у первого компьютера Эда был экран (для графиков и т. п.), а LINC был оснащен стеклянным телетайпом. Нам же по карману были лишь 16 тысяч 16-битных слов о Sketchpad на такой машине можно было и не мечтать.

Даг Энгельбарт и его NLS


Итак, дело было в первой половине 1967-го. Мы всё думали над FLEX, а в Университет Юты приехал Даг Энгельбарт визионер просто таки библейских масштабов. Он был одним из прародителей того, что мы с вами называем персональным компьютером. Он возил с собой 16-миллиметровый проектор с дистанционным управлением СТАРТ/СТОП вместо курсора, ведь тогда курсоры были еще в новинку. Главной идеей, которую он продвигал в ARPA, была Онлайн-Система (NLS, oNLine Systems), призванная усилить человеческий интеллект с помощью интерактивного средства перемещения по векторам мыслей в пространстве концепций. Даже по сегодняшним стандартам возможности его детища поражают воображение: гипертекст, графика, несколько рабочих панелей, эффективная навигация, удобный ввод команд, средства совместной работы и т. д. целый мир понятий и абстракций. Благодаря Энгельбарту все, кто желал усилить свой интеллект, сразу понимали, какими должны быть интерактивные компьютеры. Вот и я немедленно позаимствовал многие его идея для FLEX.

image

Симбиоз человека и компьютера, стоявший в центре всех проектов ARPA, и маленький компьютер Эда вновь напомнили мне о законе Мура, но на этот до меня наконец дошло его значение. Я осознал, что машина, занимавшая раньше целую комнату (тот же TX-2 или даже B6600 на 10 МГц), теперь умещается на столе. Эта мысль меня напугала: стало ясно, что современный подход к компьютерам долго не протянет, и само слово компьютер приобретало новый смысл. Наверное, так же себя чувствовали люди, только что прочитавшие трактат Коперника и взглянувшие на новые Небеса с новой Земли.

Вместо пары тысяч учебных мейнфреймов, разбросанных по всей планете (даже сейчас, в 1992 году, в мире насчитывается всего около 4000 мейнфреймов IBM) и нескольких тысяч пользователей, обученных определенным приложениям, в мире будут миллионы персональных машин и пользователей вне досягаемости университетов и организаций. Откуда возьмутся приложения? Как люди будут учиться этому? Как разработчики ПО узнают, что нужно конкретному пользователю? Здесь прямо напрашивалась расширяемая система такая, чтобы люди сами подгоняли ее под свои нужды (и дажи могли дорабатывать). Благодаря успеху систем с разделением времени многие в ARPA это уже понимали. Грандиозная метафора о симбиозе человека и машины затмевала любые проекты и не давала им превратиться в религии, удерживая внимание на абстрактном Святом Граале усилении человеческого интеллекта.

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

Напомню, что FLEX был слишком мал для того, чтобы стать мини-NLS. Нам пришлось выкручиваться, чтобы внедрить в него хотя бы часть передовых идей, а в некоторых случаях и развить их. Я решил, что универсальное окно в огромный виртуальный мир в духе Sketchpad лучше, чем тесные горизонтальные панели. Мы с Эдом придумали алгоритм отсечения изображения, очень похожий на тот, что создал Сазерленд в Гарварде: он со своими студентами разработал такой алгоритм одновременно с нами в рамках проекта по созданию шлема виртуальной реальности.

На FLEX ссылки на сущности были обобщением дескрипторов B5000. Вместо разных форматов ссылок на числа, массивы и процедуры, дескрипторы FLEX содержали два указателя: один на эталон объекта, а другой на его конкретные экземпляры (мы потом поняли, что первый указатель лучше класть в экземпляры, чтобы сэкономить место). К работе с обобщенными задачами мы подошли иначе. В B5000 были l-значения и r-значения в некоторых случаях этого было достаточно, но для более сложных объектов нужны было что-то другое. Вот пример. Пусть a разреженный массив, элементы которого по умолчанию имеют значение 0. Тогда a[55] := 0 все равно приведет к созданию элемента, потому что := оператор, а a[55] дереференцируется в l-значение, прежде чем кто-либо успеет понять, что r-значение это значение по умолчанию. При этом неважно, чем на самом деле является a: массивом или процедурой над массивом. Здесь нужно что-то вроде a(55, ':=', 0). При таком подходе программа сначала проверит все нужные операнды и только потом, если нужно, создаст элемент. Другими словами, := тут уже не оператор, а вполне себе указатель на метод сложного объекта. На то, чтобы понять это, мне потребовалось неприлично много времени. Наверное, потому что пришлось перевернуть традиционное представление об операторах, функциях и т. п. Только после этого я осознал, что поведение должно быть частью объекта. Проще говоря, объект это набор пар ключ-значение, где в роли значений выступают определенные действия. У Рудольфа Карнапа есть книга по логике, которая помогла мне понять, что традиционные способы расширения программ и содержательные дефиниции обладают одинаковыми возможностями, но последние интуитивно понятнее и удобнее.

image

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

while i <= 1 to 30 by 2 ^ j <= 2 to k by 3 do j<-j * i;

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

Еще одна интересная управляющая конструкция FLEX when. Она работала на мягких прерываниях от событий.

image

Продолжение следует...

За перевод спасибо Алексею Никитину.
(Кто считает, что эта статья важная и хочет помочь с переводом пишите в личку или alexey.stacenko@gmail.com)



Ещё


Переводы Алана Кея:


Ричард Хэмминг

image

Книга Ричарда Хэмминга The Art of Doing Science and Engineering: Learning to Learn
Предисловие
  1. Intro to The Art of Doing Science and Engineering: Learning to Learn (March 28, 1995) Перевод: Глава 1
  2. Foundations of the Digital (Discrete) Revolution (March 30, 1995) Глава 2. Основы цифровой (дискретной) революции
  3. History of Computers Hardware (March 31, 1995) Глава 3. История компьютеров железо
  4. History of Computers Software (April 4, 1995) Глава 4. История компьютеров Софт
  5. History of Computers Applications (April 6, 1995) Глава 5. История компьютеров практическое применение
  6. Artificial Intelligence Part I (April 7, 1995) Глава 6. Искусственный интеллект 1
  7. Artificial Intelligence Part II (April 11, 1995) Глава 7. Искусственный интеллект II
  8. Artificial Intelligence III (April 13, 1995) Глава 8. Искуственный интеллект-III
  9. n-Dimensional Space (April 14, 1995) Глава 9. N-мерное пространство
  10. Coding Theory The Representation of Information, Part I (April 18, 1995) Глава 10. Теория кодирования I
  11. Coding Theory The Representation of Information, Part II (April 20, 1995) Глава 11. Теория кодирования II
  12. Error-Correcting Codes (April 21, 1995) Глава 12. Коды с коррекцией ошибок
  13. Information Theory (April 25, 1995) Готово, осталось опубликовать
  14. Digital Filters, Part I (April 27, 1995) Глава 14. Цифровые фильтры 1
  15. Digital Filters, Part II (April 28, 1995) Глава 15. Цифровые фильтры 2
  16. Digital Filters, Part III (May 2, 1995) Глава 16. Цифровые фильтры 3
  17. Digital Filters, Part IV (May 4, 1995) Глава 17. Цифровые фильтры IV
  18. Simulation, Part I (May 5, 1995) Глава 18. Моделирование I
  19. Simulation, Part II (May 9, 1995) Глава 19. Моделирование II
  20. Simulation, Part III (May 11, 1995) Глава 20. Моделирование III
  21. Fiber Optics (May 12, 1995) Глава 21. Волоконная оптика
  22. Computer Aided Instruction (May 16, 1995) Глава 22. Обучение с помощью компьютера (CAI)
  23. Mathematics (May 18, 1995) Глава 23. Математика
  24. Quantum Mechanics (May 19, 1995) Глава 24. Квантовая механика
  25. Creativity (May 23, 1995). Перевод: Глава 25. Креативность
  26. Experts (May 25, 1995) Глава 26. Эксперты
  27. Unreliable Data (May 26, 1995) Глава 27. Недостоверные данные
  28. Systems Engineering (May 30, 1995) Глава 28. Системная Инженерия
  29. You Get What You Measure (June 1, 1995) Глава 29. Вы получаете то, что вы измеряете
  30. How Do We Know What We Know (June 2, 1995) переводим по 10 минутным кусочкам
  31. Hamming, You and Your Research (June 6, 1995). Перевод: Вы и ваша работа

Подробнее..

Перевод Долгая и извилистая дорога к внедрению GPS во все автомобили

27.06.2020 12:11:16 | Автор: admin
Подписывайтесь на каналы:
@AutomotiveRu новости автоиндустрии, железо и психология вождения
@TeslaHackers сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla


image


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

Точное время


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

image

(И нет, несмотря на название, атомные часы не радиоактивны.)

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

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

Идея атомных часов была разработана профессором физики Колумбийского университета Исидором Раби в 1945 году с использованием методики, которую он разработал в 1930-х годах и назвал магнитным резонансом атомного пучка. Эта концепция позволила точно измерять магнитные свойства атомных ядер путем обнаружения единичных состояний вращения атомов и молекул, а метод, в свою очередь, доказал свою осуществимость в качестве способа точного определения времени. Первые часы с использованием атомно-лучевого магнитного резонанса были введены в 1949 году Национальным бюро стандартов (ныне Национальный институт стандартов и технологий, или NIST) с использованием атомов аммиака, но они не были достаточно точными. В 1952 году наиболее точным элементом был признан цезий, который впервые был использован на часах под названием NBS-1. Семь лет спустя NBS-1 был введен в эксплуатацию в качестве основного хронометриста НИСТ.

К моменту проведения 13-й Генеральной конференции по весам и мерам в 1967 году был установлен международный стандарт: секунда времени была определена как 9 192 631 770 циклов облучения, которое требуется атому цезия для вибрации.

Впервые мировой хронометраж перестал основываться на астрономии.

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

Точное местоположения


image


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

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

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

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

Это привело к тому, что в 1959 году ВМФ США построил свою первую спутниковую навигационную систему. Система под названием Transit была разработана Лабораторией прикладной физики Джона Хопкинса с использованием орбитальных спутников для передачи радиосигналов на мониторинговые станции. Эта система позволила пользователям определять свое местоположение путем измерения допплеровского сдвига сигналов спутников и, в свою очередь, была использована для слежения за местоположением атомных подводных лодок. Хотя связь и не была быстрой, она доказала надежность космических систем.

Примерно в то же время у Лаборатории военно-морских исследований и Организации по космическим и ракетным системам ВВС США были и другие идеи. Они отдавали предпочтение программе Timation, созданной в 1964 году и запущенной в 1967 году. В этой системе использовались два экспериментальных спутника с кварцевыми кристаллическими часами (хотя в конечном итоге они переключились на рубидиевые и цезийные атомные часы). И, как бы доказывая существование государственной неэффективности, ВВС также работали над аналогичной технологической программой под названием System 621B. Она непрерывно обеспечивала навигацию с использованием 16 спутников на орбитах, которые образовывали четыре кластера овальной формы, вытянутые на 30 градусов севернее и южнее экватора. (Мы упоминали, что армия предлагала свою собственную систему, SECOR, или Sequential Correlation of Range?).

Наконец, кто-то в Министерстве обороны в 1968 году создал NAVSEG, или Группу управления навигационными спутниками, которой было поручено изучить различные системы, уже существующие или разрабатываемые. Неудивительно, что в появившемся решении были использованы лучшие аспекты систем ВМФ и ВВС. Министерство обороны одобрило разработку глобальной системы позиционирования NAVSTAR в декабре 1973 года. Испытания начались в следующем году, а полномасштабная разработка была одобрена в августе 1979 года.

К сожалению NAVSTAR столкнулась с некоторыми трудностями на рассвете нового десятилетия. Бюджет на ее разработку был сокращен на 30% министром обороны в начале 1980-х годов. Важность нового танка или самолета легко понять, в отличие от новой высокотехнологичной системы поддержки. В конечном итоге количество спутников было сокращено до 18 с 24, плюс три запасных. Далее, как раз в тот момент, когда все шло своим чередом, авария космического челнока Челленджер в 1986 году задержала программу еще на 2 года. Первые спутники, наконец, были запущены с мыса Канаверал в феврале 1989 года и начали использоваться в апреле.

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

GPS-системы за пределами Соединенных штатов


Безусловно, развитие государством атомных часов и систем глобального позиционирования привело к созданию коммерческого рынка, на котором вскоре появились меньшие по размеру, более быстрые и дешевые устройства, что, в свою очередь, помогло военным. Сегодня космическое командование ВВС США управляет системой GPS, которая была разработана, в частности, при участии стран НАТО и Австралии. Эта система также используется информационно-развлекательными системами в автомобилях для обеспечения навигации и спутникового радиовещания. Остальной мир наверстывает упущенное, начиная с ГЛОНАСС, или Глобальной навигационной спутниковой системы космической навигационной системы, созданной Россией. Планирование ее разработки было начато в 1968 году, а к 1976 году страна завершила создание этой системы. К 1991 году в эксплуатации находилось 12 спутников, а через два года она была введена в эксплуатацию, хотя в целом система функционировала лишь в декабре 1995 года. К 2002 году система едва работала. С помощью Индийской организации космических исследований, Космического агентства Индии, Российское космическое агентство развернуло ГЛОНАСС в полную силу к маю 2007 года.

Не осталась в стороне и глобальная навигационная спутниковая система Европейского космического агентства Galileo, работающая совместно с GPS и ГЛОНАСС. Первые спутники были запущены в 2011 году. Система начала функционировать в 2013 году, и в настоящее время на орбите находится 26 спутников. После завершения проекта Galileo будет иметь в эксплуатации 30 спутников.

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

Подробнее тут:



Оцифрованные карты перемещаются на приборную панель


Идея о том, что система GPS, встроенная в ваш автомобиль, может подсказать вам, куда ехать, заменяя вам партнера или штурмана, была надуманной до тех пор, пока первая картографическая навигационная система не была представлена в Японии в качестве дилерской опции для второго поколения Honda Accord в 1981 году. Система Honda Electro Gyrocator использовала датчики и гироскопы, которые сравнивали поверхность дороги с поверхностью карты, указывая таким образом направление движения. Также известная как система точного расчета траектории, она не использовала спутники, впрочем, техника не всегда работала корректно по причине наличия неточностей в картах, а это проблема для системы, которая добавляет дополнительные 25 процентов к стоимости автомобиля. Это была первая современная навигационная система, но лидерство в выходе на рынок не гарантирует долгую жизнь. Система Honda Electro Gyrocator исчезла в 1982 году.

image

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

Производители навигаторов Etak знают об этом не понаслышке. Разработанная в Калифорнии Стэном Хани и основателем Atari Ноланом Бушнеллом, эта навигационная система, устанавливаемая после продажи автомобиля, также работала по принципу точного расчета траектории, сравнивая местоположение автомобиля с точками на карте. Устройство было разработано дизайнером Pong, Аланом Алькорном (Alan Alcorn), и для составления карты оно использовало микропроцессор Intel 8088 и кассетный магнитофон. Благодаря использованию цифровой карты, компаса и датчиков колес, водители могли видеть результаты работы системы на экране.

image

Первая автомобильная навигационная система на основе карт была представлена в Японии в качестве дилерской опции для Honda Accord 1981 года. Названный Honda Electro Gyrocator, он использовал счисление пути для отслеживания местоположения автомобиля, используя используемые датчики и гироскопы для сравнения дорожного покрытия с картой.

Разработка аппаратного обеспечения была легкой, более сложной задачей оказалось получение картографической информации. Позднее компания Etak воспользовалась опытом Бюро переписи населения США, которые были профессионалами в оцифровке карт с помощью топографической математики. В качестве носителя информации инженеры выбрали карты на кассетах с поликарбонатными оболочками. На каждой из них хранилось по 3,5 МБ данных. Они лучше прочих противостояли ударам и вибрациям, а также выдерживали экстремальные температуры припаркованного автомобиля. Тем не менее, первая область, которую они нанесли на карту, Сан-Франциско, потребовала от водителей использовать шесть кассет. Экран системы представлял собой векторный катодный излучатель с высоким разрешением, который отображал яркую и четкую линию. Маленький экран считался слишком дорогим.

В июле 1985 г. появился Etak Navigator 700 с 7-дюймовым экраном за 1595$ (3819$ с поправкой на инфляцию), и Etak Navigator 450 с 4,5-дюймовым экраном за 1395$ (или 3340$ сегодня). Кассеты стоили по 35 долларов каждая (или 84 доллара сегодня). Эти модели были достаточно успешны, чтобы будущие конкуренты покупали лицензии на патенты, данные карт и/или аппаратное обеспечение Etak. Etak была куплена новостной корпорацией Руперта Мердока в 1989 году за почти 25 миллионов долларов.

image

Первая навигационная система Toyota CD-ROM была установлена на японском рынке в 1987 году Toyota Crown Royal Saloon G

Два года спустя в Toyota's Crown Royal Saloon G, продававшейся на японском рынке, была предложена навигационная система с первым цветным CRT-дисплеем и картографической системой на компакт-дисках. Но так как все эти системы использовали точный расчет траектории (то есть, сравнивали местоположение автомобиля с точками на карте), эти решения на самом деле были не намного более совершенны, чем Jones Live-Map 1909 года. В 1980-е годы было использовано больше технологий.

image

Первый в мире современный автомобиль с интегрированной системой GPS-навигации, как на Eunos Cosmo, высококлассной марки Mazda на японском рынке.

image

Eunos Cosmo 1990-1995 годов выпуска-первый в мире современный автомобиль с интегрированной системой GPS-навигации. Eunos был высококлассной маркой Mazda на японском рынке и должен был стать частью запланированного бренда Mazda Amati, хотя Mazda в конечном счете решила не запускать его в Америке. Тем не менее, автомобиль выпускался до 1995 года.

Mazda представила первую в мире современную автомобильную навигационную систему GPS, которую компания предлагала только в Японии на Eunos Cosmo 1990 года. Eunos была высококлассной машиной, и этот автомобиль должен был стать частью запланированного бренда Mazda Amati. В итоге Mazda решила не запускать его в Америке, но, тем не менее, автомобиль выпускался до 1995 года.

Спустя год после выхода Cosmo, в 1991 году, Toyota представила на японском рынке свою Electro-Multivision Global Positioning System в Toyota Soarer, выпущенной для внутреннего рынка (эта машина известна в штатах как Lexus SC). Она отображала местоположение автомобиля на 6-дюймовом цветном ЖК-дисплее с помощью спутников GPS.

Далее будут встречаться названия систем GPS из прошлого, которые могут быть вам знакомы. В 1992 году подразделения General Motors Oldsmobile и Delco представили встроенную навигационную систему GPS с 6-дюймовым полноцветным экраном Sony CRT под названием TravTek в автомобилях Avis Rent-A-Car во Флориде. В конце концов, эта система стала заводской опцией за $1995 на седане Oldsmobile 88 1995 года, где она была известна как GuideStar, навигационная система с точным расчетом траектории, использующей карты. И не путайте эту систему с более поздним сервисом OnStar, не использующим карты. Первоначально предлагалось использование этой системы только с картами Калифорнии или Лас-Вегаса, экран вставлялся в середину приборной панели и мог поворачиваться влево или вправо в зависимости от того, кто осуществлял навигацию. Сигнал GPS и карты, записанные на компакт-дисках, определяли направление движения.

image

В 1998 году компания Garmin представила свою первую портативную навигационную систему StreetPilot GPS. Компания была основана в 1991 году и стала первой компанией, которая ввела GPS-навигацию в общее пользование в том же году.

В 1997 году японская компания Alpine представила систему послепродажного обслуживания, которая также использовала карты на CD-ROM и принимала сигнал GPS, что позволяло любому покупателю автомобиля добавлять их в свой автомобиль. В следующем году Garmin представила свою первую портативную навигационную систему StreetPilot GPS, и в конце концов Garmin заняла видное место на рынке товаров послепродажного обслуживания, совместимых с разными марками автомобилей.

На кончиках пальцев


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

Сам по себе скромный сенсорный экран был создан в 1965 году и появился на свет благодаря работе передового исследовательского подразделения британского Министерства авиации.

image


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

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

Несмотря на то, что эта технология существует уже более десяти лет, первые сенсорные экраны для потребителей появились только в 1982 году в Hewlett-Packard HP-150 персонального компьютера, работающего под управлением операционной системы MS-DOS на 9-дюймовом сенсорном ЭЛТ-экране от Sony. Технология сенсорного экрана была новой, а потому недешевой: 2795 долларов или 7634 доллара с поправкой на инфляцию.

image

Buick разработал Buick Riviera 1986 года в качестве технологического экспоната для General Motors. Ключевой частью этого плана была замена многих элементов управления приборной панели графическим Центром управления.

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

image

В 1986 году Buick Riviera был первым сенсорным экраном, когда-либо поставленным в автомобиль в качестве стандартного оборудования. Он появился на рынке через два года после появления первого потребительского продукта с сенсорным Hewlett-Packard PC.

Согласно документам компании, в ноябре 1980 года (за два года до того, как Hewlett-Packard HP-150 поступил в продажу), менеджеры Buick во Флинте, штат Мичиган, решили, что к 1985 году они выпустят автомобиль с самой передовой электроникой в отрасли. По мере того, как комитет оценивал, какие электронные функции будут предлагаться, сенсорный ЭЛТ-экран разрабатывался Delco Systems дочерней компанией General Motors в Санта-Барбаре, Калифорния. В течение нескольких месяцев, в начале 1981 года, система от GM была продемонстрирована и одобрена Группой Продуктовой Политики GM. AC Spark Plug и Delco Electronics разработали аппаратное обеспечение, в то время как Delco Systems занималась разработкой программного обеспечения. К 1983 году были разработаны спецификации для экрана, и на следующий год эти экраны были установлены в тестовом парке из 100 автомобилей для измерения реакции заказчика.

Графический центр управления (GCC) представлял собой ЭЛТ-экран, покрытый невидимой панелью Mylar, в которой использовались прозрачные проводники, которые были закодированы столбцами и строками для выполнения определенных функций на определенных страницах. Функции каждого переключателя менялись с каждой страницей. Поскольку на разогрев ЭЛТ уходит несколько секунд, цепь GCC начинала прогреваться при касании ручки двери водителя. Когда дверь водителя открывалась и закрывалась, на дисплее появлялся логотип Riviera.

Как только автомобиль был запущен, дисплей переходил на домашнюю страницу, которая удовлетворяла 90% потребностей водителя. Если экрана не касались в течение 30 секунд, он выключался. GCC контролировал автоматический климат-контроль, AM/FM радио, графический эквалайзер и расчеты поездки, а также отображал показания датчиков и диагностическую информацию об автомобиле. Его черный экран и зеленый дисплей теперь кажется антиквариатом, но в то время эта технология была передовой.

Руководители Buick были в восторге, в том числе Кэри Уилсон, который впервые обратил внимание на эту идею в 1980 году. Приходит новое поколение автомобильных электрических систем, и Buick заложил для них фундамент, сказал он в 1986 году.

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

Существование графического центра управления это плохая шутка, написал он в сентябре 1986 года. Система, установленная в Riviera не делает ничего такого, чего не мог бы сделать обычный набор ручек, кнопок и аналоговых инструментов за долю секунды. Его коллега Рич Сеппос согласился. Высокотехнологичный ЭЛТ в Riviera это не скачок вперед, это лишь небольшой шаг.

Несмотря на отрицательные отзывы, Бьюик установил бы GCC и в Reatte 1988-1989 годов до появления модифицированной версии: визуального информационного центр Oldsmobile, был доступен в 1989-1992 годах в Oldsmobile Toronado Trofeo (Riviera имела такую же базовую платформу). 4-дюймовый полноцветный сенсорный экран был сделан компанией Sony, а система могла быть оснащена дополнительным мобильным телефоном Motorola, которым можно было управлять через экран.

image

Навигационная система Alpine на базе CD-ROM aftermarket может быть добавлена к любому автомобилю.

image

Acura представит свою первую навигационную систему на основе жесткого диска в 1996 году Acura 3.5 RL.

В то время как критики высмеивали эти и другие ранние попытки создания систем с сенсорным экраном, новые автомобили (такие как Tesla Model 3) поставляются с сенсорным экраном, содержащим все элементы управления. Таким образом, несмотря на то, что все эти технологии кажутся новыми, наука, подпитывающая их, работала над ними на протяжении десятилетий. Создание сегодняшней консоли Tesla стоит на плечах технологических гигантов.

image

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

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

Подписывайтесь на каналы:
@AutomotiveRu новости автоиндустрии, железо и психология вождения
@TeslaHackers сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla




image

О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

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

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

Читать еще полезные статьи:

Подробнее..

Внедрение зависимостей проще, чем кажется?

27.06.2020 14:19:52 | Автор: admin
Привет, Хабр!

У нас готовится к выходу второе издание легендарной книги Марка Симана, Внедрение зависимостей на платформе .NET



Поэтому сегодня мы решили кратко освежить тему внедрения зависимостей для специалистов по .NET и C# и предлагаем перевод статьи Грэма Даунса, где эта парадигма рассматривается в контексте инверсии управления (IoC) и использования контейнеров

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

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

На протяжении всей карьеры (я специализируюсь на разработке в Net/C#), я привык использовать внедрение зависимостей в его чистейшей форме. При этом я реализовывал DI, вообще не прибегая ни к контейнерам, ни к инверсии управления. Все изменилось совсем недавно, когда мне поставили задачу, в которой без использования контейнеров было не обойтись. Тогда я крепко усомнился во всем, что знал ранее.

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

(Здесь важно отметить: интерфейсы и контейнеры используются только в контексте внедрения зависимостей. Внедрение зависимостей можно реализовать и без интерфейсов/контейнеров, но, в сущности, единственное назначение интерфейсов или контейнеров облегчить внедрение зависимостей).

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

Подготовка


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

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

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

Приложение


Рассмотрим следующий код. Он написан для простого приложения-калькулятора, принимающего два числа, оператор и выводящего результат. (Это простое рабочее приложение для командной строки, поэтому вам не составит труда воспроизвести его как C# Console Application в Visual Studio и вставить туда код, если вы хотите следить за развитием примера. Все должно работать без проблем.)

У нас есть класс Calculator и основной класс Program, использующий его.

Program.cs:

using System;using System.Linq;namespace OfferZenDiTutorial{    class Program    {        static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            var calc = new Calculator();            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }        private static float GetNumber(string message)        {            var isValid = false;            while (!isValid)            {                Console.Write(message);                var input = Console.ReadLine();                isValid = float.TryParse(input, out var number);                if (isValid)                    return number;                Console.WriteLine("Please enter a valid number. Press ^C to quit.");            }            return -1;        }        private static char GetOperator()        {            var isValid = false;            while (!isValid)            {                Console.Write("Please type the operator (/*+-) > ");                var input = Console.ReadKey();                Console.WriteLine();                var operation = input.KeyChar;                if ("/*+-".Contains(operation))                {                    isValid = true;                    return operation;                }                Console.WriteLine("Please enter a valid operator (/, *, +, or -). " +                                  "Press ^C to quit.");            }            return ' ';        }        private static float GetResult(Calculator calc, float number1, float number2,             char operation)        {            switch (operation)            {                case '/': return calc.Divide(number1, number2);                case '*': return calc.Multiply(number1, number2);                case '+': return calc.Add(number1, number2);                case '-': return calc.Subtract(number1, number2);                default:                    // Такого произойти не должно, если с предыдущими валидациями все было нормально                     throw new InvalidOperationException("Invalid operation passed: " +                                                         operation);            }        }    }}

Главная программа запускается, запрашивает у пользователя два числа и оператор, а затем вызывает класс Calculator для выполнения простой арифметической операции над этими числами. Затем выводит результат операции. Вот класс Calculator.

Calculator.cs:

namespace OfferZenDiTutorial{    public class Calculator    {        public float Divide(float number1, float number2)        {            return number1 / number2;        }        public float Multiply(float number1, float number2)        {            return number1 * number2;        }        public float Add(float number1, float number2)        {            return number1 + number2;        }        public float Subtract(float number1, float number2)        {            return number1 - number2;        }    }}

Логирование


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

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

Calculator.cs:

using System.IO;namespace OfferZenDiTutorial{    public class Calculator    {        private const string FileName = "Calculator.log";        public float Divide(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} / {number2}");            return number1 / number2;        }        public float Multiply(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} * {number2}");            return number1 * number2;        }        public float Add(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} + {number2}");            return number1 + number2;        }        public float Subtract(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} - {number2}");            return number1 - number2;        }    }}

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

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

Класс FileLogger


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

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

FileLogger.csh:

using System;using System.IO;namespace OfferZenDiTutorial{    public class FileLogger    {        private const string FileName = "Calculator.log";        private readonly string _newLine = Environment.NewLine;        public void WriteLine(string message)        {            File.AppendAllText(FileName, $"{message}{_newLine}");        }    }}

Теперь все, что касается создания файла логов и записи информации в него обрабатывается в этом классе. Дополнительно получаем и одну приятную мелочь: что бы ни потреблял этот класс, не требуется ставить между отдельными записями пустые строки. Записи должны просто вызывать наш метод WriteLine, а все остальное мы берем на себя. Разве не круто?
Чтобы использовать класс, нам нужен объект, который его инстанцирует. Давайте решим эту проблему внутри класса Calculator. Заменим содержимое класса Calculator.cs следующим:

Calculator.cs:

namespace OfferZenDiTutorial{    public class Calculator    {        private readonly FileLogger _logger;        public Calculator()        {            _logger = new FileLogger();        }        public float Divide(float number1, float number2)        {            _logger.WriteLine($"Running {number1} / {number2}");            return number1 / number2;        }        public float Multiply(float number1, float number2)        {            _logger.WriteLine($"Running {number1} * {number2}");            return number1 * number2;        }        public float Add(float number1, float number2)        {            _logger.WriteLine($"Running {number1} + {number2}");            return number1 + number2;        }        public float Subtract(float number1, float number2)        {            _logger.WriteLine($"Running {number1} - {number2}");            return number1 - number2;        }    }}

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

Внедрение зависимости


Очевидно, ответ на последний вопрос отрицательный!

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

Calculator.cs:

        public Calculator(FileLogger logger)        {            _logger = logger;        }

Вот и все. Больше в классе ничего не меняется.

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

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

Итак, чья же это ответственность?

Как раз того, кто инстанцирует класс Calculator. В нашем случае это основная программа.

Чтобы это продемонстрировать, изменим метод Main в нашем классе Program.cs следующим образом:

Program.cs

  static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            // Следующие две строки изменены            var logger = new FileLogger();            var calc = new Calculator(logger);            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }

Таким образом, требуется изменить всего две строки. Мы не рассчитываем, что класс Calculator инстанцирует FileLogger, это за него сделает Main, а затем передаст ему результат.

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

Расширение возможностей: сделаем другой логгер


Несмотря на вышесказанное, у интерфейсов есть свое место, и по-настоящему они раскрываются именно в связке с Внедрением Зависимостей.

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

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

Вот здесь нам и пригодятся интерфейсы.

Давайте напишем интерфейс. Назовем его ILogger, поскольку его реализацией будет заниматься наш класс FileLogger.

ILogger.cs

namespace OfferZenDiTutorial{    public interface ILogger    {        void WriteLine(string message);    }}

Как видите, он определяет единственный метод: WriteLine, реализованный FileLogger. Сделаем еще шаг и формализуем эти отношения, сделав так, чтобы этот класс официально реализовывал наш новый интерфейс:

FileLogger.cs

public class FileLogger : ILogger

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

Для начала изменим класс Calculator таким образом, чтобы он использовал интерфейс ILogger, а не конкретную реализацию FileLogger:

Calculator.cs

private readonly ILogger _logger;        public Calculator(ILogger logger)        {            _logger = logger;        }

На данном этапе код по-прежнему компилируется и выполняется без всяких проблем. Мы передаем в него FileLogger из главного метода программы, того, который реализует ILogger. Единственное отличие заключается в том, что Calculator не просто не требуется знать, как создавать FileLogger, но и даже логгер какого рода ему выдается.

Поскольку все, что бы вы ни получили, реализует интерфейс ILogger (и, следовательно, имеет метод WriteLine), с практическим использованием проблем не возникает.

Теперь давайте добавим еще одну реализацию интерфейса ILogger. Это будет класс, который ничего не делает при вызове метода WriteLine. Мы назовем его NullLogger, и вот как он выглядит:

NullLogger.cs

namespace OfferZenDiTutorial{    public class NullLogger : ILogger    {        public void WriteLine(string message)        {            // Ничего не делаем в этой реализации        }    }}

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

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

Program.cs

 static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            var logger = new NullLogger(); // Эту строку нужно изменить            var calc = new Calculator(logger);            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }

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

Небольшая оговорка об интерфейсах


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

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

Контейнеры для внедрения зависимостей


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

Знакомьтесь с контейнером для внедрения зависимостей. Он упрощает вам жизнь, но принцип работы такого контейнера может показаться весьма запутанным, особенно, когда вы только начинаете его осваивать. На первый взгляд эта возможность может отдавать некоторой магией.
В данном примере мы воспользуемся контейнером от Unity, но на выбор есть и много других, назову лишь наиболее популярные: Castle Windsor, Ninject. С функциональной точки зрения эти контейнеры практически не отличаются. Разница может быть заметна на уровне синтаксиса и стиля, но, в конечном итоге, все сводится к вашим персональным предпочтениям и опыту разработки (а также к тому, что предписывается в вашей компании!).

Давайте подробно разберем пример с использованием Unity: я постараюсь объяснить, что здесь происходит.

Первым делом вам потребуется добавить ссылку на Unity. К счастью, для этого существует пакет Nuget, поэтому щелкните правой кнопкой мыши по вашему проекту в Visual Studio и выберите Manage Nuget Packages:



Найдите и установите пакет Unity, ориентируйтесь на проект Unity Container:



Итак, мы готовы. Измените метод Main файла Program.cs вот так:

Program.cs

 static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            // Следующие три строки необходимо изменить            var container = new UnityContainer();            container.RegisterType<ILogger, NullLogger>();            var calc = container.Resolve<Calculator>();            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }

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

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



Вероятно, это одна из причуд с той версией пакета Unity, которая была актуальна на момент написания этой статьи. Надеюсь, что у вас все пройдет гладко.
Все дело в том, что при установке Unity также устанавливается неверная версия другого пакета, System.Runtime.CompilerServices.Unsafe. Если вы получаете такую ошибку, то должны вернуться к менеджеру пакетов Nuget, найти этот пакет под вкладкой Installed и обновить его до новейшей стабильной версии:



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

Все начинается со строки var calc = container.Resolve<Calculator>();, поэтому именно отсюда я изложу смысл этого кода в форме диалога контейнера с самим собой: о чем он думает, когда видит эту инструкцию.

  1. Мне задано разрешить что-то под названием Calculator. Я знаю, что это такое?
  2. Вижу, в актуальном дереве процессов есть класс под названием Calculator. Это конкретный тип, значит, у него всего лишь одна реализация. Просто создам экземпляр этого класса. Как выглядят конструкторы?
  3. Хм, а конструктор всего один, и принимает он что-то под названием ILogger. Я знаю, что это такое?
  4. Нашел, но это же интерфейс. Мне вообще сообщалось, как его разрешать?
  5. Да, сообщалось! В предыдущей строке сказано, что, всякий раз, когда мне требуется разрешить ILogger, я должен передать экземпляр класса NullLogger.
  6. Окей, значит тут есть NullLogger. У него непараметризованный конструктор. Просто создам экземпляр.
  7. Передам этот экземпляр конструктору класса Calculator, а затем верну этот экземпляр к var calc.

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

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

Вот и все. Ничего таинственного и особо мистического.

Другие возможности


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

Если вы хотите сами поэкспериментировать с примерами, приведенными в этой статье: смело клонируйте с Гитхаба репозиторий, в котором они выложены github.com/GrahamDo/OfferZenDiTutorial.git. Там семь веток, по одной на каждую рассмотренную нами итерацию.
Подробнее..

Перевод Учебный проект на Python интерфейс в 40 строк кода (часть 2)

03.07.2020 08:04:12 | Автор: admin
image

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

Streamlit


Streamlit это веб-фреймворк, предназначенный для исследователей данных для простого развертывания моделей и визуализаций с использованием Python. Это быстро и минималистично, а также красиво и удобно. Есть встроенные виджеты для пользовательского ввода, такие как загрузка изображений, ползунки, ввод текста и другие знакомые элементы HTML, такие как флажки и переключатели. Всякий раз, когда пользователь взаимодействует с потоковым приложением, сценарий python перезапускается сверху вниз, что важно учитывать при рассмотрении различных состояний вашего приложения.
Вы можете установить Streamlit с помощью pip:

pip install streamlit


И запустите streamlit в скрипте Python:

streamlit run app.py


Варианты использования


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

Во-первых, давайте создадим пользовательский интерфейс для загрузчика изображений и возможность использовать изображение по умолчанию. Мы можем добавить вывод текста, используя такие функции, как st.write() или st.title(). Мы храним динамически загруженный файл, используя функцию st.file_uploader(). Наконец, st.checkbox() вернет логическое значение в зависимости от того, установил ли пользователь флажок.

import streamlit as stimport cv2import matplotlib.pyplot as pltimport numpy as npimport mazest.title('Maze Solver')uploaded_file = st.file_uploader("Choose an image", ["jpg","jpeg","png"]) #image uploaderst.write('Or')use_default_image = st.checkbox('Use default maze')


Результат:

image

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

if use_default_image:    opencv_image = cv2.imread('maze5.jpg')elif uploaded_file is not None:    file_bytes = np.asarray(bytearray(uploaded_file.read()), dtype=np.uint8)    opencv_image = cv2.imdecode(file_bytes, 1)


Как только изображение загружено, мы хотим показать изображение, размеченное с начальной и конечной точками. Мы будем использовать ползунки, чтобы позволить пользователю переместить эти точки. Функция st.sidebar() добавляет боковую панель на страницу, а st.slider() принимает числово в пределах определенного минимума и максимума. Мы можем определить минимальное и максимальное значения слайдера динамически в зависимости от размера нашего изображения лабиринта.

if opencv_image is not None:    st.subheader('Use the sliders on the left to position the start and end points')    start_x = st.sidebar.slider("Start X", value= 24 if use_default_image  else 50, min_value=0, max_value=opencv_image.shape[1], key='sx')    start_y = st.sidebar.slider("Start Y", value= 332 if use_default_image  else 100, min_value=0, max_value=opencv_image.shape[0], key='sy')    finish_x = st.sidebar.slider("Finish X", value= 309 if use_default_image  else 100, min_value=0, max_value=opencv_image.shape[1], key='fx')    finish_y = st.sidebar.slider("Finish Y", value= 330 if use_default_image  else 100, min_value=0, max_value=opencv_image.shape[0], key='fy')    marked_image = opencv_image.copy()    circle_thickness=(marked_image.shape[0]+marked_image.shape[0])//2//100 #circle thickness based on img size    cv2.circle(marked_image, (start_x, start_y), circle_thickness, (0,255,0),-1)    cv2.circle(marked_image, (finish_x, finish_y), circle_thickness, (255,0,0),-1)    st.image(marked_image, channels="RGB", width=800)


image

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

После того, как пользователь определил начальную и конечную позиции, мы хотим кнопку, чтобы решить лабиринт и отобразить решение. Элемент st.spinner () отображается только во время работы его дочернего процесса, а вызов st.image () используется для отображения изображения.

if marked_image is not None:    if st.button('Solve Maze'):        with st.spinner('Solving your maze'):            path = maze.find_shortest_path(opencv_image,(start_x, start_y),(finish_x, finish_y))        pathed_image = opencv_image.copy()        path_thickness = (pathed_image.shape[0]+pathed_image.shape[0])//200        maze.drawPath(pathed_image, path, path_thickness)        st.image(pathed_image, channels="RGB", width=800)


image

Кнопка

image

Вывод решения

Вывод


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

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

image

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



Читать еще


Подробнее..

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

03.07.2020 16:05:03 | Автор: admin
Многие убеждены, что область Human Computer Interaction (HCI или человеко-компьютерное взаимодействие) сводится только к проектированию сайтов или приложений, а основная задача специалиста удовлетворить пользователей, увеличивая на несколько пикселей кнопку лайка. В посте мы хотим показать, что это совсем не так, и рассказать, что происходит в HCI на стыке с исследованиями машинного обучения и искусственного интеллекта. Возможно, это позволит читателям посмотреть на эту область с новой для себя стороны.

Для обзора мы взяли труды конференции CHI: Conference on Human Factors in Computing Systems за 10 лет, и с помощью NLP и анализа сетей социтирования посмотрели на темы и области на пересечении дисциплин.




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

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

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

В первую очередь мы расскажем, что происходит в таких областях, как xAI и iML (eXplainable Artificial Intelligence и Interpretable Machine Learning) со стороны интерфейсов и пользователей, а также как в HCI изучают когнитивные аспекты работы специалистов data science, и приведем примеры интересных работ последних лет в каждой области.

xAI и iML


Методы машинного обучения интенсивно развиваются и что важнее с точки зрения обсуждаемой области активно внедряются в автоматизированное принятие решений. Поэтому исследователи все чаще обсуждают вопросы: как пользователи, не являющиеся специалистами в машинном обучении, взаимодействуют с системами, где подобные алгоритмы применяются? Один из важных вопросов такого взаимодействия: как сделать, чтобы пользователи доверяли решениям, принятым на основе моделей? Поэтому с каждым годом все более горячей становится тематика интерпретируемого машинного обучения (Interpretable Machine Learning iML) и объяснимого искусственного интеллекта (eXplainable Artificial Intelligence XAI).

При этом, если на таких конференциях, как NeurIPS, ICML, IJCAI, KDD, обсуждают сами алгоритмы и средства iML и XAI, на CHI в фокусе оказываются несколько тем, связанных с особенностями дизайна и опытом использования этих систем. Например, на CHI-2020 этой тематике были посвящены сразу несколько секций, включая AI/ML & seeing through the black box и Coping with AI: not agAIn!. Но и до появления отдельных секций таких работ было достаточно много. Мы выделили в них четыре направления.

Дизайн интерпретирующих систем для решения прикладных задач


Первое направление это дизайн систем на основе алгоритмов интерпретируемости в различных прикладных задачах: медицинских, социальных и т. д. Такие работы возникают в очень разных сферах. Например, работа на CHI-2020 CheXplain: Enabling Physicians to Explore and Understand Data-Driven, AI-Enabled Medical Imaging Analysis описывает систему, которая помогает врачам исследовать и объяснять результаты рентгенографии органов грудной клетки. Она предлагает дополнительные текстовые и визуальные пояснения, а также снимки с таким же и противоположным результатом (поддерживающие и противоречащие примеры). Если система предсказывает, что на рентгенографии видно заболевание, то покажет два примера. Первый, поддерживающий, пример это снимок легких другого пациента, у которого подтверждено это же заболевание. Второй, противоречащий, пример это снимок, на котором заболевания нет, то есть снимок легких здорового человека. Основная идея сократить очевидные ошибки и уменьшить число обращений к сторонним специалистам в простых случаях, чтобы ставить диагноз быстрее.


CheXpert: автоматизированное выделение областей + примеры (unlikely vs definitely)



Разработка систем для исследования моделей машинного обучения


Второе направление разработка систем, которые помогают интерактивно сравнивать или объединять несколько методов и алгоритмов. Например, в работе Silva: Interactively Assessing Machine Learning Fairness Using Causality на CHI-2020 была представлена система, которая строит на данных пользователя несколько моделей машинного обучения и предоставляет возможность их последующего анализа. Анализ включает построение причинно-следственного графа между переменными и вычисление ряда метрик, оценивающих не только точность, но и честность (fairness) модели (Statistical Parity Difference, Equal Opportunity Difference, Average Odds Difference, Disparate Impact, Theil Index), что помогает находить перекосы в предсказаниях.


Silva: граф связей между переменными + графики для сравнения метрик честности + цветовое выделение влиятельных переменных в каждой группе

Общие вопросы интерпретируемости моделей


Третье направление обсуждение подходов к задаче интерпретируемости моделей в целом. Чаще всего это обзоры, критика подходов и открытые вопросы: например, что понимать под интерпретируемостью. Здесь хотелось бы отметить обзор на CHI-2018 Trends and Trajectories for Explainable, Accountable and Intelligible Systems: An HCI Research Agenda, в котором авторы рассмотрели 289 основных работ, посвященных объяснениям в искусственном интеллекте, и 12 412 публикаций, цитирующих их. С помощью сетевого анализа и тематического моделирования они выделили четыре ключевых направления исследований 1) Intelligent and Ambient (I&A) Systems, 2) Explainable AI: Fair, Accountable, and Transparent (FAT) algorithms and Interpretable Machine Learning (iML), 3) Theories of Explanations: Causality & Cognitive Psychology, 4) Interactivity and Learnability. Кроме того, авторы описали основные тренды исследований: интерактивное обучение и взаимодействие с системой.

Пользовательские исследования


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

Инструментов и алгоритмов интерпретации появилось очень много, поэтому возникает вопрос: как понять, какой же алгоритм выбрать? В работе Questioning the AI: Informing Design Practices for Explainable AI User Experiences как раз обсуждаются вопросы мотивации использования объясняющих алгоритмов и выделяются проблемы, которые при всем многообразии методов еще не решены в достаточной степени. Авторы приходят к неожиданному выводу: большинство существующих методов построены так, что отвечают на вопрос почему (почему у меня такой результат), в то время как пользователям для принятия решений нужен еще и ответ на вопрос почему нет (почему не другой), а иногда что сделать, чтобы результат изменился.

В работе говорится также о том, что пользователям нужно понимать, каковы границы применимости методов, какие у них есть ограничения и это нужно явно внедрять в предлагаемые инструменты. Более ярко эта проблема показана в статье Interpreting Interpretability: Understanding Data Scientists' Use of Interpretability Tools for Machine Learning. Авторы провели небольшой эксперимент со специалистами в области машинного обучения: показали им результаты работы нескольких популярных инструментов для интерпретации моделей машинного обучения и предложили ответить на вопросы, связанные с принятием решения на основе этих результатов. Оказалось, что даже специалисты слишком доверяют подобным моделям и не относятся к результатам критически. Как любой инструмент, объясняющие модели можно использовать неправильно. При разработке инструментария важно учитывать это, привлекая накопленные знания (или специалистов) в области человеко-компьютерного взаимодействия, чтобы учитывать особенности и потребности потенциальных пользователей.

Data Science, Notebooks, Visualization


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

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

Визуализация неопределенности


Визуализация неопределенности одна из особенностей, которые отличают научную графику от презентационной и бизнес-визуализации. Довольно долго ключевым в последних считался принцип минималистичности и фокуса на основных трендах. Однако это приводит к чрезмерной уверенности пользователей в точечной оценке величины или прогноза, что может быть критичным, особенно, если мы должны сравнивать прогнозы с разной степенью неопределенности. Работа Uncertainty Displays Using Quantile Dotplots or CDFs Improve Transit Decision-Making анализирует, насколько способы визуализации неопределенности в предсказании для точечных графиков и кумулятивных функций распределения помогают пользователям принимать более рациональные решения на примере задачи оценки времени прибытия автобуса по данным мобильного приложения. Что особенно приятно, один из авторов поддерживает пакет ggdist для R с различными вариантами визуализации неопределенности.


Примеры визуализации неопределенности (https://mjskay.github.io/ggdist/)

Однако часто встречаются и задачи визуализации возможных альтернатив, например, для последовательностей действий пользователя в веб-аналитике или аналитике приложений. Работа Visualizing Uncertainty and Alternatives in Event Sequence Predictions анализирует, насколько графическое представление альтернатив на основе модели Time-Aware Recurrent Neural Network (TRNN) помогает экспертам принимать решения и доверять им.

Сравнение моделей


Не менее важный, чем визуализация неопределенности, аспект работы аналитиков сравнение того, как часто скрытый выбор исследователем разных подходов к моделированию на всех его этапах может вести к различным результатам анализа. В психологии и социальных науках набирает популярность предварительная регистрация дизайна исследования и четкое разделение эксплораторных и конфирматорных исследований. Однако в задачах, где исследование в большей степени основано на данных, альтернативой могут стать инструменты, позволяющие оценить скрытые риски анализа за счет сравнения моделей. Работа Increasing the Transparency of Research Papers with Explorable Multiverse Analyses предлагает использовать интерактивную визуализацию нескольких подходов к анализу в статьях. По сути, статья превращается в интерактивное приложение, где читатель может оценить, что изменится в результатах и выводах, если будет применен другой подход. Это кажется полезной идеей и для практической аналитики.

Работа с инструментами организации и анализа данных


Последний блок работ связан с исследованием того, как аналитики работают с системами, подобными Jupyter Notebooks, которые стали популярным инструментом организации анализа данных. Статья Exploration and Explanation in Computational Notebooks анализирует противоречия между исследовательскими и объясняющими целями, изучая найденные на Github интерактивные документы, а в Managing Messes in Computational Notebooks авторы анализируют, как эволюционируют заметки, части кода и визуализации в итеративном процессе работы аналитиков, и предлагают возможные дополнения в инструменты, чтобы поддерживать этот процесс. Наконец, уже на CHI 2020 основные проблемы аналитиков на всех этапах работы, от загрузки данных до передачи модели в продакшн, а также идеи по улучшению инструментов обобщены в статье Whats Wrong with Computational Notebooks? Pain Points, Needs, and Design Opportunities.


Преобразование структуры отчетов на основе логов выполнения (https://microsoft.github.io/gather/)

Подводя итог


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

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

Никаких кликов интервью с Джессикой Дин о командной строке, автоматизации и DevOps

06.07.2020 12:10:38 | Автор: admin


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


Осенью на нашей конференции DevOops выступала Джессика Дин. Она удивительно разносторонний человек в отношении платформ: обожает Linux, постоянно пользуется Mac и при этом работает в Microsoft. И она очень любит автоматизацию, скрипты и отказ от мышки настолько, что в её дотфайлах уже сотни коммитов.


В трансляции DevOops мы с Михаилом Дружининым (xomyakus) поспрашивали её и об использовании терминала, и о совмещении миров Windows/Linux/Mac, а поскольку дело было на девопс-конференции, к концу разговор свернул ещё и в сторону Kubernetes. А сейчас, прямо перед новым онлайновым DevOops, мне захотелось перевести это интервью на русский, чтобы оно было и в текстовом формате.


Текстовый вариант чуть сокращённый, если предпочитаете посмотреть исходное англоязычное видео, оно вот:



Евгений Трифонов: Я заглянул в твои дотфайлы на GitHub и оказался впечатлён


Джессика Дин: Большое спасибо! Да, это интересный проект, и он продолжает разрастаться, я постоянно добавляю к нему разное. Я фанатка автоматизации, штук, упрощающих любой процесс. Мои дотфайлы так или иначе связаны с этим. Их можно использовать и в Linux, и в Windows Subsystem for Linux (хоть WSL1, хоть WSL2), и на macOS. Они обращаются к 17 разным опенсорсным инструментам. Основная причина, по которой я всем этим занялась упрощение моего рабочего процесса как с точки зрения разработки, так и с точки зрения эксплуатации.


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


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


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


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


Если речь о моей собственной системе, то я установлю всё, что мне может понадобиться, со всеми зависимостями. Но если я использую чужую, то мне нужен только удобный CLI с комфортным интерфейсом я использую тему для zsh Powerlevel9k (да, я знаю, что уже появился Powerlevel10k), у меня на экране много полезной информации. И сейчас я подумала, что мне нужна установочная опция, где устанавливаешь только этот интерфейс без всех остальных зависимостей. Сейчас главное бутылочное горлышко здесь это время, которое требуется на установку всего.


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


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


Джессика: Порой бывает! У меня даже есть пост со словами Down the Rabbit Hole в заголовке.


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


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


Но ещё есть любопытство, потому что все мы инженеры: Но я ведь уже начал, я не могу сдаться!


Михаил Дружинин: И как тебе удаётся себя остановить?


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


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


Евгений: У вас там целое сообщество людей, которые смотрят дотфайлы друг друга?


Джессика: Так и есть! Есть треды на Reddit об этом, есть видео в сети.


Ещё меня как-то упомянули в таком треде на Reddit как человека, который работает в Microsoft, пишет дотфайлы под Linux и macOS, выступает о Linux, получал и сертификаты Apple, и звание Windows MVP. Это было собрано в треде под грифом Мы не понимаем. Но я просто люблю работать с другими инженерами и мне неважно, на какой платформе кто работает! Я вношу свой вклад в сообщество dotfiles, до этого делала то же самое с PowerShell (ещё до выхода PowerShell Core, так что это было только для Windows). Сейчас забавно, когда мне приходится снова писать скрипты на PowerShell, столько отличий. Я просто люблю тусоваться в разных сообществах, и dotfiles одно из них.


Евгений: Интересно, что ты любишь Linux и работаешь в Microsoft. В этом нет противоречия, но, наверное, люди часто удивляются?


Джессика: Да! Потому что так было не всегда. Я каким-либо образом связана с Microsoft уже более 10 лет. Изначально работала на их подрядчика. И тогда была совсем другая эпоха с совсем другим руководством компании. Когда я пришла в кампус, у меня были iPhone и Mac и кто-то меня окликнул: Ты случайно не из тех, у кого Mac и iPhone? И я такая, пряча свой рюкзак и комп: Кто-нибудь! Срочно дайте мне Windows Phone! Сбегайте в музей! Я не хочу быть белой вороной! Даже в команде, с которой я работала, подшучивали, потому что меня все знали как любительницу Linux и Apple, хотя в то же время у меня был статус Windows MVP и сертификация.


Я тогда по работе занималась примерно тем же, что и сейчас делаю как advocate, но тогда делала это в онлайне мы называли это вовлечением через социальные сети. Моя работа заключалась в том, чтобы взаимодействовать с сообществом на популярных в IT интернет-ресурсах вроде Reddit и Spiceworks, общаться с теми, у кого были технические вопросы. Это было во времена Microsoft Deployment Toolkit и SCCM. Я помогала людям в этих сообществах, а в то же время была инженером интеграции систем Linux и чинила компьютеры Apple. Так что я всегда пересекала границы платформ. Но тогда это было нетипично.


Сейчас я в Microsoft уже почти 4 года и то, как изменилось направление внутреннего и внешнего развития, взрывает мне мозг каждый день. 10 лет назад я была полезна, работая на подрядчика Microsoft, но из меня вышла бы не очень хорошая сотрудница непосредственно для Microsoft, потому что я любила работать на Linux и Mac, и не собиралась от них отказываться. И 4 года назад они наняли меня после моего выступления о линуксовом веб-сервере. Я такая: Вы в курсе, что я только что говорила про Linux, да? Так что конфликта тут больше нет, хотя и есть определённое прошлое. Это уже совсем другой Microsoft!


Евгений: А что для такого человека, как ты, означало появление Windows Subsystem for Linux? Перевернуло ли это всю твою жизнь? :)


Джессика: Ну, моя главная система для разработки это по-прежнему Mac. Но у меня дома есть и Surface Book. И это действительно сказывается особенно теперь, с WSL 2 и опенсорсным Terminal. У меня может быть и PowerShell, и Ubuntu, и Fedora, и любые другие дистрибутивы, и я могу настраивать разные профили. Я работала с командой WSL с момента его появления.


Мой коллега, Скотт Хансельман, шутил, что он провёл нагрузочное тестирование моего блога, ретвитнув один из моих постов пару лет назад, когда у Windows 10 вышло Fall Creators с обновлением WSL. Шутка была в том, что в блог пришло так много читателей, что он упал и мне пришлось его поднимать. Это был пост о том, как можно взять терминал, дотфайлы, о которых мы говорили, и сделать так, чтобы на WSL всё выглядело идентично тому, что я запускаю на Mac и Ubuntu.


Это взорвало людям мозг. И до сих пор взрывает мозг мне! Мне не пришлось вносить никаких изменений. Код, который я использовала на Ubuntu такой же, какой я использовала на WSL. Поэтому у моих дотфайлов сейчас всего две ветки одна из них называется "WSL", но работает и на Linux, а другая для macOS. Я до сих пор влюбляюсь в свою работу, просто глядя на направление, в котором мы двигаемся. Объединение разработчиков всех платформ.


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


Джессика: Это правда, особенно в отношении CI/CD-пайплайнов я работаю ещё в DevOps-команде, занимаюсь автоматизацией скриптами, и там могу делать проверки вроде открывается ли такой-то URL. И в моём докладе здесь, на DevOops, есть пример использования curl. Чтобы протестировать такие вещи, я сначала выполняю их локально в терминале до того, как помещу в пайплайн. А в итоге я ощущаю, что могу выполнять такие задачи эффективнее, потому что для меня становится естественным выполнять их из командной строки.


Я уже говорила про мои дотфайлы, что всегда хочу видеть в терминале определённую информацию, и в том числе хочу знать мои внутренний и внешний IP-адреса. Некоторые люди, чтобы узнать свой IP, идут на сайт вроде https://whatismyipaddress.com/. А у меня это просто часть терминала.


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


Михаил: Как ты к этому пришла? Как долго ты шла к осознанию, что печатать быстрее?


Джессика: Примерно 5-6 лет. Работая одновременно и с Linux, и с технологиями Microsoft, я деплоила приложения и с IIS, где было очень много кликанья, и с Linux, где было сплошное печатание. Каждый раз, когда разворачивала на Linux всё шло без проблем, а на IIS всё было гораздо сложнее. В итоге я начала писать скрипты на PowerShell так я ещё дальше зашла в автоматизацию. В общем, это был долгий путь.


Михаил: Какую часть своего рабочего дня ты проводишь в терминале сейчас?


Джессика: Terminal у меня всегда запущен, он всегда открыт в фоне. Я бы сказала, что непосредственно в нём не меньше 50 времени, возможно, больше. А поскольку я пользуюсь DevOps-инструментами, повсюду код: в Codefresh и Azure DevOps Serviсes YAML, в Jenkins Groovy Поэтому у меня ощущение, что я всё время живу либо в командной строке, либо в VS Code, и терминал всегда открыт.


Михаил: Ещё один вопрос, чтобы закрыть эту тему. Vim или Emacs?


Джессика: Vim.


Я знаю некоторых, кто предпочитает Pico, Emacs, nano Не могу представить, зачем может понадобиться работать в nano Я из тех сумасшедших, кто за Vim. А вы как? Vim или Emacs? И в tmux что используете, Ctrl+A или дефолтное Ctrl+B?


Михаил: Vim, Ctrl+B.


Евгений: Vim. К вопросу о нём: другой спикер Себастиан Дашнер сегодня рассказал нам, использует плагин Vimium в браузере и IdeaVim в IntelliJ IDEA. Ты чем-то подобным пользуешься?


Джессика: Нет. Самое нердовское, что я использую это плагин NERDTree. Он добавляет мне файловый менеджер слева и я могу нажать Ctrl+N, чтобы этот менеджер появлялся и скрывался. Ну и ещё я использую таблицу стилей в Vim. У меня есть моя обычная таблица стилей со шрифтами и цветными штуками для терминала, а в Vim свое цветовое оформление. Вроде бы сейчас использую схему wombat Ну, это всё в открытом доступе, можете сами проверить.


Евгени: Мне хочется делать как можно больше с клавиатуры, но хватает ситуаций, когда всё-таки берусь за мышку/тачпэд. А когда идёшь по жизни с девизом #noclickyclicky, какие сценарии могут вынудить всё-таки оторваться от клавиатуры?


Джессика: Мы же уже говорили про DevOps. Если я демонстрирую Azure DevOps и показываю общую картину того, как он работает (а это, по сути, система запуска задач), я открываю то, что мы называем визуальным редактором. Там список задач без всякого YAML, и я пользуюсь мышкой, чтобы его показать В общем, пользуюсь мышью для навигации в браузере, но когда делаю что-то с кодом, мои руки на клавиатуре.


Михаил: Вчера на BOF-сессии о будущем Kubernetes говорили как раз о том, что происходит переход к кликам в браузере, и больше не надо возиться с YAML, больше не нужно быть YAML-разработчиком, спасибо и на этом


Джессика: Прямо как с табуляцией и пробелами!


Михаил: GitHub также выпустил GitHub Actions он тоже визуальный с кликами. Что ты думаешь об этом направлении? Мне кажется, люди так позабудут о клавиатуре.


Джессика: Возможно, это просто говорит моя страсть к командной строке, но если вспомнить, как всё развивалось в последние 10-15 лет, мне кажется, что она никуда не денется.


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


Михаил: Сделать конфигурацию в UI, потом экспортировать в некий код, а потом продолжить что-то с ним делать.


Джессика: Потому что так я могу его ещё и проверить. Я могу разместить его вместе с моим исходным кодом, с моим приложением...


Михаил: посмотреть diff.


Джессика: Да, особенно. Если я собираюсь обновить мой пайплайн, мне нужно посмотреть разницу, что я изменила, особенно если пайплайн сломается. Мне нужна история. Я не уверена, что мы когда-нибудь отойдём от кода. Да, мы будем улучшать и упрощать его, в этом основная цель того же Kubernetes. Он был создан чтобы упрощать. Helm был создан, чтобы упрощать упрощённое. Есть другие инструменты такие как Draft и Skaffold, которые были сделаны, чтобы упростить и его.


В Microsoft у нас есть Azure Dev Spaces, который, судя по роадмапу, в будущем будет работать даже вне Azure, и он был сделан, чтобы работать с ещё большим уровнем абстракции, когда тебе не нужно беспокоиться про Docker или Kubernetes. У тебя просто может быть изолированная песочница. Как разработчице мне не нужно что-либо настраивать и мне не нужно иметь дело с кодом. Мы постоянно работаем над тем, чтобы упростить простое. Мне кажется, мы продолжим двигаться в этом направлении.


Михаил: Как ты думаешь, каким будет следующий конкретный уровень упрощения Kubernetes? На что бы ты поставила?


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


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


Не всё нужно разбирать до такого мелкого уровня. Не всё надо запускать в Kubernetes. Люди говорят: Kuberenetes во все поля! Зачем? Келси Хайтауэр как-то твитнул, что лучшая часть понимания контейнеров и будущего направления их развития не в том, чтобы понимать, как ими пользоваться, а в том, чтобы понимать, когда ими пользоваться не надо. Мне кажется, это то направление, в котором нам нужно двигаться дальше.


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


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


Другой мой коллега, крупная фигура в Go коммьюнити, Эрик Сент-Мартин, известен своим высказыванием: Kubernetes это не Та Самая Вещь. Это вещь, которая поможет нам достигнуть следующей вещи, а потом та даст добраться до следующей. Это вечно продолжается. Но мы сможем понять, как попасть дальше, только если будем понимать, зачем что-то нам нужно, а почему оно нам не нужно.


Евгений: Вот на этом и остановимся, потому что время на интервью закончилось. Спасибо за ответы!


Уже сегодня в 17:00 стартует новая конференция DevOops: в этот раз в онлайне и пятидневная. Там без слова Kubernetes, конечно, тоже не обойдётся! А ещё будут легенда DevOps Джон Уиллис, ряд докладов про DevOps как культуру, любимец публики Барух Садогурский и многое другое смотрите полную программу, чтобы понять, сколько там актуального лично для вас.
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru