К этому моменту мы с вами создали проект (WSGI-приложение), состоящий из нескольких файлов и реализующий некоторый типовой функционал: отображение статей, авторизацию и регистрацию пользователей. Но даже в этом простом приложении становится непросто ориентироваться, вносить изменения, не говоря уже о тестировании отдельных его компонент, например, авторизации пользователей. Наверное, главной проблемой разрастающегося проекта, является все большая мешанина программного кода, усложнение его понимания, редактирования и переноса части функционала в какой-либо другой подобный проект.
Так вот, все эти слова я, конечно, говорю не просто так. Фреймворк Flask позволяет разделять большой, сложный проект на набор независимых модулей. Например, на сайте могут быть модули авторизации, админ-панели, подсчета числа просмотров страниц и так далее. Причем, каждый модуль может иметь свои шаблоны, стили оформления, наборы изображений. Все это хранится в отдельном подкаталоге, что делает фрагмент приложения совершенно независимым. И при необходимости, этот каталог можно просто скопировать в другой проект и подключить к другому сайту.
Такие модули в терминологии Flask называются Blueprint (эскизами) и о них пойдет речь на этом занятии. Чтобы не копаться в уже написанном коде и не усложнять занятие, я покажу пример реализации Blueprint на примере создания простейшей админ-панели.
Структура подкаталога admin
Вся наша админ-панель будет реализована в отдельном подкаталоге admin со следующей структурой:
В корне этого каталога будет лежать файл admin.py, в котором и реализуем админ-панель с использованием Blueprint. В подкаталоге templates/admin будут располагаться файлы шаблонов, а в static – файлы оформления, js, изображений и другие статические данные, подключаемые к HTML-страницам в панели администратора. Таким образом, мы строго разделяем данные, относящиеся к нашему модулю admin от всех остальных файлов приложения. В дальнейшем, при необходимости, можно будет просто скопировать этот подкаталог в другой проект и в нем реализовать похожую админ-панель.
Здесь может возникнуть вопрос: зачем в подкаталоге templates создавать еще один каталог admin? Фактически, здесь используется Django’вский подход, когда шаблоны в каждом модуле помещаются в дополнительный подкаталог с тем же именем. Это необходимо, т.к. при компиляции проекта все шаблоны собираются в одну кучу и может возникнуть конфликт имен, когда в разных модулях будут файлы с одинаковыми именами. Чтобы этого избежать, как раз и создается дополнительный подкаталог. В этом случае в момент выполнения, шаблоны будут отделяться от других этим подкаталогом.
Создание и регистрация Blueprint
Итак, теперь у нас все готово, чтобы создать Blueprint в модуле admin.py. В начале выполним импорт класса Blueprint:
и ниже создадим экземпляр этого класса:
После создания эскиза его нужно зарегистрировать в основном приложении. Перейдем в файл flsite.py и выполним импорт переменной admin:
Обратите внимание, мы импортируем именно переменную, а не класс или функцию. Далее, ниже выполним непосредственно регистрацию Blueprint:
Здесь admin – ссылка на созданный Blueprint; url_prefix – префикс для всех URL модуля admin. Это необязательный параметр. Без него все URL внутри Blueprint будут записываться непосредственно после домена сайта. Но это не лучшая практика, так как, подключая несколько таких модулей, можно опять же столкнуться с проблемой дублирования URL. Поэтому лучше использовать префик, по которому они будут четко разделяться.
Итак, мы создали Blueprint и зарегистрировали его в приложении. Если теперь перейти по URL:
то получим ошибку 404 – страница не найдена, так как внутри эскиза не создано ни одного представления. Давайте его добавим.
Маршрутизация в Blueprint
Перейдем в модуль admin.py и пропишем декоратор route:
Смотрите, мы вызываем route для admin, а не app, как это делали в основном приложении. Тем самым указываем, что корневая (главная) страница – это страница Blueprint, а не приложения app. Причем, адрес этого URL определяется по правилу:
и в нашем случае будет выглядеть так:
то есть, это главная страница админ-панели, а не сайта. И благодаря префиксу, указанному при регистрации этого эскиза, мы можем не беспокоиться о дублировании URL в нашем модуле.
Авторизация в админ-панели
Давайте теперь добавим возможность авторизации в нашей тестовой панели администратора. Для этого пропишем еще одну функцию представления login, следующим образом:
Здесь все достаточно просто и очевидно. Сначала проверяем, что пришли данные по POST-запросу, затем, проверяем правильность логина и пароля и при истинности условий, выполняем авторизацию с помощью функции login_admin, которую пропишем чуть позже. Далее, делается перенаправление на главную страницу админ-панели, а иначе – формируется мгновенное сообщение «Неверная пара логин/пароль». В конце возврашается шаблон ‘admin/login.html’ с заголовком ‘Админ-панель’.
Обратите внимание, как здесь записан параметр в функции
Перед index указана точка. Эта точка означает, что функцию-представления index следует брать для текущего Blueprint, а не глобальную из приложения. Если убрать точку, то будет возвращен URL-адрес главной страницы сайта, а не панели администратора. Как вариант, функцию url_for можно еще вызвать и так:
Здесь admin – это имя Blueprint, а не название файла admin.py. Например, если изменить имя эскиза на bp, то придется уже прописывать:
Но, в данном случае, это избыточная запись и, кроме того, идет жесткая привязка к имени Blueprint. Поэтому, я в дальнейшем буду писать просто точку.
Итак, возвращаясь к обработчику login, добавим функцию login_admin в модуль admin.py:
Мы здесь просто в сессии создаем и сохраняем запись ‘admin_logged’ со значением 1. И в дальнейшем будем полагать, если она существует, то пользователь зашел в админ-панель.
Некоторые из вас могут задаться вопросом: почему бы нам здесь не использовать рассмотренный ранее модуль Flask-Login? Дело в том, что нельзя создать еще один его экземпляр в рамках одного приложения. А Blueprint – это лишь дополнение, расширение, но не самостоятельная программа. Конечно, мы могли бы передать ссылку на Flask-Login в наш модуль admin и как то его использовать, но тогда теряется концепция независимости и модульности Blueprint. И наша реализация будет ничем не лучше обычного дополнительного вспомогательного класса, записанного в отдельном файле проекта. Поэтому, я авторизацию сделал через сессии.
Давайте здесь же рядом объявим еще две вспомогательные функции:
Первая проверяет: авторизован ли администратор, а вторая – удаляет из сессии запись об авторизации и будет использоваться при выходе из админ-панели. И сразу пропишем функцию представления logout:
Шаблоны для страницы админ-панели и авторизации
Теперь давайте добавим первые шаблоны для нашей панели администратора. Я специально для демонстрации сделаю другое оформление и пропишу новый базовый шаблон. В каталоге templates/admin добавлю файл base_admin.html, который будет иметь следующий вид:
Здесь все, опять же, достаточно очевидно. Обратите внимание, для обращения к каталогу static первый параметр функции
записан с точкой вначале. Эта точка будет указывать брать каталог static из подкаталога admin, то есть, сформируется следующий путь:
Далее, в шаблоне идет отображение меню, если оно передается в шаблон и записан именованный блок content для добавления информации в дочерних шаблонах. И первый такой шаблон будет login.html со следующим содержимым:
Мы здесь отображаем форму авторизации, где пользователь вводит логин/пароль.
А шаблон index.html будет пока пустой:
Далее, нам нужно прописать стили оформления. Они представлены в файле
(подробнее см. в файле проекта).
И перед первым пробным тестированием, изменим обработчик главной страницы админ-панели:
Вначале идет проверка: если пользователь не авторизован, то он перенаправляется на страницу авторизации. Иначе, будет отображена панель администратора. Здесь в шаблон ‘admin/index.html’ передаются два параметра: menu и title. И для menu пропишем следующую коллекцию:
Все, теперь при запуске, мы увидим окно авторизации и, вводя admin/12345, перейдем в панель администратора.
Видео по теме
Flask #1: Что это такое? Простое WSGI-приложение
Flask #2: Использование шаблонов страниц сайта
Flask #3: Контекст приложения и контекст запроса
Flask #4: Функция url_for и переменные URL-адреса
Flask #5: Подключение внешних ресурсов и работа с формами
Flask #7: Декоратор errorhandler, функции redirect и abort
Flask #8: Создание БД, установление и разрыв соединения при запросах
Flask #9: Добавление и отображение статей из БД
Flask #10: Способ представления полноценных HTML-страниц на сервере
Flask #11: Формирование ответа сервера, декораторы перехвата запроса
Flask #12: Порядок работы с cookies (куками)
Flask #13: Порядок работы с сессиями (session)
Flask #14: Регистрация пользователей и шифрование паролей
Flask #15: Авторизация пользователей на сайте через Flask-Login
Flask #16: Улучшение процесса авторизации (Flask-Login)
Flask #17: Загрузка файлов на сервер и сохранение в БД
Flask #18: Применение WTForms для работы с формами сайта
Flask #19: Обработка ошибок во Flask-WTF
Flask #23: Операции с таблицами через Flask-SQLAlchemy
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
BluePrint: как создать успешный стратегический план разработки и не завалить проект
Ответ предельно прост:
Процесс разработки приложения подобен строительству дома. Среди нас вряд ли найдется тот, кто захочет приступить к строительству, не имея четкого плана. Хозяин будущего дома может уточнить, что в доме должно быть 4 этажа, панорамные окна и черепичная крыша. Но для того, чтобы строительная бригада приступила к работе, этих сведений явно недостаточно. Помимо этих параметров есть еще тысяча и одна мелочь, которая должна быть учтена, чтобы подрядчик мог рассчитать бюджет, обозначить этапы строительства и предоставить план работ. В свою очередь и заказчик извлечет из наличия плана неоспоримые выгоды, поскольку он может четко изложить свои требования и понимает, за что платит.
Каждому в конце дня нужен план.
Вы спросите, нужен ли план этот для более ясного понимания общей картины? Именно! И вот что конкретно заключает в себе BluePrint:
Теперь вам стало понятней, что из себя представляет BluePrint, но все же не до конца ясно, какие конкретные выгоды он в себе несет? Вот список наиболее ключевых для вас:
Мы готовы приложить максимум усилий, чтобы сделать BluePrint как можно более наглядным для вас. Если вы хотите ознакомиться с примерами и получить больше подробностей о том, как его можно оптимально применить к вашей идее, свяжитесь с нами прямо сейчас!
«Тайна» торговой марки Blue Print
Вся продукция, поставляемая Blue Print, отличается высоким уровнем качества и надежности. Это объясняется тем, что 90% запчастей производится на предприятиях Японии, такими компаниями, как NTN, HDK, 555, NGK, Denso, Kayaba и другие. Кроме того, продукция, которая поставляется под брендом Blue Print, сертифицирована как соответствующая Международным стандартам качества ISO 9001:2000.
Английская компания ADL (Automotive Distributors Ltd.) создана в октябре 1983 года английскими и японскими учредителями для обеспечения вторичного рынка запасными частями японского производства.
Компания на 49,6% принадлежит японской корпорации TMY и на 50,4% английским акционерам.
Наличие японских совладельцев гарантирует действительно японское качество поставляемых товаров, разумное ценообразование и возможность приобретения товаров для японских автомобилей как европейского так и внутрияпонского рынков.
Структура компании ADL направлена на наилучшее исполнение заказов своих партнеров (не менее 90%), а также постоянный контроль за качеством товаров и сервиса.
Торговая марка BluePrint включает в себя не только высокое качество товаров, но и широкий ассортимент, техническую и информационную поддержку наших заказчиков и партнеров, сервис по организации доставки товаров на территории России.
Важным фактором также явлется гибкая политика компании ADL при формировании собственных складских остатков, выражающаяся в следующем:
— при увеличении спроса на отдельные товары это немедленно учитывается при формировании складских остатков и ассортимента.
— при отстутствии в каталогах компании каких-либо товаров поддерживается возможность их добавления при предоставлении со стороны заказчика оригинального номера требуемых товаров и определении ежемесячной потребности.
Что конкретно запаковано в коробку от BLUE PRINT.
1 Тормозные колодки бар./диск. Kashiyama
2 Диски/барабаны тормозные Nishioka
3 Фильтры масл., топл., возд. by-pass, Micro
4 Датчики HKT
5 Помпы водяные GMB
6 Прокладки клап. крышки/гол. блока компл. Stone
7 Ремни зубч., клин., руч. Roulunds/Bando/Mitsuboshi
8 Шланги тормоз., сцепл., Miyaco
9 Натяжители ремня ГРМ NSK/Koyo
10 Патрубки радиатора Nissens
11 Тросики тормозные, сцепления TSK
12 Термостаты HKT
13 Топливные насосы Kyosan/Mitsubishi
14 Сцепления комплекты и части Asco/NKK
15 Тормозные цилиндры глав/раб. Miyaco
16 Ремкомплекты тормозных цилиндров Tokico/Miyaco
17 Сцепления цилиндры глав/втор. Tokico/Miyaco
18 Ремкомплекты цилиндров сцепления Tokico/Miyaco
19 Подшипники ступицы NTN/Koyo/NSK/Nachi
20 Стартеры, генераторы Mitsubishi
21 Части трамблера YEC
22 Провода ВВ Seiwa
23 Шаровые опоры 555
24 ШРУС-ы NKN
25 Тяги стабилизатора, 555
26 Крышки радиаторов Nissens
27 Радиаторы Nissens
28 Пыльники ШРУС-ов GMB
29 Щетки стеклоочистителя TRYCO
30 Фары и фонари TYC
31 Рессоры 4х4/вэны вкл. втулки
32 Втулки и сайлентблоки подвески L56
33 Рычаги подвески 555
34 Cуппорта UBD
35 Наконечники рулевых тяг 555
36 Головки блока бенз. двигателей
37 Болты головки блока Kato Screw
Как перейти от CJM к Service blueprint?
Разбираемся, как не путать два очень полезных и очень разных инструмента Service Blueprint (карту сервисного сценария) и Customer Journey Map (карту пути пользователя).
Есть два инструмента, которые часто путают — карта клиентского опыта Customer Journey Map (CJM — «карта пути пользователя») и сервис-блупринт (Service Blueprint — «карта сервиса» или сервисный сценарий).
Customer Journey Map — это путь клиента по сервису, а может быть, путешествие между разными сервисами и каналами, в которых участвует и ваше предложение. CJM показывает опыт клиента, как он есть.
Например, мы проектируем медицинский сервис, который позволяет сдавать анализы на дому. С чего начать? Мы всегда начинаем с эмпатии, понимания настоящего опыта человека, который столкнулся с необходимостью сдавать анализы. Для этого мы наблюдали за клиентами частных клиник, беседовали с ними и сами проходили по всей процедуре записи, регистрации и сдачи анализов. Таким образом мы смогли получить карту пути нашего клиента или CJM — историю о его фактическом опыте.
На представленной выше картинке CJM — путь клиента после сдачи анализов. Пользователь находится на работе, активно занят своими делами. Возникает целый сценарий того, что происходит на этапе «После», которые отражает мысли, эмоциональную оценку происходящего и действия, которые предпринимает Пользователь: звонит на горячую линию, уточняет и так далее.
CJM — это исследование текущего пользовательского пути «как он есть», а Service Blueprint — карта спроектированного вами на основе этого клиентского пути (его проблем и возможностей) новое сервисное решение.
После того, как мы снимем опыт пользователя с помощью CJM, мы сможем сгенерировать новые идеи по улучшению и спроектировать новый сервисный сценарий, который как раз и ляжет в канвас сервис-блупринта или «карты сервиса», какой она должна быть.
Нам как сервисным дизайнерам важно и то, что переживает человек, и то, что происходит вне его взгляда, «за сценой» сервиса. Мы отвечаем на вопрос, как компания поддерживает опыт человека, какие внутренние системы способствуют тому, чтобы произошло это «путешествие» и что мы можем сделать, чтобы улучшить этот опыт.
Научиться проявлять эмпатию в разработке продуктов и сервисов можно на нашем интенсиве Составляем Customer Journey Map
Из чего состоит Service blueprint?
Для начала, нужно определить какой пользовательский сценарий мы хотим спроектировать. Мы определяем его на основе CJM (карты пути пользователя).
Разрабатывая сервис компании Red, мы определили такие компоненты карты сервиса (сервисного сценария):
В лаборатории Wonderfull использование любого инструмента главным образом должно быть оправдано его практическим применением, поэтому раздутые и нечитаемые схемы мы упрощаем до того момента, пока с этим становится удобно работать. Мы намеренно не заполнили сразу «подводную» часть этого чертежа, чтобы держать фокус на пользователе.
Когда переходить «за кулисы» сервиса?
Когда мы понимаем, какой опыт хотим создать для нашего пользователя, какие проблемы сможем решить в текущем сценарии, переходим к действующим лицам «за сценой». Именно сотрудники и внутренние процессы будут создавать позитивный опыт для пользователя. Мы очень внимательно сосредоточились на этой теме.
Сотрудники — это внутренние пользователи нашего сервиса. Поэтому также изучаем их опыт работы, взаимодействие с клиентами и внутренними процессами. В процессе исследования мы формируем не только карту пути пользователями, но и второй CJM — CJM сотрудника, выявляем болевые точки в его работе.
На основе этой информации генерим идеи для Service Blueprint: как будет работать новый сервис, что позволит создать лучший опыт.
Почему у нас появилась отдельная строка «возможные ошибки и их решения»?
Обращали ли вы внимание на то, что часто хороший сервис — это невидимый сервис. Пользователя все устраивает, вы решаете его задачи. Но как только происходит сбой — вас замечают, начинают звонить, писать, оставлять гневные отзывы в интернете. Знакомая ситуация? Избежать ошибок совсем нельзя, вот почему так важно знать все тонкие места и иметь быстрые решения для таких ситуаций.
В нашем случае точками для срывов сценария пользователя было незнание ответов на актуальные вопросы клиентов, незнание действий в случае опоздания, изменения заказа или смены адреса.
Главная задача для нас как проектировщиков — превратить служебные инструкции в ряд полезных полевых инструментов для выездной бригады лаборатории.
В рамках Service Blueprint мы отметили эти моменты в специальной строке, чтобы видеть что происходит и на каких этапах пользовательского сценария. Дальше, основываясь на этой картине сервиса, мы сгенерировали идеи о том, как помочь сотрудникам создавать позитивные впечатления от услуги у пользователей «здесь и сейчас».
Что у нас получилось можно узнать на нашем сайте в развернутой истории о кейсе RED: lab-w.com/cases/red
Как CJM и Service Blueprint работают вместе?
Понимание пути пользователя по вашему продукту или сервису (CJM), проектирование сервисного сценария (Service Blueprint) — важные инструменты для человеко-ориентированного подхода. Важно понимать разницу между ними и то, как они дополняют друг друга.
CJM — помогает посмотреть на продукт или сервис глазами пользователя, что позволяет проявить эмпатию к его опыту и улучшить его. Чтобы сохранить связку между опытом пользователя с реальной возможностью изменить бизнес-процессы нужно погрузиться «за сцену» и посмотреть, что поддерживает это «путешествие».
Только зная как устроены процессы “внизу” можно проектировать лучшие путешествия ваших пользователей.
Читать также:
“CJM словарь” — краткий иллюстрированный гид по основным терминам, сопутствующим составлению карты пути пользователя.
«3 инсайта проектирования финансовых технологий в развивающихся странах» — перевод статьи управляющего партнера Grid Impact Алксандры Фиорилло.
Автор: Анна Мезина, старший исследователь лаборатории Wonderfull.
Blue Print — правильный выбор запчастей для азиатских автомобилей
Приветствуем вас, уважаемые читатели! Сегодня мы расскажем о третьем продуктовом бренде в портфеле bilstein group.
Бренд Blue Print появился в 1994 году в рамках компании «Automotive Distributors Ltd», отделившейся от «Mazda Cars Ltd». В 2011 году бренд стал частью группы компаний bilstein group наряду с брендами febi и SWAG.
Логотип бренда представляет собой отпечаток пальца, а в технической документации термин «blue print» означает план, чертеж или точную копию. Это соотносится с тем, что запчасти Blue Print являются альтернативой оригинальным деталям, имеют такие же характеристики и свойства и предназначены для прямой их замены.
Сегодня в ассортименте бренда Blue Print представлено более 23 000 наименований, специализируется бренд на азиатских моделях легковых автомобилей и легкого коммерческого транспорта. Кроме этого, вы найдете и запчасти для автомобилей американских и английских производителей.
Ключевые продуктовые группы: фильтры, детали сцепления, компоненты тормозной системы, щетки стеклоочистителя.
Слоган бренда Blue Print – «Right First Time.», что можно перевести как «Всегда с первого раза». Этот слоган подчеркивает главные принципы бренда — качество и точность, на которые с уверенностью полагаются наши покупатели по всему миру.
Почему Blue Print можно доверять?
— Каждая партия изделий Blue Print проходит проверку в сравнении с оригинальными деталями, что обеспечивает соответствие высочайшим стандартам качества.
— В распоряжении Blue Print есть тысячи образцов оригинальных изделий для сравнительного анализа.
— Все без исключения производственные партнеры Blue Print инспектируются квалифицированными аудиторами на предмет соответствия минимальным требованиям производственного стандарта ISO.
— Собственная производственная экспертиза (некоторые запчасти производятся на нашем заводе bilstein group Engineering; Clutch Competence Centre или Экспертный центр сцепления занимается разработкой компонентов сцепления, в том числе для бренда Blue Print)
— Каждый год специально выделенная команда инженеров проводит сравнения тысяч компонентов
— В собственных испытательных лабораториях bilstein group продукция бренда тестируется по многим параметрам
— Если новые образцы продукции не соответствуют требованиям Blue Print, они отбраковываются.
Для более удобной идентификации артикульных номеров бренда разработана собственная система наименований: