Расскажете подробнее? Просто я видел (и реализовывал) паттерны с конфигурируемыми полями, но пока не могу понять, как за счет таких полей выстроить реляционные отношения в несколько уровней.
И второй вопрос — почему вы говорите только об админке, на чем вы пишите фронт?
Если говорить о других примерах вложенности, где можно использовать CRUD-виджеты, могу привести из другого моего проекта: пользователь имеет список записей в балансе, каждая запись имеет список счетов, каждый счет имеет список исторических значений (по одному на каждый месяц) и связи на транзакции (дебет/кредит).
Здесь полностью приложение написано на Yii. Админка, конечно, есть, но она скорее утилитарная — справочники настроить, какие-то общие параметры и т.п. Соль как раз в интерфейсах для конечных пользователей для отображения и управления такими вложенными сущностями.
Видимо, я слишком сильно упростил пример. Речь не идет о стандартной CMS, для которой нужна одна админка с набором полей. Речь идет о проекте, когда пишется полноценный кастомный бэк, со сложной моделью данных и бизнес логикой.
Например, в одном из моих гейм-дев проектов есть такая структура: основная сущность — квест, он состоит из этапов. Этапы состоят из сообщений. Сообщения могут содержать мини игру. Мини игры могут быть разных типов, один из них — викторины, которые содержат список вопросов. А к каждому вопросу есть список вариантов ответов с одним правильным.
Если вы можете привести ссылку на готовое решение для такой возможности, буду благодарен.
Уже несколько лет пользуюсь freemind, её карты хранятся как XML файлы и есть встроенная возможность прогнать его через xslt. Используя это я много генерил разных артефактов из одной большой карты по проекту.
Например, ddl инструкции для базы данных по простому списку таблиц и полей.
Либо сводный excel (csv, конечно, но бизнес открывал его в excel и радовался) со статусами открытых вопросов/комментариев.
А что если сайт является «спутником» для мобильного приложения, в котором, работает аналитика, показывается реклама и/или есть возможность совершать микротранзакции?
Особенно интересно, как это все связать с новым законом GDPR?
Вы все правильно пишете, но не даете ответа на вопрос — как определить, что исполнитель провел качественный анализ и результатам его проверок гипотез можно доверять, или он просто слил задачу, а вся статистическая разница определяется сезонной/недельной погрешностью?
Допустим, вы говорите, что на месяц нельзя предсказать, но тогда на какой срок можно? Скажем, средняя стоимость привлеченного клиента за 3 месяца или за 6? Больше уже просто нет смысла оценивать.
Ценность исследований точно также понятна и поддается расчету: можно потратить сейчас на исследование разных стратегий 50 тысяч или 100 тысяч, но зато потом в течение 3 (6?) месяцев эффективность рекламы будет выше, что позволит окупить эти затраты. Или не позволит, но тогда — зачем исследования?
С точки зрения владельца бизнеса, все измеряется в деньгах, которые он заработает от этого бизнеса. Любые изменения в сайте, исследования маркетинговых инструментов, проверка гипотез — все это должно быть обосновано прибылью. Если не в краткосрочной перспективе, то в средне или долгосрочной — в зависимости от сумм затрат и текущего положения компании на рынке.
Реклама — это такой же участок бизнеса, как и логистика, производство или программирование. На всех этапах есть свои риски, гипотезы для проверки и деньги для счета. Поэтому реклама, как и любой другой аспект бизнеса должна иметь свои критерии эффективности, с позиции которых и принимаются решения относительно любых гипотез.
Так вот и вопрос — какие это критерии на ваш взгляд?
Хороший пример, согласен, волатильность спроса присутствует. Но как тогда оценить эффективность работы рекламщика? Как сказать, что вот этот специалист лучше того, на основе какого критерия?
В том-то и дело, что владельцу бизнеса нужен не трафик на сайт, а продажи. А уже способность увеличить продажи за счет улучшения качества трафика вызовет у владельца бизнеса больше доверия к специалисту и является обязательным условием для начала обсуждения любых других изменений в сайте/сервисе, естественно через АБ-тестирование. Кто будет выполнять эти изменения — уже совершенно другой вопрос.
Возвращаясь к исходному вопросу, вынесенному в заголовок статьи: почему все-таки специалисты по продвижению не готовы гарантировать продажи при условии сохранения остальных аспектов?
Вы меня не услышали.
Суть любых АБ-тестов в том, что в каждый момент времени меняется только один параметр — либо сайт (или даже какой-то один аспект сайта), либо источники трафика. Когда владелец бизнеса приходит к специалисту по продвижению, он хочет поменять только источник трафика. Может быть, он пришел одновременно к нескольким специалистам и собирается замерять их сравнительную эффективность — чей трафик будет лучше при прочих равных условиях.
Можно сколько угодно улучшать сайт, сервис и продажи, но вопрос в другом: они сейчас уже работают с определенной известной эффективностью.
Если при изменении только источника трафика общая эффективность упадет, это значит, что проблема не в сайте, сервисе или продажах. Проблема — в источнике трафика. Разве нет?
Почему интернет-продвижение не может гарантировать N продаж в месяц?
Вот и правда — почему? Положим, есть простой лендинг по продаже мелкой бытовой техники с формой заказа и оплаты. Есть настроенная кампания в директе, есть текущие показатели конверсии и рекламного бюджета. Для заказчика в такой ситуации вполне логично ожидать, что специалист по продвижению даст ему увеличение продаж, иначе зачем этот специалист вообще нужен?
Утверждение, что интернет-продвижение должно просто приводить посетителей на сайт — не верно: задача продвижения — приводить посетителей, которые совершат покупку и никак иначе. А то можно повесить порно-баннер — переходов будет тьма, а вот покупок — ноль.
Главный вопрос — по какому показателю мерять эффективность работы специалиста по продвижению? По количеству посетителей — бизнесу не это нужно, а за продажи они отвечать не хотят.
КОП не продвинутое ООП, а надстройка над ним. Согласен с вами по сути изложенного, но не согласен по форме: нельзя противопоставлять ООП и КОП, иначе, прочитав вашу статью, может сложиться впечатление, что ООП — устаревшее зло без права на всплытие.
В вашем примере, кстати, компоненты, отвечающие за урон ближнего боя и урон дальнего боя, вполне логично пронаследовать от одного компонента, отвечающего за урон в принципе.
Согласен, что не нужно пытаться использовать ООП для объектов игрового мира, т.к. они заведомо собираются из различных компонент (начиная от transform и rigitbody, заканчивая контроллерами баффов и собственных действий), но его можно и нужно использовать для реализации аспектов, действительно связанных отношениями родитель-потомок.
Не могу сказать, что современные BRMS и BPMS движутся в сторону Prolog-а, это было бы некорректным утверждением.
Но если говорить о декларативных вычислениях в целом, то в IBM пока такой возможности нет, там все еще доминирует процедурный образ мышления (нынче модно это называть SOA-архитектурой).
Насколько я знаю, в Appian также нет такой возможности, но с этим продуктом я близко не знаком, так что могу ошибаться.
Зато такая возможность есть и активно используется в Pega: там несколько различных типов декларативных правил, самым простым из них является declare expression, задающий формулу для вычисления значения переменной. Исполнение этой формулы обеспечивается движком Pega (PRPC) одним из двух вариантов:
Пересчитывать результат при каждом изменении любой переменной, входящей в формулу;
Пересчитывать результат при каждом чтении значения рассчитываемой переменной.
При этом, декларативные правила используются именно как дополнение к основному процессу. Это инструмент, который можно применять там, где он эффективен.
Вы правы, на нашем рынке пока очень мало людей, которые действительно знают, как применять BPM-системы. Но опыт американского и европейского рынков подсказывает, что мы тоже к этому придем.
На мой взгляд, из собственного опыта, залог успеха кроется в нескольких простых пунктах, практически независимых от выбранной платформы:
Знать свою платформу: очень часто в реальных проектах на платформах реализуется то, что итак есть, но чуть-чуть по-другому (другой пользовательский портал, своя система уведомлений и т.п.).
Еще раз — знать свою платформу: не менее часто в реальных проектах на таких платформах пытаются реализовать что-то, для чего они не предназначены (как правило — всякие учетные системы).
Ставить бизнес-цели: если проект делается для того, чтобы «потратить бюджет», то вряд ли он будет успешным, какая бы хорошая платформа ни была выбрана. В противовес этому, если проект делается с пониманием, что его внедрение позволит компании сэкономить 5-10 миллионов рублей ежемесячно, тогда у людей появляется стимул принимать нужные решения.
Вовлекать бизнес-пользователей в процесс разработки: еще одна частая проблема в том, что в больших проектах расстояние от бизнес-заказчика до программиста измеряется парой десятков руководителей, аналитиков с обеих сторон, архитекторов, прочих сочувствующих и мегабайтами документов. В результате делается не то, что нужно.
Приведенные скриншоты сняты с IBM ODM. Соглашусь, что это хорошая BR-система, но нельзя сказать, что самая лучшая.
Если вы занимались CRM системами, то вам стоит обратить внимание не только на BRMS, но и на BPMS (Business Process Management System). Посмотрите, например, отчет Gartner BPM Magic Quadrant за 2014 год (можно скачать с сайта IBM, оставив им контактные данные, есть отдельно сравнительная диаграмма из статьи или можно еще погуглить)
Даже если просто взять за основу их сравнительную диаграмму и посмотреть информацию по тройке лидеров (Pegasystems, Appian, IBM BPM), то уже можно составить базовое представление об области.
Для этого размер ортогональной камеры (параметр Size) должен равняться половине высоты экрана в пикселях. Например, если это экран iPhone 3G в портретном режиме, разрешение экрана которого 320x480, то Size = h/2 = 480/2 = 240.
Это некорректно. OrthographicSize камеры должен быть равен половине высоты экрана не в пикселях, а в unit-ах (внутренней единице измерения, обычно приравниваемой к 1му метру).
Понятно, что в целом, описываемый в данной статье подход уже не применим, но этот нюанс с камерой остается актуальным, и он попортил мне довольно много крови.
Если в корне SD-карты создать папку Maps, то в приложении появится возможность создавать и редактировать файлы локально, без аккаунта в облаке. На данный момент эта возможность бесплатна. И ее можно скомбинировать со сторонними облачными сервисами, например, Dropbox.
Есть поддержка карт .mm в приложении от Mindjet
Совместимость, конечно, не полная, но проблем у меня за все время использования не было.
Нужно создать папку Maps на sd-карте, тогда станет доступна опция работы с файлами на устройстве — после этого можно будет подключиться и к Dropbox
И второй вопрос — почему вы говорите только об админке, на чем вы пишите фронт?
Если говорить о других примерах вложенности, где можно использовать CRUD-виджеты, могу привести из другого моего проекта: пользователь имеет список записей в балансе, каждая запись имеет список счетов, каждый счет имеет список исторических значений (по одному на каждый месяц) и связи на транзакции (дебет/кредит).
Здесь полностью приложение написано на Yii. Админка, конечно, есть, но она скорее утилитарная — справочники настроить, какие-то общие параметры и т.п. Соль как раз в интерфейсах для конечных пользователей для отображения и управления такими вложенными сущностями.
Видимо, я слишком сильно упростил пример. Речь не идет о стандартной CMS, для которой нужна одна админка с набором полей. Речь идет о проекте, когда пишется полноценный кастомный бэк, со сложной моделью данных и бизнес логикой.
Например, в одном из моих гейм-дев проектов есть такая структура: основная сущность — квест, он состоит из этапов. Этапы состоят из сообщений. Сообщения могут содержать мини игру. Мини игры могут быть разных типов, один из них — викторины, которые содержат список вопросов. А к каждому вопросу есть список вариантов ответов с одним правильным.
Если вы можете привести ссылку на готовое решение для такой возможности, буду благодарен.
Думаю как раз потому, что "дальше его проблемы". Любая автоматизация должна решать проблемы, а не создавать их.
Уже несколько лет пользуюсь freemind, её карты хранятся как XML файлы и есть встроенная возможность прогнать его через xslt. Используя это я много генерил разных артефактов из одной большой карты по проекту.
Например, ddl инструкции для базы данных по простому списку таблиц и полей.
Либо сводный excel (csv, конечно, но бизнес открывал его в excel и радовался) со статусами открытых вопросов/комментариев.
Особенно интересно, как это все связать с новым законом GDPR?
Допустим, вы говорите, что на месяц нельзя предсказать, но тогда на какой срок можно? Скажем, средняя стоимость привлеченного клиента за 3 месяца или за 6? Больше уже просто нет смысла оценивать.
Ценность исследований точно также понятна и поддается расчету: можно потратить сейчас на исследование разных стратегий 50 тысяч или 100 тысяч, но зато потом в течение 3 (6?) месяцев эффективность рекламы будет выше, что позволит окупить эти затраты. Или не позволит, но тогда — зачем исследования?
С точки зрения владельца бизнеса, все измеряется в деньгах, которые он заработает от этого бизнеса. Любые изменения в сайте, исследования маркетинговых инструментов, проверка гипотез — все это должно быть обосновано прибылью. Если не в краткосрочной перспективе, то в средне или долгосрочной — в зависимости от сумм затрат и текущего положения компании на рынке.
Реклама — это такой же участок бизнеса, как и логистика, производство или программирование. На всех этапах есть свои риски, гипотезы для проверки и деньги для счета. Поэтому реклама, как и любой другой аспект бизнеса должна иметь свои критерии эффективности, с позиции которых и принимаются решения относительно любых гипотез.
Так вот и вопрос — какие это критерии на ваш взгляд?
Возвращаясь к исходному вопросу, вынесенному в заголовок статьи: почему все-таки специалисты по продвижению не готовы гарантировать продажи при условии сохранения остальных аспектов?
Суть любых АБ-тестов в том, что в каждый момент времени меняется только один параметр — либо сайт (или даже какой-то один аспект сайта), либо источники трафика. Когда владелец бизнеса приходит к специалисту по продвижению, он хочет поменять только источник трафика. Может быть, он пришел одновременно к нескольким специалистам и собирается замерять их сравнительную эффективность — чей трафик будет лучше при прочих равных условиях.
Можно сколько угодно улучшать сайт, сервис и продажи, но вопрос в другом: они сейчас уже работают с определенной известной эффективностью.
Если при изменении только источника трафика общая эффективность упадет, это значит, что проблема не в сайте, сервисе или продажах. Проблема — в источнике трафика. Разве нет?
Вот и правда — почему? Положим, есть простой лендинг по продаже мелкой бытовой техники с формой заказа и оплаты. Есть настроенная кампания в директе, есть текущие показатели конверсии и рекламного бюджета. Для заказчика в такой ситуации вполне логично ожидать, что специалист по продвижению даст ему увеличение продаж, иначе зачем этот специалист вообще нужен?
Утверждение, что интернет-продвижение должно просто приводить посетителей на сайт — не верно: задача продвижения — приводить посетителей, которые совершат покупку и никак иначе. А то можно повесить порно-баннер — переходов будет тьма, а вот покупок — ноль.
Главный вопрос — по какому показателю мерять эффективность работы специалиста по продвижению? По количеству посетителей — бизнесу не это нужно, а за продажи они отвечать не хотят.
В вашем примере, кстати, компоненты, отвечающие за урон ближнего боя и урон дальнего боя, вполне логично пронаследовать от одного компонента, отвечающего за урон в принципе.
Согласен, что не нужно пытаться использовать ООП для объектов игрового мира, т.к. они заведомо собираются из различных компонент (начиная от transform и rigitbody, заканчивая контроллерами баффов и собственных действий), но его можно и нужно использовать для реализации аспектов, действительно связанных отношениями родитель-потомок.
Но если говорить о декларативных вычислениях в целом, то в IBM пока такой возможности нет, там все еще доминирует процедурный образ мышления (нынче модно это называть SOA-архитектурой).
Насколько я знаю, в Appian также нет такой возможности, но с этим продуктом я близко не знаком, так что могу ошибаться.
Зато такая возможность есть и активно используется в Pega: там несколько различных типов декларативных правил, самым простым из них является declare expression, задающий формулу для вычисления значения переменной. Исполнение этой формулы обеспечивается движком Pega (PRPC) одним из двух вариантов:
При этом, декларативные правила используются именно как дополнение к основному процессу. Это инструмент, который можно применять там, где он эффективен.
На мой взгляд, из собственного опыта, залог успеха кроется в нескольких простых пунктах, практически независимых от выбранной платформы:
Если вы занимались CRM системами, то вам стоит обратить внимание не только на BRMS, но и на BPMS (Business Process Management System). Посмотрите, например, отчет Gartner BPM Magic Quadrant за 2014 год (можно скачать с сайта IBM, оставив им контактные данные, есть отдельно сравнительная диаграмма из статьи или можно еще погуглить)
Даже если просто взять за основу их сравнительную диаграмму и посмотреть информацию по тройке лидеров (Pegasystems, Appian, IBM BPM), то уже можно составить базовое представление об области.
Это некорректно. OrthographicSize камеры должен быть равен половине высоты экрана не в пикселях, а в unit-ах (внутренней единице измерения, обычно приравниваемой к 1му метру).
Понятно, что в целом, описываемый в данной статье подход уже не применим, но этот нюанс с камерой остается актуальным, и он попортил мне довольно много крови.
Совместимость, конечно, не полная, но проблем у меня за все время использования не было.
Нужно создать папку Maps на sd-карте, тогда станет доступна опция работы с файлами на устройстве — после этого можно будет подключиться и к Dropbox