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

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

Теперь, когда мы упростили себе задачу, можно абстрактно рассуждать о том, нужно ли нам приложение и как мы сможем его использовать для получения дополнительной прибыли. Честно скажу, что до недавнего времени я сам очень мало пользовался приложениями на своем андроиде и не понимал, как приложение может быть отдельным каналом привлечения клиентов, ведь, как мне казалось, мало кто просто так ставит себя приложения. Однако, по данным Яндекса среднестатистический пользователь устанавливает 3-4 новых приложения в месяц. Да еще и проводит в приложениях около 80% времени, проведенного «в телефоне». Эти цифры напрямую ничего не говорят нам, но можно предположить что даже просто выложив приложение мы уже получим какой-то органический трафик в него из магазинов приложений. Я думаю, что для серьезного бизнеса этот трафик не существенный и не стоит расчитывать, что за счет него мы хотя бы часть разработки окупим в итоге.

Чем приложение отличается от сайта для бизнеса?

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

Все эти отличия для интернет-магазина, как правило, сводятся к следующим вариантам их использования:

• Возврат покупателей через PUSH-уведомления. Этот способ использования достаточно близок к так называемому email-маркетингу. Хотя часть пользователи относятся к уведомлениям благосклоннее, так как чувствуют, что сами их разрешили, установив приложение.
• Качественная персонализация. То есть, конечно, её можно добится и на сайте, но надо помнить, что пользователи могут пересаживаться с рабочего компьютера на домашний или наоборот, один компьютер и несколько членов семьи. Телефон же, как правило, предмет личный и, даже, можно сказать интимный.
• Мелкие «плюшки». Например кнопка «Привезите мне туда, где я сейчас», которую на сайте не реализуешь, без огромной погрешности.
• Лояльность. Кто уже установил приложение, обычно стали автоматом лояльнее. Им проще посмотреть там, чем искать конкурента.

Чем приложение отличается от сайта для клиента?

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

Ложка дегтя

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

• Отношение количества повторных покупок к первым. Тут считать, думаю, стоит именно в количестве, а не по сумме, п тому, что нам важно только то, как часто человек будет запускать приложение для покупки.
• Средний возраст аудитории. Существует распространенное мнение, что сматфонами активнее пользуется молодое поколение. Я не нашел более серьезной статистики, и посмотрел по одному из проектов с достаточно большим количеством посещений к статистике которого у меня был доступ. С смартфонов сайт просматривало 4% пользователей младше 25, но 12% старше. А для ПК эта статистика составляла 16% к 48%. Разница ровно в 3 раза в обоих случаях. Это говорит нам о том, что возраст на самом деле можно и не учитывать всерьез.
  Интересно что для планшетов статистика показала 1.6% к 5.8%. 5.8/1.6 = 3.8. То есть старшее поколение активнее пользуется планшетами, чем младшее. Я понимаю, что это всего один проект и по нему не стоит делать глобальных выводов, но все же любопытно.
• Отношение аудитории к бонусным программам. Давайте договоримся о шкале от 0 до 1. Если вы продаете что-то для юридических лиц, то, как правило напротив этого пункта можноставить число близкое к 0. Если же ваша аудитория активная и имеет возможность поразбиратся в бонусных программах, то число тут будет ближе к 1. Например, для детски товаров я бы поставил 0.8-0.9, по тому, что «мамочки» очень любыт раличные скидки и бонусы.
• Частота покупок. Предлагаю измерять в среднем количестве покупок от одного пользователя в неделю. Понятно, что продукты мы покупаем чуть ли не каждый день, а машину большинство меняет раз в несколько лет. Чем чеше будет покупать конкретный пользователь, тем больше профита он получит от установки приложения.
• Сезонность товаров. Чем равномернее распределяются покупки по времени, тем, опять же, выгоднее будет приложение.

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

Вывод

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

Singleton — первый шаблон проектирования о котором я узнал. Очень хорошо помню этот момент, по тому, что было это на собеседовании. Мое первое и, если честно, единственное техническое собеседование. Как уже догадался читатель, на вопрос «что такое синглтон и с чем его едят» я только удивленно моргал глазами. Правда, на работу меня все равно взяли. Может быть по тому, что после об]яснения мне в двух словах сути, общий механизм построения я описать смог.

Если что-то хочет познакомится с этим и гругими порождающими шаблонами, то можно обратиться к «банде четырех» или , ближе ко мне, Мэтт Зандстра – PHP. Объекты, шаблоны и методики программирования. Когда мы говорим про веб-разработку, то обычно мы слышим такие применения для Синглтона:

Первый пример

Первый, самый популярный, на мой взгляд, пример — подключение к базе данных. Это всегда казалось мне какой-то шляпой. Используя Синглтон мы гарантируем, что подключимся к база данных только один раз, а в дальнейшем будем использовать это подключение. Но что, если у нас несколько баз данных? «Ок,» — скажут знатоки — «если все реализовать правильно, то мы будем гарантировать, что к конкретной базе не будем подключаться более одного раза». Ну а если база одна, но коннектиться нужно от разных пользователей? «Ок,» — скажут знатоки, обозвав меня занудой и любителем придумывать проблемы — «ты можешь все написать так, что гарантируешь, что подключение к одной базе от имени одного пользователя будет единственно и его-то ты и будешь использовать дальше. И вообще суть в том, что ты сможешь использовать подключение в других классах не передавая его явно». А почему я не могу использовать global? Или просто статический метод? «Просто ты дурак и любишь поспорить. Это все гораздо хуже.» Это я слышал в разных интерпретациях много раз.

Второй пример

Второй пример — конфиг в синглтоне. Суть в том, что мы можем задать в нем любую переменную, а к ней геттер и сеттер. Тут суть иллюстрируется таким кодом:

$class1 = myClass::getInstance();
$class2 = myClass::getInstance();
$class2->setA(3);
$class1->setA(5);
echo $class2->getA(); //5

То есть мы всегда гарантируем, что в любой момент времени в любом классе переменная A будет единой для всей системы. Чем это отличается от глобальных переменных, про которые любой новичок скажет, что «Так писать нельзя» ? Мне всегда было непонятно.

Другие примеры мне долгое время не встречались и я не понимал, нафига тогда этот синглтон нужен на самом деле и почему он делает код лучше. И вот сегодня ко мне пришло откровение

Мой вариант

В одном из наших проектов сложная система расчета цен для разных пользователей. Все началось с того, что все пользователи делятся на несколько ценовых групп, в каждой из которых есть своя наценка на каждую группу товаров. Позже оказалось, что есть поставщики с другой политикой. Они предоставляют прайс «для всех», а диллерам и постоянным покупателям дают от него скидки. Соответственно модель наценок на каждую товарную группу превратилась в модель наценка-или-скидка. Но и это еще не все. Есть клиенты (и их много), которые давно работают с нашими заказчиками и у них есть особые условия – специальная скидка или наценка на конкретный товар или группу товаров.

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

Итак, та-да-а-ам. Меня спас Синглтон. Паттерн гарантировал мне, что я лишь однажды запрашиваю из базы информацию о наценках/скидках, товарах и клиентах. А обрабатываю её по мере надобности. Так как запрос из базы самая «толстая» операция и мне удалось сократить количество запросов с примерно 80 до 3-4, мы получили прирост в производительности расчета примерно в 10 раз.

На практике это означает, что все стало «летать». И все благодаря тому, что мы не делаем лишних запросов к базе, за счет Синглтона.

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

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

1) Наш сайт phoenix-cg.ru итак диктовать и запоминать тяжко. Это связано с наличием дефиса и буквы C, которая как «си», так и «эс». Кроме того русскоговорящих часто ставит в ступор, что «Ф» иногда это «Ph», а «Феникс» пишется, как «Phoenix».
2) Эти три буквы с появлением DNS были уже никому не нужны и оставлены для обратной совместимости. Это произошло еще до массового распространения интернета, а значит ими можно было пожертвовать почти с самого начала. В современном вебе «ВВВ» перед каждым сайтом вообще смысла не имеют. Кто сейчас хотя-бы расшифровку этой абрривиатуры вспомнит?
3) Мне дико нравится идея писать почту, сайт и, может, твиттер одной строкой.

Коллеги мне на это возражали, что

1) Существует много народу, кто без www сайты никогда не ищет. И возможно, в их числе наши потенциальные клиенты.
2) Так принято. Можем посмотреть на кучу визиток и везде «www».

Расследуем

Я решил разобраться в этом вопросе подробнее. Для начала поискал в интернете визитки, сделанные известными веб-дизайнерами. Вот те, которые без «www»: (можно листать)

А вот те, которые с: (можно листать)

На многих картинках сайта не видно. Если мне не верите, то можно нагуглить их по названию компании.

«Очки» распределились почти поровну. Конечно, мой часовой поиск в интернете не дает сколько-нибудь репрезентативных результатов, но можно констатировать, что оба варианта распространены.

И что делать?

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

В этой моей убежденности меня укрепил Артемий Лебедев в своем совете о визитке Владимира Владимировича Путина. Надо соответствовать своей эпохе и быть понятным. Вот и все выводы из этой истории.

В конце сентября учавствовал в конкурсе на переверстку плаката. Итоговый плакат получился ниже среднего, если не сказать жестче. Тем не менее, для себя я результат считаю положительным, по тому, что основной задачей была «проба пера». О процессе я создал отдельную страничку. А результат могу продублировать тут:

Если кому-то интересно, то вот результаты.

За три года, что я работаю в web-разработке мне как-то удавалось избегать самого популярного в мире движка, не считая совсем мелких правок. Но мне приходилось слышать от коллег различные мнения от «Какое извращение превращать блог в магазин, форум и все, что угодно!» до «Вполне адекватная CMS для небольших проектов.» И вот предоставилась возможность поработать с WordPress воочию.

Первый блин

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

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

В переносе мультисайта мне помогли заметки SiteHint.ru и WP MAGAZINE. Как я понял, сложности связанные с этим давно известны сообществу WP и обсуждать их смысла нет. Наверное, этой заметки бы не было, если бы сайт «завелся» сразу после этого без проблем.

Настоящее веселье

Самое интересное началось, когда я думал, что перенос уже завершен успешно. Один из разделов (всего один и самый важный!) загружался не до конца. То есть просто в какой-то момент html код обрывался, как говорится «на самом интересном месте».

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

define(‘WP_DEBUG’, false);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);

до прямых директив

ini_set(‘log_errors’,’On’);
ini_set(‘display_errors’,’Off’);
ini_set(‘error_reporting’, E_ALL );

Ничего ни на экране, ни в логах. Все чисто, но где-то работа скрипта обрывается.
«Уф», подумал я, и приступил к ковырянию в скриптах. Что бы не мучить читателя сразу расскажу о результатах расследования. Оказалось, что падает кеширование, а именно функция

update_meta_cache(‘post’, $post_ids);

А в ней проблема возникает во время запроса кэша из БД:

$meta_list = $wpdb->get_results( “SELECT $column, meta_key, meta_value FROM $table WHERE $column IN ($id_list) ORDER BY $id_column ASC”, ARRAY_A );

И, наконец, изучив объект $wpdb я нашел место падения

while ( $row = @mysqli_fetch_object( $this->result ) ) {
$this->last_result[$num_rows] = $row;
$num_rows++;
}

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

Решение

Убрав собачку я увидел уже истинную причину проблем:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 81 bytes) in /var/www/path_to_script/wp-db.php on line 1684

Временно забыть о проблеме с памятью удалось заменив в wp-config.php

define(‘WP_MEMORY_LIMIT’, ‘64M’);

На

define(‘WP_MEMORY_LIMIT’, ‘128M’);

Конечно, нужно искать причину, почему скрипт «жрет» столько оперативки, но это уже не срочно.

Как так

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

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

P.S. Все вышесказанное о движке WordPress 4.1.8