Угодить целевой аудитории это тоже «точка зрения продавца» — основная часть его бизнеса. Поверьте мне, как владельцу нескольких магазинов :) Иначе бизнес прогорит и он не получит своих денег. Так что тут все завязано.
Ну я же писал — «нет хороших и плохих — есть правильно выбранные инструменты
под вашу бизнес-модель и есть неправильно выбранные». Т.е. я знаю людей, счастливых от неумелой поделки студентом на коленке. Хотя это редкое исключение. И плюющихся от Битрикса.
Я конечно могу назвать движки, но если они не подходят к интернет-магазину велосипедов — это не значит что они плохие. И для магазина электроники могут подойти идеально. А мы их возьмем и обидим :) Это ИМХО лишнее.
Сочтут за пиар. Опять же, это будет противоречить основному тезису статьи —
Главное — выбирать, руководствуясь практикой своей работы, а не внешним видом, прикольной фичей для покупателя или рекомендацией «на одном авторитетном форуме». Тестируйте демонстрационный движок со всех сторон и не тратьте деньги зря. :)
Наборы фильтров и подбор по характеристикам хорош тут: bodyshop.com.ua/dir.php?id=64 причем видно, что часть характеристик сквозные по сайту, а часть специфические в разделе
Вероятно мы по разному понимаем «лаги». Дело не только в чистом рафинированном пинге внутри сети. Вы ведь не думаете, что время отклика 5-10ms сохранится если ходить на ваш сервер через спутник и через кучу независящих от вас каналов?
«Некоторое органичение многопользовательскости» (опять же это касается именно Двуядерной схемы) это например случай, если вы будете работать с вашим сервером изнутри сети, а из Австралии сеть вдруг стала недоступной(в то время как сам сайт магазина — по прежнему нормально работает). Либо просто десктоп будет тормозить так сильно, что практически будет неработоспособен. Мы ведь писали его в рассчитывая на быстрый локальный интернет, соответственно десктоп будет гонять много данных, включая тяжелые картинки. И их там не факт что можно будет отключить, как в браузере. Хотя это конечно зависит от реализации. Т.е. вы не сможете набрать например фрилансеров-китайцев для набивки в магазин товаров. С базой смогут работать только пять человек в вашей локальной сети. Потому что пинг то быстрый только для вас, верно? ;)
Ну и моя исходная формулировка «некоторых случаях ограничение многопользовательского режима» стреляет намного в большей мере, если база находится не в сети, к которой вы грамотно настроили доступ отовсюду, а на том же локальном компьютере что и десктоп. Частный случай реализации двуядерной схемы. Так реализовано в Melbis.
Дело в том, что десктоп при обычной архитектуре клиент-сервер при нашем обычном интернете точно также будет «бить лагами». Для того, чтобы их убрать — вам надо иметь локальную копию данных с которыми работаете. И тут уже возможны варианты.
1. Ну очень умное кеширование зашитое в десктоп. Честно говоря пока не встречал, да и не всегда это в принципе возможно. Но потенциально могут быть рабочие красивые решения.
2. Десктоп работает с основной копией базы которая опять же лежит рядом (на этом же компьютере, в этой же локальной сети, в этой же точке обмена — короче очень быстро), а база в «большом интернете» строится на основе вашей — локальной-боевой. Т.е. грубо говоря мы работаем с близкой базой которая так или иначе(вероятнее асинхронно) реплицируется с далекой базой. Реализации репликации могут быть абсолютно разными, но ясно одно — ваша «близкая база» в любом случае является «далёкой» для человека из Австралии, например. Т.е. ему «будет медленно», ежели конечно «будет» вообще. А «быстро» будет только для сидящих в этой локально сети (на этом компьютере). Это я и называю ограничение многопользовательского режима.
3. Есть еще промежуточное крайне интересное решение, похожее скорее на первый пункт. Когда основная база лежит все таки в «большом интернете», а локальная база (с которой идет непосредственно работа) строится из основной. Пользователь работает с ней, а потом данные возвращаются в основную. Пока таких внедренных решений мне неизвестно, но точно знаю что в этом году мы увидим одно такое ;)
P.S. Зануд прошу не пинать меня за то, что я называю асинхронной репликацией то, что скорее является «управляемым копированием» или «ручной синхронизацией». Это вопрос терминов, а мне просто не хочется усложнять текст.
Безусловно, можно найти и очень крупные магазины на таком решении. Кроме того, на ИНМАРСИС десктопная админка вероятно была бы не оптимальна — на площадку добавляют товары десятки тысяч разных людей — в данном случае кроссплатформенность и доступность с любого компьютера важнее чем производительность труда.
Я думаю решить, что есть заблуждение, поможет время :) Если вы владелец магазина — вы сможете проверить и сравнить описанные мной два подхода. Ведь лучшая проверка в таком случае — это заработанные магазином деньги, не так ли? ;)
Ну, про ОЗОН придумал не автор. Источник залинкован — все претензии к Майкрософту :) А я хотел ознакомить общественность с вариантами построения интернет-магазинов. К слову, если бы вы были внимательны, вы бы увидели, что все описанные в статье решения появились задолго до Core 2 Duo ;)
Данные есть, но это не «нотариально заверенные скриншоты», а «коллега на конференции поделился за чашкой кофе». Поэтому выкладывать я их не буду :) У меня кроме Озона данные еще про два крупных российских магазина. И про два универсальных движка, которые я привел в посте. На их основе магазинов не мало. Но в целом, если вы прочитали статью про ОЗОН, на сайте Майкрософта — вопросы про такое решение должны были отпасть. Опять же, вероятно, не так много магазинов на двухъядерной архитектуре. И не так много магазинов в принципе светят то, как они устроены.
Но если вы укажите информацию, что крупные магазины с двухъядерной архитектурой не используют десктоп, а работают через браузер — я приму такую инфу и подкорректирую пост в соответствии с новой информацией.
Это довольно просто. Для багтрекинга практически не могут понадобится групповые операции над большой группой данных, как это может часто быть необходимым в магазине, также не требуется оператично вычитывать множество данных, снабженных графикой на одной странице и быстро по ним перемещаться. Не требуется добавление большого количества данных, как и не требуется автоматизация такого добавления. Что нужно для багтрекинга? Ну текст, ну скриншот, ну аттач скриптов. Смысла в десктопе никакого. Аналогичный ответ и для CMS для сайтов. Единственное узкое место — загрузка фотографий пачками — реализуется небольшим жаба-апплетом… И десктоп не нужен. У десктопа ж тоже минусы есть некоторые. Внекоторых случаях ограничение многопользовательского режима, сложность, дороговизна, иногда меньшая кроссплатформенность.
Уважаемый разработчик. Я почитал описание и не совсем понял, что именно отличает вас от конкурентов и почему следует предпочесть вас. В частности, интересует чем вы лучше чем shopscript и phpshop. Ведь выходя на рынок следует показать отличие от других, верно?
взлом интернет-магазина не так страшен как кажется. И он возможен. Всегда. Независимо от того, сами вы пишете движок или нет. Магазин может сломать уволившийся сотрудник провайдера, пароль на FTP может стырить троян, неопределенный лицензионным касперским, может отснифферить сотрудник провайдера… Вариантов миллион. Это нужно учитывать, но тратить год на написание своего движка — это самое малоэффективное решение. Тем более, что тот, кто вам пишет движок, может написать его намного менее защищенным, чем готовое решение, которое проверядось годами и писалось весьма квалифицированной командой… Интернет-магазин это Бизнес. Ничего более. А значит надо просто считать деньги. Во многих случаях написание своего движка экономически невыгодно, а взлом сайта практически не страшен. Это ральность.
Все очень просто. Мы должны посмотреть на то, окупает ли заработок на товаре время менеджера колл-центра. Если, допустим, на товаре мы зарабатываем 100 баксов, то стимулировать делать электронный заказ — странно. Нужно напротив, максимизировать звонки — и посадить менеджеров, таких, которые железно уговорят клиента на покупку, а может быть и на несколько.
Если на товаре мы зарабатываем 1 бакс, то можно так и написать — «у нас суперцены, которые не могут окупить содержание колл-центра». Пишите письма :)
Отличная статья. На 90% сайтов CMS написаны одни и те же вещи… Именно поэтому нужно разделить подход — «описание для ньюбов, клиентов», которым важно, что «есть древовидный каталог рубрик», и для продвинутых пользователей, где будут описываться действительно уникальные особенности системы, которыми она отличается от конкурентов.
Собственно существуют механизмы, когда мы можем отследить контакты именно с сайта компании. Если есть возможность их отслеживать, то возможно и отслеживать продажи или контакты «через интернет». А следовательно мотивировать сейла(менеджера, начальника интернет-подразделения — не суть важно) например процентом от сделок с этими клиентами. Такая мотивация — сильнейший стимул чтобы отдел занимался и юзабилити и конверсией и вообще всем что необходимо — и сайт был идеальным.
Что вы о ней скажете? ;)
под вашу бизнес-модель и есть неправильно выбранные». Т.е. я знаю людей, счастливых от неумелой поделки студентом на коленке. Хотя это редкое исключение. И плюющихся от Битрикса.
Я конечно могу назвать движки, но если они не подходят к интернет-магазину велосипедов — это не значит что они плохие. И для магазина электроники могут подойти идеально. А мы их возьмем и обидим :) Это ИМХО лишнее.
Главное — выбирать, руководствуясь практикой своей работы, а не внешним видом, прикольной фичей для покупателя или рекомендацией «на одном авторитетном форуме». Тестируйте демонстрационный движок со всех сторон и не тратьте деньги зря. :)
Наборы фильтров и подбор по характеристикам хорош тут: bodyshop.com.ua/dir.php?id=64 причем видно, что часть характеристик сквозные по сайту, а часть специфические в разделе
«Некоторое органичение многопользовательскости» (опять же это касается именно Двуядерной схемы) это например случай, если вы будете работать с вашим сервером изнутри сети, а из Австралии сеть вдруг стала недоступной(в то время как сам сайт магазина — по прежнему нормально работает). Либо просто десктоп будет тормозить так сильно, что практически будет неработоспособен. Мы ведь писали его в рассчитывая на быстрый локальный интернет, соответственно десктоп будет гонять много данных, включая тяжелые картинки. И их там не факт что можно будет отключить, как в браузере. Хотя это конечно зависит от реализации. Т.е. вы не сможете набрать например фрилансеров-китайцев для набивки в магазин товаров. С базой смогут работать только пять человек в вашей локальной сети. Потому что пинг то быстрый только для вас, верно? ;)
Ну и моя исходная формулировка «некоторых случаях ограничение многопользовательского режима» стреляет намного в большей мере, если база находится не в сети, к которой вы грамотно настроили доступ отовсюду, а на том же локальном компьютере что и десктоп. Частный случай реализации двуядерной схемы. Так реализовано в Melbis.
1. Ну очень умное кеширование зашитое в десктоп. Честно говоря пока не встречал, да и не всегда это в принципе возможно. Но потенциально могут быть рабочие красивые решения.
2. Десктоп работает с основной копией базы которая опять же лежит рядом (на этом же компьютере, в этой же локальной сети, в этой же точке обмена — короче очень быстро), а база в «большом интернете» строится на основе вашей — локальной-боевой. Т.е. грубо говоря мы работаем с близкой базой которая так или иначе(вероятнее асинхронно) реплицируется с далекой базой. Реализации репликации могут быть абсолютно разными, но ясно одно — ваша «близкая база» в любом случае является «далёкой» для человека из Австралии, например. Т.е. ему «будет медленно», ежели конечно «будет» вообще. А «быстро» будет только для сидящих в этой локально сети (на этом компьютере). Это я и называю ограничение многопользовательского режима.
3. Есть еще промежуточное крайне интересное решение, похожее скорее на первый пункт. Когда основная база лежит все таки в «большом интернете», а локальная база (с которой идет непосредственно работа) строится из основной. Пользователь работает с ней, а потом данные возвращаются в основную. Пока таких внедренных решений мне неизвестно, но точно знаю что в этом году мы увидим одно такое ;)
P.S. Зануд прошу не пинать меня за то, что я называю асинхронной репликацией то, что скорее является «управляемым копированием» или «ручной синхронизацией». Это вопрос терминов, а мне просто не хочется усложнять текст.
Но если вы укажите информацию, что крупные магазины с двухъядерной архитектурой не используют десктоп, а работают через браузер — я приму такую инфу и подкорректирую пост в соответствии с новой информацией.
Если на товаре мы зарабатываем 1 бакс, то можно так и написать — «у нас суперцены, которые не могут окупить содержание колл-центра». Пишите письма :)