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) и команды.

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

Первая – "Принципы" Рэя Далио, вторая – "Creativity, Inc" Эда Кэтмелла.

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

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

Рэй Далио – создатель одного из самых успешных хедж-фондов Bridgewater Associates. Его книга – это, по сути, монолог о том, как он принимал решения, делал ошибки, строил компанию: первая часть – это его автобиография, вторая – принципы, которые он вывел для себя в течение жизни. Мне это напомнило книгу The Hard Thing about Hard Things (https://t.me/proproduct/681), где первая половина была утомительно детальной, а вторая – сугубо теоретической. Получилось, что эти финальные постулаты оторваны от доказательной базы, поданы как набор некоторых философских утверждений, многие из которых не особо оригинальны и уже не раз звучали в других книгах про менеджмент. Мне такое читать скучно: я не верю автору на слово, я хочу с ним живой дискуссии через книгу – а это создается через описание процесса мышления, проб и ошибок, через которые он прошел. Это частично есть в первой части, но с точки зрения структуры текста не соединено со второй.

Напротив, Эд Кэтмелл, президент Pixar и Walt Disney Animation Studios, рассказывает историю. Его размышления и принципы удачно вплетены в общую канву повествования, с большим количеством примеров из его работы в качестве руководителя. Изначально книга читается как документальный роман о создании Pixar, но в итоге ты остаешься с миллионом записей и мыслей о лидерстве. И, что было особенно важно для меня, о лидерстве в креативных индустриях. Многие книги о менеджменте написаны людьми, которые работали на производстве или пытались сделать его более эффективным. Да, конечно, креативность тут важна в верхах, но менеджмент в большинстве случаев сводился к оптимизации расходов/доходов. Люди в этих условиях – не больше, чем ресурс. Таичи Оно и его изобретения в Toyota, безусловно, гениальны, но стоит ли проводить аналогию с разработкой продуктов? Правда ли, что у нас такой же конвейер, и все сотрудники одинаковы и заменимы?

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

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

“If you’re sailing across the ocean and your goal is to avoid weather and waves, then why the hell are you sailing?”

Знайте про производственный менеджмент, учитесь креативному лидерству ^_^

Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

Немного матана! Совсем недавно, на интервью я столкнулся с интересным вопросом: «Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?»

И казалось бы, ответ довольно очевидный: мол Нильсен говорит 5. Но почему 5? Откуда это магическое число? Без математики не обошлось.

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

Если прорезюмировать, то можно сказать, что Нильсен не был не прав 🙂 Однако стоит приводить полный ответ:

—————————————————————————

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

—————————————————————————

Последняя часть, вообще интересная, не правда-ли? ) «Не менее 31% пользователей», то есть в самом неудачном случае 59% пользующихся так и не столкнуться с проблемами. Но это не слишком страшно.

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

http://bit.ly/2UqfhOs

Олег Большаков написал о проектировании системы уведомлений.

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

2. Создайте каркас: первый столбец таблицы — для событий, остальные столбцы — для уведомлений для каждой пары «задействованная роль и канал связи» (пуш-уведомления, письма, персональная лента). Например: «Персональная лента: Исполнитель».

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

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

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

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

6. Доработайте события. Добавьте формулировки:

— Для массовых событий. Например: «ПОЛЬЗОВАТЕЛЬ: Добавил в утверждение N файлов»;
— Для последовательностей действий. Например: если пользователь удалил одного утверждающего и добавил другого, пишите «Заменил утверждающего с УТВЕРЖДАЮЩИЙ на УТВЕРЖДАЮЩИЙ».

Как генерировать идеи для продукта

Внешние источники:

1. Тренды в вашей индустрии: что происходит на рынке
2. Что делают конкуренты
3. Какие фичи просят пользователи конкурентов
4. Что делают похожие бизнесы на других рынках (например, Amazon vs InstaMart in India)
5. Что обсуждают на конференциях/форумах/спец ресурсах в вашей индустрии
6. Какие фичи просят ваши пользователи

Внутренние источники

7. Что пользователи делают в продукте (или не могут сделать); как выглядит user journey
8. Что говорят пользователи, которые перестали пользоваться продуктом
9. Что говорят другие отделы, которые общаются с пользователями (саппорт, сейлзы, маркетинг)
10. Что говорит руководство компании/топ менеджеры/лидеры
11. Что делают другие команды в вашей компании, есть ли возможность для коллаборации или заимствования
12. Догфудинг (интенсивное использование продукта самой командой)
13. Небольшие сфокусированные дискуссии с командой
14. Работа в "обратную сторону" от видения: если вы хотите достичь X, какие проблемы должны быть решены

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

В жизни каждого дизайнера возникает момент, когда клиент приходит за логотипом для какого-то нового проекта.

В жизни каждого дизайнера возникает момент, когда клиент приходит за логотипом для какого-то нового проекта.

Это важный момент, потому что именно тогда придуманное название становится окончательным. И если название дерьмовое — иногда ещё не поздно что-то с этим сделать.

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

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

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

3. И если критика находит отклик, получить разрешение придумывать новое, и с этим разрешением придумывать.

4. И показывать не названия текстом, а быстрые логотипы из разных названий.

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

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

Это я книгу пишу и некоторые мысли туда просто не влезают. Вторая глава близко.