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

Часто я слышу от клиентов такие слова, как «движок», «ядро», «Цеэмэска». Как правило под всем этим подразумевается некая web-система, которую можно поставить платно либо бесплатно и которая уже сделала за программиста половину его работы. Обратите внимание, для многих клиентов сайт делает программист. На самом деле, конечно в процессе создания сайт может участвовать множество людей, часть из которых — разработчики. Это дизайнеры, верстальщики, фронт- и бекенд программисты и все, кто создает сайт и хочет называть себя разработчиком. Такое понимание, конечно же, в корне не верное.

Начну с того, что тут не так. С точки зрения разработчика, как я уже отмечал, CMS система — одна из компонент проекта. При этом, далеко не всегда это «основа». «Ядром», или лучше сказать основной разработки, может послужить фраемворк, может совокупность отдельных готовых модулей. Это может быть даже одна отдельно взятая библиотека или же такой основы может вовсе не быть. Все это должно волновать заказчика в последнюю очередь, так же, как и стул, на котором сидит дизайнер или текстовый редактор, которым пользуется менеджер проекта. Все это — внутренние вопросы, которые помогают или мешают исполнителям решать проблему заказчика.

Так почему же заказчики часто настаивают на использовании готовых многофункциональных CMS систем? Существует несколько причин. Разберу основные.

Экономия

Вполне логично предположить, что если разработчики будут пользоваться готовыми компонентами, то работы окажется меньше, а следовательно стоить она будет дешевле. Тут есть здравое зерно. Однако, первое, что стоит понимать, что это, возможно, экономия для разработчиков, но не для клиента. Цена проекта будет такой, на которую вы договоритесь и никакие внутренние процессы на нее не повлияют. Ни разу не слышал, что бы клиент предлагал разработчику перейти на выбранную им CMS и цена сайт падала, скорее в жизни бывает наоборот. Если разработчики смогли где-то сэкономить, то это их личная победа, так же, как и обратная ситуация — если у разработчиков внутри ваших договоренностей что-то пошло не так, то это не должно лечь на плечи клиента. По крайней мере и то и другое — предмет переговоров, но никак не снижение/повышение цены автоматом.
Тут есть и второй момент. Заключается он в том, что упросить ли использование каких-то готовых компонент разработку зависит от конкретных разработчиков и от конкретного проекта. Любой профессиональный веб разработчик способен, в итоге, разобраться в любом чужом компоненте, но сколько уйдет на это времени и как конкретно он поможет проекту вопрос сложный и всегда открытый.

Страх выбора плохого разработчика

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

Опыт работы

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

Функциональность будущего сайта

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

Откуда ноги ростут

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

P.S. Для тех, кто не знает о ком я, посмотрите рейтинг CMS рунета. На картинке рейтинг платных CMS по версии iTrack.

В общем случае на этот вопрос, конечно же, ответа нет. Понятно, что под «делают сайт», можно подразумевать все, что угодно. Гугл, например, то же сайт. В крупных интернет-изданиях трудятся десятки, а иногда и сотни человек. Так что тему этой заметки я сужу так «какое оптимальное число человек должна работать в веб-студии над одним проектом?» Предположим, что существует некий заказчик, который берет на себя все вопросы, кроме непосредственно связанных с разработкой сайта. Допустим так же, что мы рассматриваем случай именно разработки сайта с самого начала и до запуска проекта. Так же оговоримся, что мы рассматриваем только «производственную часть», без различных менеджеров, переговорщиков и директоров. Все эти люди, безусловно, очень важны для проекта, но сегодня мне интересно порассуждать именно о технической стороне вопроса.

Что еще за проект?

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

Итак, есть абстрактный «крупный проект». Сколько оптимально выделить людей для его осуществления? Еще раз оговорюсь, что рассматриваю абстрактный случай, в котором есть четкое ТЗ и оно не изменно от начала и до конца работ. Да, я знаю, что такого не бывает. Но, если все-же представить себе этот случай, то, скорее всего, такое ТЗ будет включать в себя уже разработаенный и тщательно продуманный дизайн. Так что говорить мы будем только о разработчиках.

Математический метод

Пойдем математическим путем. Мы точно знаем, что 0 разработчиков сделать сайт не могут и их эффективность ровно ноль. Так же мы точно знаем, что бесконечное число разработчиков будет искать способы взаимодействия бесконечно долго и иметь бесконечно малую ответственность, так что их эффективность то же нулевая. Учитывая тот факт, что сайты все же существуют мы можем сказать, что есть некое число разработчиков, эфективность которых отлична от 0. Из курса матанлиза нам известна теорема Ролля, согласно которой при таких условиях существует некое оптимальное число разработчиков, эффективность которых максимальна. Попробуем это число найти.

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

Упрощенная модель

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

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

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

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

Столбиком на границе разработчиков я обозначил затраты на взаимоействие. Извиняюсь, за кривые графики, но надеюсь всем видно, что два разработчика – оптимально. При трех величина «слолбиков» взаимодействия будет больше чем профит. Конечно, это все верно для нарисованного мной проекта и моих данных. Однако, если форма графика неизменна, то всегда 2 или 3 разработчика оказываются оптимальным числом.

Вспомним так, же, что я предложил делить разработку на фронтенд и бекенд. Часто слабый в бекенде разработчик может так же присоединится к фронтенду. Так что идельный размер команды минимум 3 (по два на каждом графике, но один из разработчиков один и тот же человек) и максимум 6 человек.

Что делать, если проект требует бОльшего числа разработчиков для ускорения процесса? Делить его на более мелкие проеты, мало зависящие друг от друга. Вот такой вывод у меня получился сегодня. А вообще все это можно воспринимать, как шутку.

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

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

Теперь, когда мы упростили себе задачу, можно абстрактно рассуждать о том, нужно ли нам приложение и как мы сможем его использовать для получения дополнительной прибыли. Честно скажу, что до недавнего времени я сам очень мало пользовался приложениями на своем андроиде и не понимал, как приложение может быть отдельным каналом привлечения клиентов, ведь, как мне казалось, мало кто просто так ставит себя приложения. Однако, по данным Яндекса среднестатистический пользователь устанавливает 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». Однако, если найдется хоть один человек, кто испытает трудности с понимаем, что перед ним адрес сайта, то наша компания потеряет потенциального клиента/партнера, а, возможно, вместе с этим и деньги.

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