Мифы и легенды интернен продаж, оптимизации и т.д.

Слава Шевцов, +1. Я, пожалуй, дополню.

Если мы говорим об уникальном программном продукте (не о коробке), то стоимость и сроки его доработки сторонним разработчиком будут в разы выше изза необходимости полного реверс-инжиниринга. Да и гарантий никаких.... Так что конкуренции можно не бояться.

Мишган добавил 17.03.2008 в 15:12

На самом деле все не так страшно. Если система действительно сложная то проще написать с нуля. А если простая то и без исходников напишут. Да и зазенденные скрипты вроде можно дисассемблировать

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

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

Потом Вам его открывают, программист залазит в исходники, долго там шибуршит .. вылазит ... и говорит,

- да идити вы в баню, там черт ногу сломит :)

---

Уж очень быстро устаревают системы ..

Когда и с кем такое было? С какими системами? Назовите, я их вычеркну из своего списка CMS.

Самая известная - Микрософт. В оффисе от версии к версии регулярно наблюдается несовместимость :) Попросите, к примеру, доработать MS DOS 3.15 :) Если поближе - то тот же, любимый всеми 1С, а конкретно версии 7 и 8 :)

А как Вы в таком случае реализуете задачу резервирования товара в реальном времени через Web интерфейс? А элемент для нормального магазина, торгующего с реального склада очень нужный. Правда с 1С я бы очень не рекомендовал обращаться напрямую к таблицам. Очень стремное действо. Пишите Web сервис с API или используйте то, что есть в 8. И не забывайте при изменении конфигурации 1С вносить необходимые изменения в API :)

Я бы сказал, что современный интернет магазин должен иметь API для сопряжения с системой управления предприятием. Правда точка ответственности СУП и магазина для каждого конкретнго предприятия своя, поэтому интеграция - это всегда ручная работа.

Во многом не согласен с ТС. Просто пример из моей жизни.

Первый интернет-магазин мы с друзьями открыли как раз так:

"Вась, че б замутить?"

"А баблос есть?"

"Да вот с последней темы кое-что осталось, в принципе, можно вложить куда-нить. Поголодаю, если дело стоящее".

..... перечисление тем, куда можно вложить деньги.

"А давайте лучше интернет-магазин откроем!"

"Блин, давай! А че для этого надо-то?"

"Надо, короче найти фирму, которая нам сделает сайт, но он должен быть с корзиной! Так что тут важно на жулье не напороться, которое без корзины делает."

Через три месяца у нас был интернет-магазин ,еще через три месяца он стал приновить доход. Сейчас этот магазин обслуживает пять человек с зарплатами от 30к руб. и плюс имеет свою копейку фирма-оптимизатор.

Так что все вполне реально.

И это 95% случаев. Причем половина из них быстро умирает причем не из-за софта а из-за организационных проблем. :) А вот те, кто выживают, создают собственные бизнес-схемы и пытаются уложить их в готовые системы управления магазинами и интегрировать с системами управления бизнесом. И не всегда это 1С.

Мы в 2002 году делали интернет магазин для дилеров, т.е. отдельный домен 3 уровня, сразу закрытый логином и паролем. Причем изначально задача ставилась так, что все операции должны проходить в реальном времени. На стороне клиента была самописная система управления бизнесом. Договорились с разработчиками СУБ об интерфейсе и границах ответственности и сделали практически полноценный Web интерфейс к СУБ. Web часть обеспечивает защиту, т.е. отвечает за авторизацию и представление данных и практически ничего не хранит, кроме сформированных документов для клиентов. За эти годы и одна и вторая части были очень сильно модернизиованы за счет сервисных функций, добавлены уровни защиты и.т.д. но все время соблюдался принцип - мы в своей работе не мешаем разработчикам СУБ, т.к. делаем все в рамках согласованного интерфейса, а они также делают в СУБ все что угодно, не затрагивая нас. Лишь один раз пришлось обновить протокол интерфейса взаимодействия.

Сейчас делаем вторую версию системы, которая будет взаимодействовать по SOA, но в ней все равно, как резервный вариант остался старый интерфейс :)

Я это к тому, что перед серьезными интернет магазинами могут ставиться абсолютно разные задачи и пути их решения должны быть индивидуальны.

StarPlayer, А Вы не обращали внимания на такие ЦМСки как WebSphere и SharePoint?

В них, то что Вам надо уже есть, или достаточно просто прикручивается. Масштабируются практически до бесконечности, как в сторону кластерности, так и в сторону серьезных серверов типа SuperDome и AS400. По крайней мере первая - точно. Если Вам нехватает мощи кластера из 4 4-х головых интеловских серверов купите AS 400 c 64 рискованными головушками и все полетит.... Причем часть этих головушек может быть Java процессорами :)

да уж, вебсфера это притча во языцах для жаба разработчиков :-(

В рунете много магазинов, которым _необходим_ оракл и они его легально используют?

Много из них на битриксе (и любых других коробочных решениях)?

Дык оракл есть и бесплатный ... вот только его поддержка денюжку стоит, но это уже другая история .