PHP Intl. Правильная транслитерация кириллицы

PHP Intl. Правильная транслитерация кириллицы

Современные фреймворки предоставляют готовый функционал в составе библиотек или хелперов для работы с библиотекой ICU (http://site.icu-project.org/home) через API Intl.

Такой функционал необходим для поддержки интернационализации разрабатываемого веб-сервиса. На основе указанной локали могут устанавливаться форматы отображения валют, времени и даты, а также подбираться настройки для инициализации транслитераторов (https://www.php.net/class.transliterator).

В разделе «Телеграм-каналы (https://chulakov.ru/notes)» сайта Студии во время автоматического импорта постов из наших каналов производится транслитерация названий заметок для формирования ЧПУ (https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_URL).

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

Например, уникальная часть URL заметки (https://chulakov.ru/notes/development/php-8-pocti-novogodnij-podarok) про релиз PHP 8 после транслитерации имела вид php-8-pocti-novogodnij-podarok. Замена некоторых букв произошла некорректно.

Для того чтобы транслитерация кириллицы производилась по традиционным правилам, необходимо произвести конфигурацию объекта-транслитератора (https://www.php.net/manual/ru/transliterator.create.php), передав следующее значение параметра $id:

Russian-Latin/BGN; Any-Latin; Latin-ASCII; NFD; [:Nonspacing Mark:] Remove; NFC;

После такой конфигурации результат преобразования наименования заметки изменится на php-8-pochti-novogodniy-podarok.

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

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

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

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

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

И у нас не получилось.

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

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

Но и это еще не все!

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

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

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

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

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

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

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

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

Несколько мыслей команде.

Благодарность командам, в которых мы были и радость нового смысла в командах — в которых мы будем собой.

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

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

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

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

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

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

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

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

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

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

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

Как все успевать

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

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

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

Зачем?

Боюсь, тут не обойтись без предыстории.

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


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

Мне очень нравилась тусоваться на занятиях и рассуждать по поводу UX, но с учебой я конкретно ложанул. В первом семестре мы работали над личными проектами и я серьезно застрял на уровне идеи — и когда все уже отрисовывали UI, я все ещё решал какая механика у моего приложения. Все это привело к тому, что на защите я с треском провалился и получил трояк. Тогда мои глаза открылись — как так! Неужели я хуже вон тех ребят? Да не может быть!

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

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

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

В итоге первый проект, про городские исследования, был похож на молниеносную войну. За 1,5 месяца мы прокопали тему, нашли интересное решение и неплохо его презентовали — в итоге единственная пятерка в группе.

Реванш за тройку и закрытый гештальт.

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

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

Так как же все успевать?

Как в и любом деле главное захотеть. Толчком может послужить злость, как в моем случае. Много хотеть, ничего не успевать, злиться на себя и все таки делать.

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

Иначе для чего вообще бросать себе вызов?

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

let el = document.querySelector(".someClass");
el.innerText // текстовое содержимое
el.innerHTML // HTML-разметка содержимого
el.outerHTML // полная HTML-разметка
el.offsetWidth // ширина, аналогично Height
el.offsetLeft // координата левого угла
// и так далее

Назначенные узлу стили можно узнать через свойство sytle:

el.style.color // цвет текста

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

getComputedStyle(el).color // цвет текста

Если захотите узнать более сложные свойства, то не забудьте преобразовать их названия в camelCase. Например: background-color → backgroundColor;

Подробнее в видео: https://youtu.be/kM8YAhsaHfE
И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO

Редактор UX Movement Энтони написал о цветовом контрасте и доступности интерфейса по стандартам WCAG

1. Требования WCAG не всегда оптимальны. Алгоритм оценки контраста занижает её для белого текста на ярком фоне (синем или оранжевом), хотя читать его легче чёрного текста.

2. Контраст текста не обязательно тянуть на уровень 7:1. Это полезно, если большая часть вашей аудитории — люди старше 70 лет с потерей зрения 20/80. Для определённого контента достижение уровня 7:1 невозможно вовсе.

3. Так как текст надо читать, его стандарты контрастности выше, чем у других компонентов интерфейса. У текста 4,5:1 против 3:1 у иконок.

4. Если у иконки есть доступная подпись (контраст 4,5:1), контраст самой иконки не важен. Также не важен цвет кнопки, если находящийся на кнопке текст доступен. Требование контрастности не распространяется на неактивные компоненты (например, отключённые кнопки).

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

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

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

https://ux.pub/mify-o-dostupnosti-tsvetovogo-kontrasta/