7 важных факторов PHP-приложения

7 важных факторов PHP-приложения

Инженеры платформы Heroku (https://www.heroku.com/) на основе собственного опыта создали методологию (https://12factor.net/ru/) для разработки SaaS-приложений.

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

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

Кодовая база (https://12factor.net/ru/codebase). Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.

Зависимости (https://12factor.net/ru/dependencies). Используйте менеджер зависимостей Composer (https://getcomposer.org/) и его основные операции install и update для манипуляций c composer.json (https://getcomposer.org/doc/04-schema.md) и composer.lock.

Конфигурация (https://12factor.net/ru/config). Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv (https://github.com/symfony/dotenv).

Параллелизм (https://12factor.net/ru/concurrency). Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ (https://github.com/rabbitmq).

Паритет разработки/работы приложения (https://12factor.net/ru/dev-prod-parity). Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.

Журналирование (https://12factor.net/ru/logs). Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog (https://github.com/Seldaek/monolog) или компоненты фреймворков.

Задачи администрирования (https://12factor.net/ru/admin-processes). Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console (https://github.com/symfony/console). Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения (https://www.yiiframework.com/doc/guide/2.0/en/tutorial-console) и команды.

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

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

Нашла интервью (https://www.thatexplainsthings.com/the-invisible-voice/) о нейтральном голосе с Сарой Ричардз. Сара руководила контент-дизайном gov.uk, сайта правительства Великобритании. Интервью вот о чем:

«Нейтрально» — хорошее описание стиля gov.uk. Правительству легко звучать снисходительно или покровительственно, этого важно было избежать. Никто не приходит на сайт правительства, чтобы вдохновиться: это почти неприятность — здесь приходится платить деньги или разбираться с неинтересными делами. Нужно было как можно незаметнее и дать посетителям выполнить их задачи, не пытаясь превратить это в приятное занятие и не давая советы.

Команда никогда не писала «для всех». При том, что аудитория всего сайта — миллионы, аудитория каждой странички достаточно узкая. Вы не знаете свою аудиторию, если думаете, что пишете для всех.

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

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

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

Итак, PROFI.RU

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

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

Часть первая. Бизнес модель.

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

Давайте рассмотрим этот процесс подробнее.

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

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

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

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

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

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

Часть вторая. Зонтичный бренд

Еще одной важной особенностью сервиса, которую мы узнали от заказчика, является большое количество различных направлений — вертикалей бизнеса. Платформа PROFI.RU образовалась путем объединения нескольких уже существующих сервисов по поиску репетиторов, спортивных тренеров, врачей и т.д. — образовав тем самым, так называемый, зонтичный бренд.

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

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

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

Часть третья. Legacy

Из-за особенностей, описанных выше, а именно из-за того, что сервис образовался путем слияния разных бизнесов, вытекает еще одна не самая приятная особенность — большое техническое наследование, или technological legacy. Это означает, что платформа, на которой строится профиру за всю свою историю существования (а это больше 10 лет) обросла огромным количеством костылей и ограничений. БОльшая часть интерфейсных (и не только) проблем сервиса связанна именно с этим — любое изменение дается долго и дорого.
Поэтому бриф, который озвучил Андрей, был про свежий взгляд без привязки к грузу технических ограничений.

Итого

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

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

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

Мини-кейс

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

Например, как решить проблему того, что люди часто не заканчивают курс лекарств до конца?

Конечно же ввести геймификацию!
Главная проблема заключается в том, что довольно сложно принимать большое количество одинаковых лекарств постоянно, это просто надоедает. Но можно пойти другим путем и разделить одинаковые лекарства на две группы — 90% оставить как было, а 10% сделать другим цветом и разместить их в самом конце, сказав, что их прием ОБЯЗАТЕЛЕН.

Профит!

Денис Невожай о доме будущего и дизайне интерфейсов для часов.

Старший UX-дизайнер в Essential
http://dnevozhai.com/

— Привет Денис. Чем ты занимаешься в Essential?

UX Design для Home продукта. Если точнее, то работаю над архитектурой и логикой для таких систем как домашняя безопасность, управление IoT устройствами в доме и т.д.

— Почему ты решил заниматься только UX? У тебя же и UI отлично получается)

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

— Как будет работать дом будущего?

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

— Ты занимался интерфейсами для Alcatel One Touch и Amazfit. Что нужно в первую очередь учитывать, рисуя дизайн для часов?

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

— Как ты проверял свои решения?

На телефоне с маленьким, кругленьким экраном внутри )

— Как делать UI для круглых экранов?

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

— Что смогут делать носимые устройства через 5 лет?

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

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

— Какие устройства станут популярными через 5 лет?

Штука, которая взорвет мир — дополненная реальность. Но это произойдет только когда эти устройства смогут быть достаточно незаметными и не «странными» как Google Glass. Был слух от знакомого, который работает в Magic Leap, о том, что люди на закрытом демо не могли отличить искусственные объекты от реальных. Это впечатляет, обнадеживает и пугает.

— Ты много путешествуешь. Какое место нужно посетить каждому дизайнеру?

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

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

— Apple или Google?

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

Денис Ломов #1 - о номинации «Агенство года» и процессах.

Креативный директор Red Collar.
http://redcollar.ru/

— Привет, давай начнем. Вы стали первой студией из России, которая выиграла в номинации «Агенство года» по версии CSS Design Awards. Почему так сложилось и что было залогом успеха?

Я сам был удивлен, и до сих пор не могу это осознать. После того, как мы взяли первый «Сайт дня» с нашим сайтом, начали стараться делать на высочайшем уровне для клиентов. И последние 2 года старались не выпускать проходных проектов. В каждый вкладывались по максимуму. За год выиграли 10 наград на CSS Design Awards. Видимо это огромный скачок, и жюри решили что мы достойны называться лучшими в мире по итогам 2017 года.

— Круто ) Что-нибудь изменилось в жизни агенства после?

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

— Воронеж наверное гордится вами ) А какой может быть твоя следующая цель?

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

— Желаю удачи! Давай поговорим про процесс. Большинство твоих работ — промо с крутым дизайном и качественной разработкой. Как у тебя происходит процесс поиска дизайн-решения?

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

— Интересно ) А как ты налаживаешь взаимодействие дизайнеров и разработчиков?
Я пишу в фейсбуке про Creative Frontend Developer. Так вот у нас именно такие. Дизайнер и фронтенд-разработчик совещаются, обсуждают, предлагают решения. Нет такого, что все, что предложил дизайнер должно быть реализовано 1 в 1. От некоторых вещей можно отказаться, а другие изменить. И разработчик часто сам предлагает очень интересные решения, о которых дизайнер и не думал даже. А возможные конфликты между ними решаются арт-директором.

Впечатления от станции

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

Самое главное отличие Яндекс Станции от конкурентов — её можно подключить к телевизору, и если опыт общения с голосовым помощником у нас уже есть (Siri, Google Assistant), то как будет выглядеть взаимодействие с голосовым ассистентом, который в тоже время имеет визуальный интерфейс? Очень интересно.

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

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

Во время демонстрации мне особенно интересно было узнать, как Алиса обрабатывает ошибки, ведь если по голосу она меня не поняла, то ввести более точный запрос у меня никак не получится. Парень, проводящий демонстрацию, показал это на примере вопроса о погоде на марсе — Алиса просто не смогла ответить, сказала, что не знает. Тогда я спросил у неё «а в москве?» и она поняла контекст — дала прогноз погоды по Москве. Это здорово.

Дальше, я хотел выяснить как она понимает, где показывать мой запрос — на ютубе, на кинопоиске или амедиатеке. Парень попросил Алису показать котиков, и она открыла ютуб. Но я решил дать запрос посложнее и попросил показать мне видео Усачева — Алиса также открыла ютуб, но выборка была не самой очевидной — какие-то рандомные видео из ютуба с непонятными людьми (хотя по идее канал Руслана Усачева один из топовых). А если я имел в виду писателя? По итогу, мне было не очень понятно, как Алиса выбирает место поиска, и как мне уточнить какой-нибудь сложный запрос.

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

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

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

А как вам Яндекс Станция?