Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
может хабракат поставить?
Подскажите, как специалист, почему для управления интернет-магазином десктоп клиент считается удобнее чем веб-клиент, а для уравления проектами (bugtracking, project management, jira, bugzilla, track) — с точностью до наоборот? С местной колокольни разница мало заметна :(
Это довольно просто. Для багтрекинга практически не могут понадобится групповые операции над большой группой данных, как это может часто быть необходимым в магазине, также не требуется оператично вычитывать множество данных, снабженных графикой на одной странице и быстро по ним перемещаться. Не требуется добавление большого количества данных, как и не требуется автоматизация такого добавления. Что нужно для багтрекинга? Ну текст, ну скриншот, ну аттач скриптов. Смысла в десктопе никакого. Аналогичный ответ и для CMS для сайтов. Единственное узкое место — загрузка фотографий пачками — реализуется небольшим жаба-апплетом… И десктоп не нужен. У десктопа ж тоже минусы есть некоторые. Внекоторых случаях ограничение многопользовательского режима, сложность, дороговизна, иногда меньшая кроссплатформенность.
Сложность и дороговизна — это да. Если есть чуток свободного времени, можете уточнить про ограничения многопользовательского режима? Я сейчас прицениваюсь что бы получше внедрить для управления одним из проектов, выбираю между вебом и desktop. Веб пока очень больно бьет лагами ( полсекунды-секунда конечно фигня, но на каждой операции — сильно раздражает. Я даже знаю почему раздражает — устройство человеческого мозга ) и отсутствием правого клика мышью. Десктопа нет в природе, но можно очень быстро написать самому.
Дело в том, что десктоп при обычной архитектуре клиент-сервер при нашем обычном интернете точно также будет «бить лагами». Для того, чтобы их убрать — вам надо иметь локальную копию данных с которыми работаете. И тут уже возможны варианты.
1. Ну очень умное кеширование зашитое в десктоп. Честно говоря пока не встречал, да и не всегда это в принципе возможно. Но потенциально могут быть рабочие красивые решения.
2. Десктоп работает с основной копией базы которая опять же лежит рядом (на этом же компьютере, в этой же локальной сети, в этой же точке обмена — короче очень быстро), а база в «большом интернете» строится на основе вашей — локальной-боевой. Т.е. грубо говоря мы работаем с близкой базой которая так или иначе(вероятнее асинхронно) реплицируется с далекой базой. Реализации репликации могут быть абсолютно разными, но ясно одно — ваша «близкая база» в любом случае является «далёкой» для человека из Австралии, например. Т.е. ему «будет медленно», ежели конечно «будет» вообще. А «быстро» будет только для сидящих в этой локально сети (на этом компьютере). Это я и называю ограничение многопользовательского режима.
3. Есть еще промежуточное крайне интересное решение, похожее скорее на первый пункт. Когда основная база лежит все таки в «большом интернете», а локальная база (с которой идет непосредственно работа) строится из основной. Пользователь работает с ней, а потом данные возвращаются в основную. Пока таких внедренных решений мне неизвестно, но точно знаю что в этом году мы увидим одно такое ;)
P.S. Зануд прошу не пинать меня за то, что я называю асинхронной репликацией то, что скорее является «управляемым копированием» или «ручной синхронизацией». Это вопрос терминов, а мне просто не хочется усложнять текст.
1. Ну очень умное кеширование зашитое в десктоп. Честно говоря пока не встречал, да и не всегда это в принципе возможно. Но потенциально могут быть рабочие красивые решения.
2. Десктоп работает с основной копией базы которая опять же лежит рядом (на этом же компьютере, в этой же локальной сети, в этой же точке обмена — короче очень быстро), а база в «большом интернете» строится на основе вашей — локальной-боевой. Т.е. грубо говоря мы работаем с близкой базой которая так или иначе(вероятнее асинхронно) реплицируется с далекой базой. Реализации репликации могут быть абсолютно разными, но ясно одно — ваша «близкая база» в любом случае является «далёкой» для человека из Австралии, например. Т.е. ему «будет медленно», ежели конечно «будет» вообще. А «быстро» будет только для сидящих в этой локально сети (на этом компьютере). Это я и называю ограничение многопользовательского режима.
3. Есть еще промежуточное крайне интересное решение, похожее скорее на первый пункт. Когда основная база лежит все таки в «большом интернете», а локальная база (с которой идет непосредственно работа) строится из основной. Пользователь работает с ней, а потом данные возвращаются в основную. Пока таких внедренных решений мне неизвестно, но точно знаю что в этом году мы увидим одно такое ;)
P.S. Зануд прошу не пинать меня за то, что я называю асинхронной репликацией то, что скорее является «управляемым копированием» или «ручной синхронизацией». Это вопрос терминов, а мне просто не хочется усложнять текст.
Дело в том, что десктоп при обычной архитектуре клиент-сервер при нашем обычном интернете точно также будет «бить лагами»
Не будет, к сожалению. Сам проверял. Если в локальной сети поставить компьютер с той же Ubuntu (операцонка не принципиальна) и запустить на нем простой TCP сервер на python + sqlite, то подключившийся по TCP клиент будет иметь время отклика на операции 5-10ms. Если на этом же компьютере поставить LAMP и Trac, то задержка на почти все операции будет 500-1000ms (замеряется firebug). Я хз почему так и что именно в лампе и TRAC'е тормозит. Рабочая версия — на каждую операцию выполняется бесконечное количество PHP (python в случае TRAC, но с Bugzilla все то же самое) кода и много-много SQL запросов. Ну и SQL запросы в рамках LAMP видимо тоже не очень быстры.
И потом, десктопному клиенту нет необходимости ждать пока сервер обработает запрос. У нас же запросы по сети и пользовательский интерфейс в разных потоках? :)
Про ограничения многопользовательского режима так и не сказали, а это самое интересное :)
Вероятно мы по разному понимаем «лаги». Дело не только в чистом рафинированном пинге внутри сети. Вы ведь не думаете, что время отклика 5-10ms сохранится если ходить на ваш сервер через спутник и через кучу независящих от вас каналов?
«Некоторое органичение многопользовательскости» (опять же это касается именно Двуядерной схемы) это например случай, если вы будете работать с вашим сервером изнутри сети, а из Австралии сеть вдруг стала недоступной(в то время как сам сайт магазина — по прежнему нормально работает). Либо просто десктоп будет тормозить так сильно, что практически будет неработоспособен. Мы ведь писали его в рассчитывая на быстрый локальный интернет, соответственно десктоп будет гонять много данных, включая тяжелые картинки. И их там не факт что можно будет отключить, как в браузере. Хотя это конечно зависит от реализации. Т.е. вы не сможете набрать например фрилансеров-китайцев для набивки в магазин товаров. С базой смогут работать только пять человек в вашей локальной сети. Потому что пинг то быстрый только для вас, верно? ;)
Ну и моя исходная формулировка «некоторых случаях ограничение многопользовательского режима» стреляет намного в большей мере, если база находится не в сети, к которой вы грамотно настроили доступ отовсюду, а на том же локальном компьютере что и десктоп. Частный случай реализации двуядерной схемы. Так реализовано в Melbis.
«Некоторое органичение многопользовательскости» (опять же это касается именно Двуядерной схемы) это например случай, если вы будете работать с вашим сервером изнутри сети, а из Австралии сеть вдруг стала недоступной(в то время как сам сайт магазина — по прежнему нормально работает). Либо просто десктоп будет тормозить так сильно, что практически будет неработоспособен. Мы ведь писали его в рассчитывая на быстрый локальный интернет, соответственно десктоп будет гонять много данных, включая тяжелые картинки. И их там не факт что можно будет отключить, как в браузере. Хотя это конечно зависит от реализации. Т.е. вы не сможете набрать например фрилансеров-китайцев для набивки в магазин товаров. С базой смогут работать только пять человек в вашей локальной сети. Потому что пинг то быстрый только для вас, верно? ;)
Ну и моя исходная формулировка «некоторых случаях ограничение многопользовательского режима» стреляет намного в большей мере, если база находится не в сети, к которой вы грамотно настроили доступ отовсюду, а на том же локальном компьютере что и десктоп. Частный случай реализации двуядерной схемы. Так реализовано в Melbis.
>>… на практике в этих решениях всегда персонал использует оконный интерфейс
«На практике всегда» — это на примере двух магазинов? Или у вас есть еще данные?
«На практике всегда» — это на примере двух магазинов? Или у вас есть еще данные?
Данные есть, но это не «нотариально заверенные скриншоты», а «коллега на конференции поделился за чашкой кофе». Поэтому выкладывать я их не буду :) У меня кроме Озона данные еще про два крупных российских магазина. И про два универсальных движка, которые я привел в посте. На их основе магазинов не мало. Но в целом, если вы прочитали статью про ОЗОН, на сайте Майкрософта — вопросы про такое решение должны были отпасть. Опять же, вероятно, не так много магазинов на двухъядерной архитектуре. И не так много магазинов в принципе светят то, как они устроены.
Но если вы укажите информацию, что крупные магазины с двухъядерной архитектурой не используют десктоп, а работают через браузер — я приму такую инфу и подкорректирую пост в соответствии с новой информацией.
Но если вы укажите информацию, что крупные магазины с двухъядерной архитектурой не используют десктоп, а работают через браузер — я приму такую инфу и подкорректирую пост в соответствии с новой информацией.
Я не такой сильный специалист по веб-магазинам; однако если не ограничиваться такой нишей, как электронный магазин, а включить туда, например, торговые площадки и порталы (которые, собстно, не столь сильно отличаются по внутреннему устройству), то можно привести как пример ИНМАРСИС, у которого и фронт-офис, и бэк-офис — веб-формата
Безусловно, можно найти и очень крупные магазины на таком решении. Кроме того, на ИНМАРСИС десктопная админка вероятно была бы не оптимальна — на площадку добавляют товары десятки тысяч разных людей — в данном случае кроссплатформенность и доступность с любого компьютера важнее чем производительность труда.
И к слову. Виндовая админка для управления сайтом есть не только для интернет-магазинов. Вот — CMS Encore Pro 1.0.6 (Free Edition) www.freedownloadscenter.com/Web_Authoring/Automated_Web_Publishing_Tools/CMS_Encore_Pro_Screenshot.html
Хотел бы немного поправить автора…
Цель — PHPShop
Архитекутра — 3х ядерная (модуль управления заказами из под J2M)
Архитекутра — 2х ядерная (1С модуль давно перепрягнул OSG, сами 1С-Битрикс советуют PHPShop в качетсве замены своей платформы)
Архитекутра — 2х++ ядерная (в комлекте идет имулятор сервера для Windows с возможностью 100% синхронизации данных с хостингом)
Архитекутра — 2х+++ ядерная (синхронизация 2х++ с флешкой — возможность копирование имулятора на флешку с сохранением ) 2х++
Ссылки для чтива:
phpshop.ru/news/ID_219.html
phpshop.ru/news/ID_217.html
phpshop.ru/news/ID_211.html
Цель — PHPShop
Архитекутра — 3х ядерная (модуль управления заказами из под J2M)
Архитекутра — 2х ядерная (1С модуль давно перепрягнул OSG, сами 1С-Битрикс советуют PHPShop в качетсве замены своей платформы)
Архитекутра — 2х++ ядерная (в комлекте идет имулятор сервера для Windows с возможностью 100% синхронизации данных с хостингом)
Архитекутра — 2х+++ ядерная (синхронизация 2х++ с флешкой — возможность копирование имулятора на флешку с сохранением ) 2х++
Ссылки для чтива:
phpshop.ru/news/ID_219.html
phpshop.ru/news/ID_217.html
phpshop.ru/news/ID_211.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Возможные архитектуры построения ПО интернет-магазинов