remusok: RoR - потому что можно быстро реализовать сложный проект с индивидуальной функциональностью. Преимущества с точки зрения заказчиков и конечных пользователей — это сокращение сроков и стоимости разработки, легкое внесение изменений и расширение функциональности. По сравнению с php, RoR разработчиков на рынке меньше, но найти их всегда можно.
Любой язык программирования есть язык. Его возможности обусловлены наличием библиотек. В PHP таких библиотек не меньше чем в RoR, просто вы их не знаете, отсюда и ваши заблуждения на счет сроков разработки и прочего. А дефицит исполнителей это неизбежно рост стоимости владения сайтом.
der_Patriot: Приветствую. Ищу инфу следующего содержания, прошу ткнуть носом или направить в нужном направлении:
1. Основные особенности современного интернет-магазина (ИМ) в рунете. 2. Всякие технические детали (стоит ли, допустим, гнаться за скоростью загрузки сайта или полностью сосредоточиться на юзабилити и пр.; как должна выглядеть карточка товара, какими должны быть фотки и т.д.).
3. ИМ с точки зрения продвижения в поисковиках (интересуют максимально белые, долгосрочные способы).
4. ИМ в Директе/Adwords.
В общем, хочется вникнуть в эту тему, представить четкую картинку качественного, современного ИМ. Есть ли хорошие учебники/руководства/сайты по этой тематике? Многое зависит от ниши и прочих факторов, но пока интересует общая инфа.
Попробуйте начать отсюда http://smartceo.ru. Материал правда не полный и местами сыроват. Сейчас работаю над систематизацией накопленного материала. Надеюсь скоро выложить. Если интересует что-то более конкретное пишите.
Четверьг: Всем привет!
Есть ИМ, в нем- товары, категории.
Ассортимент- величина переменная. Какие-то товары вводятся в ассортимент, какие-то выводятся, снимаются с производства, появляются новые модели.
Т.е. двигать ключи- модели товаров, неактуально из-за временности этих ключей.
Двигать категории, можно, но есть ли смысл?
Категорий много, частотность очевидных ключей невелика. В итоге, приходится расширять СЯ, включать ключи не только с названиями бренда, а и более общие, по функционалу, брать ВЧ, СЧ.
Например, магазин Ентер или Связной. Они вообще пользуются СЕО? Оно им нужно?
Вы пользуетесь СЕО для магазина, где много каталожных товаров? Каталожные я имею ввиду товары типа "Телевизор Сони КТ530-4352 ЛСД 50 дюймов".
ПС: с позволения модераторов создам похожую тему в ветке СЕОшников, т.к. здесь в основоном, магазинщики, а там СЕОшники, и у них может быть другой взгляд на эту тему.
Если под СЕО понимается SEO, то это реклама. Вопрос - нужна ли реклама в торговле? Если денег - куры не клюют, то SEO можно заменить огромным рекламным бюджетом на Директы и АддВоррдсы и не напрягаться по поводу движения к топу выдачи.
Крупные магазины возможно SEO как средством привлечения посетителей и не используют. Мелкие вынуждены использовать рекламный бюджет только для первоначального привлечения, а потом двигаться вверх за счет SEO и других средств.
Да, и еще, большинство продавцов и сеошников, ошибочно полагают, что потенциальный покупатель ищет в сети именно товар, поэтому и двигать пытаются каждый товар в отдельности. Очевидно что в магазинах с большой номенклатурой это не реально.
Lacos: e_v_medvedev, Большое спасибо за ответ! Используем модуль Ругенто, настраиваемые товары да, это отдельное веселье))) Но вроде получается у программиста, причем без изменения конфигурации 1С, разве что только местами приходится менять что-либо в ведении номенклатуры))) Но так как и 1С и сайт с нуля - нестрашно все это. Хотелось бы понять, почему именно неудобно делать полный обмен между УТ и CMS. Поэтому, собственно, и спросил...
Ну да, другой вариант прописывания связи группирующего и группируемых товаров это отразить связь через правильное формирование артикулов. А для синхронизации цен и остатков выгрузка всего объема данных в CommerceML не разумна. Обработка объемных файлов XML съедает много вычислительных ресурсов у хостинга (проще использовать CSV файл). Правда я возможностей модуля Ругенто не знаю. Может для первоначальной заливки он от части и подойдет, но все равно нужно будет проводить поисковую оптимизацию контента и делать это в 1С не рационально. Правда как известно "дьявол кроется в деталях". Может конкретно для вашего случая решение вполне приемлемое.
Lacos: e_v_medvedev, То есть, Вы считаете, что проще будет фото и описания напрямую в CMS грузить (в нашем случае Magento)? Или дело не в том, что проще, а как правильнее))))
Мой опыт работы с клиентами, имеющими сайты на Мадженто и 1С подсказывает именно такой вариант. В 1С как правило ведется минимум данных, предназначенных для идентификации товара, а не для его демонстрации со всех сторон и в лучшем виде. В результате приходится сначала выгружать данные из 1С в какой то промежуточный формат, потом добавлять туда данные, необходимые для SEO (подготовленные другими средствами), и потом заливать в базу сайта. То есть проблема в том, что без промежуточной обработки данные из 1С в базу заливать не получается. А есть еще проблемы с импортом настраиваемых товаров. Тогда и 1С нужно будет допиливать. Так что универсального решения не получится.
Lacos: Добрый день! А подскажите, в чем именно "неудобность" такого решения? Как раз сейчас организовываем именно это (полный обмен 1С УТ и CMS), может быть зря? :)
Тухлое занятие. Метаданных в 1С все равно не хватает. Да и картинок в торговом зале как правило нужно больше чем в системе учета. Кроме того ни кто не пустит контент-менеджеров в систему управления. В лучшем случае в админку сайта ИМ.
silicoid: яне вижу что сложного в стандартном протоколе обмена (кроме рукожопой организации самого xml), которым пользуются все складские системы России (да и вообще всего постсоветского пространства, быть может кроме прибалтики) например Мойсклад, класс365, да и собсно 1с торговля и склад.
XML это метаязык. Проблема не в нем, а в том, что на нем строят. Если это CommerceML, то организация XML кажется рукожопой, а если это HTML, то все нормально. Да и CommerceML не так широко используется на самом деле, как вы это представляете.
А СЕО, это что? Давайте договоримся о терминологии. А то каждый о чем-то своем рассуждает.
Предлагаю для обсуждения определения из статьи "Что такое SEO?". Хотя на данный момент материал немного устарел но для отправной точки думаю сойдет.
Секрет :)
Скажу так: треть всех посещений- с поиска.
Да, не густо. По статистике моих клиентов поиск должен давать в среднем 2/3 посетителей.
RoR - потому что можно быстро реализовать сложный проект с индивидуальной функциональностью. Преимущества с точки зрения заказчиков и конечных пользователей — это сокращение сроков и стоимости разработки, легкое внесение изменений и расширение функциональности. По сравнению с php, RoR разработчиков на рынке меньше, но найти их всегда можно.
Любой язык программирования есть язык. Его возможности обусловлены наличием библиотек. В PHP таких библиотек не меньше чем в RoR, просто вы их не знаете, отсюда и ваши заблуждения на счет сроков разработки и прочего. А дефицит исполнителей это неизбежно рост стоимости владения сайтом.
Приветствую. Ищу инфу следующего содержания, прошу ткнуть носом или направить в нужном направлении:
1. Основные особенности современного интернет-магазина (ИМ) в рунете.
2. Всякие технические детали (стоит ли, допустим, гнаться за скоростью загрузки сайта или полностью сосредоточиться на юзабилити и пр.; как должна выглядеть карточка товара, какими должны быть фотки и т.д.).
3. ИМ с точки зрения продвижения в поисковиках (интересуют максимально белые, долгосрочные способы).
4. ИМ в Директе/Adwords.
В общем, хочется вникнуть в эту тему, представить четкую картинку качественного, современного ИМ. Есть ли хорошие учебники/руководства/сайты по этой тематике? Многое зависит от ниши и прочих факторов, но пока интересует общая инфа.
Попробуйте начать отсюда http://smartceo.ru. Материал правда не полный и местами сыроват. Сейчас работаю над систематизацией накопленного материала. Надеюсь скоро выложить. Если интересует что-то более конкретное пишите.
Всем привет!
Есть ИМ, в нем- товары, категории.
Ассортимент- величина переменная. Какие-то товары вводятся в ассортимент, какие-то выводятся, снимаются с производства, появляются новые модели.
Т.е. двигать ключи- модели товаров, неактуально из-за временности этих ключей.
Двигать категории, можно, но есть ли смысл?
Категорий много, частотность очевидных ключей невелика. В итоге, приходится расширять СЯ, включать ключи не только с названиями бренда, а и более общие, по функционалу, брать ВЧ, СЧ.
Например, магазин Ентер или Связной. Они вообще пользуются СЕО? Оно им нужно?
Вы пользуетесь СЕО для магазина, где много каталожных товаров? Каталожные я имею ввиду товары типа "Телевизор Сони КТ530-4352 ЛСД 50 дюймов".
ПС: с позволения модераторов создам похожую тему в ветке СЕОшников, т.к. здесь в основоном, магазинщики, а там СЕОшники, и у них может быть другой взгляд на эту тему.
Если под СЕО понимается SEO, то это реклама. Вопрос - нужна ли реклама в торговле? Если денег - куры не клюют, то SEO можно заменить огромным рекламным бюджетом на Директы и АддВоррдсы и не напрягаться по поводу движения к топу выдачи.
Крупные магазины возможно SEO как средством привлечения посетителей и не используют. Мелкие вынуждены использовать рекламный бюджет только для первоначального привлечения, а потом двигаться вверх за счет SEO и других средств.
Да, и еще, большинство продавцов и сеошников, ошибочно полагают, что потенциальный покупатель ищет в сети именно товар, поэтому и двигать пытаются каждый товар в отдельности. Очевидно что в магазинах с большой номенклатурой это не реально.
e_v_medvedev, Большое спасибо за ответ! Используем модуль Ругенто, настраиваемые товары да, это отдельное веселье))) Но вроде получается у программиста, причем без изменения конфигурации 1С, разве что только местами приходится менять что-либо в ведении номенклатуры))) Но так как и 1С и сайт с нуля - нестрашно все это. Хотелось бы понять, почему именно неудобно делать полный обмен между УТ и CMS. Поэтому, собственно, и спросил...
Ну да, другой вариант прописывания связи группирующего и группируемых товаров это отразить связь через правильное формирование артикулов. А для синхронизации цен и остатков выгрузка всего объема данных в CommerceML не разумна. Обработка объемных файлов XML съедает много вычислительных ресурсов у хостинга (проще использовать CSV файл). Правда я возможностей модуля Ругенто не знаю. Может для первоначальной заливки он от части и подойдет, но все равно нужно будет проводить поисковую оптимизацию контента и делать это в 1С не рационально. Правда как известно "дьявол кроется в деталях". Может конкретно для вашего случая решение вполне приемлемое.
e_v_medvedev, То есть, Вы считаете, что проще будет фото и описания напрямую в CMS грузить (в нашем случае Magento)? Или дело не в том, что проще, а как правильнее))))
Мой опыт работы с клиентами, имеющими сайты на Мадженто и 1С подсказывает именно такой вариант. В 1С как правило ведется минимум данных, предназначенных для идентификации товара, а не для его демонстрации со всех сторон и в лучшем виде. В результате приходится сначала выгружать данные из 1С в какой то промежуточный формат, потом добавлять туда данные, необходимые для SEO (подготовленные другими средствами), и потом заливать в базу сайта. То есть проблема в том, что без промежуточной обработки данные из 1С в базу заливать не получается. А есть еще проблемы с импортом настраиваемых товаров. Тогда и 1С нужно будет допиливать. Так что универсального решения не получится.
Добрый день! А подскажите, в чем именно "неудобность" такого решения? Как раз сейчас организовываем именно это (полный обмен 1С УТ и CMS), может быть зря? :)
Тухлое занятие. Метаданных в 1С все равно не хватает. Да и картинок в торговом зале как правило нужно больше чем в системе учета. Кроме того ни кто не пустит контент-менеджеров в систему управления. В лучшем случае в админку сайта ИМ.
Что за бред вы несете? 😂
Главное не что, а куда. Луче если бы он нес его отсюда и куда подальше :-).
яне вижу что сложного в стандартном протоколе обмена (кроме рукожопой организации самого xml), которым пользуются все складские системы России (да и вообще всего постсоветского пространства, быть может кроме прибалтики)
например Мойсклад, класс365, да и собсно 1с торговля и склад.
XML это метаязык. Проблема не в нем, а в том, что на нем строят. Если это CommerceML, то организация XML кажется рукожопой, а если это HTML, то все нормально. Да и CommerceML не так широко используется на самом деле, как вы это представляете.