Заметки Андрея Романова
1.3K subscribers
40 photos
100 links
Разработка интерфейсов, дизайн, программирование и всё остальное. Вопросы, пожелания, комментарии — @andrew_r

http://andrew-r.ru
Download Telegram
«Мораль истории такова: механизм автоматической вставки точек с запятыми (ASI) предназначен для исправления синтаксических ошибок. Если вы начнёте программировать, опираясь на него как на универсальное правило вставки точек с запятой на месте перевода строки, вы облажаетесь».
Брендан Айк объясняет, почему нужно ставить точки с запятыми в JS-коде — https://brendaneich.com/2012/04/the-infernal-semicolon/
Из переводов «Питера» можно мемы делать
Два часа ночи. Самое время рассказать, как сделать уведомления доступными — https://github.com/andrew--r/ui-developer-tips/tree/master/tips/008-alerts-accessibility
Тед Дзюба о трёх инструментах инженера (http://widgetsandshit.com/teddziuba/2010/12/the-3-basic-tools-of-systems-engineering.html)

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

1. Деньги
Лучший инструмент для решения задач, потому что экономит время и не требует написания кода. Чаще всего применяется для решения проблем масштабируемости и производительности.

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

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

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

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

const numberFormatter = new Intl.NumberFormat();

numberFormatter.format(12345.67); // -> 12 345,67


По умолчанию NumberFormat использует правила системной локали. При необходимости можно указать нужную локаль: new Intl.NumberFormat('en-US'). Вторым аргументом передаются опции вроде минимального/максимального количества знаков после запятой, подробнее в документации.

Intl поддерживается начиная с IE 11 и Safari 10, на мобильных поддержка хуже, поэтому нужно при открытии страницы проверять поддержку и при её отсутствии подгружать полифил.

Проще всего использовать сервис Polyfill.io от Financial Times:

<script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=Intl.~locale.en"></script>


Polyfill.io проверяет по юзерагенту, какие фичи не поддерживает браузер, и отдаёт полифилы только для них.
Как описывать состояние загружаемых данных — https://github.com/andrew--r/ui-developer-tips/tree/master/tips/009-data-state
В Google Fonts добавили новую кайфовую антикву Spectral с поддержкой кириллицы — https://design.google/library/spectral-new-screen-first-typeface/
Любая статья становится на порядок круче, если добавить в неё интерактивности, как, например, в этом введении в квантовые вычисления — http://davidbkemp.github.io/QuantumComputingArticle/
Сегодня открылся шестой набор в ШРИ Яндекса: https://academy.yandex.ru/events/frontend/shri_msk-2018/

Нынешнее тестовое задание гораздо сложнее, интереснее и цельнее того, которое я делал год назад. Год назад тестовое делилось на три разные задачи: сверстать телепрограмму, написать JS-библиотеку для управления школой, починить и доработать написанный кем-то сервис-воркер. В этом году тестовое всё также делится на три задачи, но теперь они связаны друг с другом: сперва нужно доработать чужой серверный код, затем сверстать пару страничек, а в конце связать бэкенд и вёрстку, получив на выходе сервис для бронирования переговорок в виде SPA.
ВК на форме входа используют Credentials Management API для быстрой авторизации: пользователь кликает по полю логина, открывается системное окно с сохранёнными аккаунтами, при выборе аккаунта автоматически происходит вход — всего в два клика.

Технически это реализуется довольно просто (опустил проверку на поддержку этой фичи):


loginFieldNode.addEventListener('click', () => {
navigator.credentials
.get({ password: true })
.then((creds) => {
if (creds) {
logIn({
id: creds.id,
password: creds.password
});
}
})
});


Документация — https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer
Цветовое кодирование математических выражений может здорово улучшить их понимание — https://betterexplained.com/articles/colorized-math-equations/
Раньше я думал, что создавать новые продукты нужно исходя из их целевой аудитории. Такое понимание сложилось ещё пару лет назад после чтения каких-то мутных статей в интернете. В них советовали составить портрет типичного представителя целевой аудитории: например, делаем трекер задач для менеджера, которому 30 лет, он работает в веб-студии, воспитывает дочь и по утрам выгуливает собаку.

На самом деле всё это полный булшит: делая продукт, нужно исходить из решаемой задачи/проблемы, а не из примерного портрета пользователя. Такой подход к разработке продуктов описан фреймворком Jobs-to-be-Done, о котором есть целая книжка от Интеркома. Для поверхностного знакомства с подходом можно прочесть введение в Jobs-to-be-Done от Анны Булдаковой.
​​Закон Хика

Чем больше вариантов выбора, тем больше времени нужно на принятие решения.

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

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

Подробнее о том, на какие метрики влияет закон Хика и как его применять в веб-дизайне — https://www.interaction-design.org/literature/article/hick-s-law-making-the-choice-easier-for-users.
Вечерняя инфографика: как блокировка ВК на Украине отразилась на статистике Форвеба
Ещё одна инфографика о том, что такое степень доктора наук — http://matt.might.net/articles/phd-school-in-pictures/
Утилитарные функции

В программировании есть два подхода. Первый — не использовать утилитарные функции и каждый раз заново писать код, решающий типичную задачу вроде группировки элементов массива. Второй — максимально использовать уже написанные утилитарные функции и выносить повторяющийся код в новые. К большому сожалению, в джаваскрипте довольно скудная стандартная библиотека, что бы ни говорили сторонники первого подхода («зачем тебе лодаш, если forEach, map и filter уже давным-давно реализованы нативно?»). Из-за этого приходится подключать сторонние библиотеки или писать свои велосипеды, что, конечно, плохо.

Тем не менее, мне ближе второй подход, потому что:
— утилитарные функции позволяют максимально сконцентрироваться на задаче и не отвлекаться на мелочи вроде написания очередного редьюса;
— утилитарные функции лучше выражают намерения программиста: flatten, pluck или chunk выглядят куда содержательнее, чем array.reduce((result, item) => /* какой-то код */);
— каждое дублирование кода вместо использования утилитарной функции повышает вероятность ошибки и требует дополнительных тестов.