Библиотека Интернет Индустрии I2R.ru

"Когда Вы делали систему, наверное, могли бы провести исследования на предмет спроса пользователей на те или иные сервисы и ввести их. Странно, что Вы придумываете XML-языки для магазинов в то время, как для посетителей Ваша система месяцами остается неуклюжей. Если бы мы ловили глюки на этапе, когда разьяренный пользователь может только написать жалобу в форум, наша система была бы на таком же уровне, как и Торг.ру... Если Вам нужно найти например компьютер Pentium II дешевле 1000 долларов, в Shopping.ru я их найду в 2 приема, а на Торге мне нужно просмотреть все страницы, чтобы получить информацию, а о сравнении цен речь вообще не идет. Вы для кого делали систему, для посетителей или для инвесторов?

Shopping.ru

Уважаемый SR! XML-язык был создан именно для того, чтобы сделать поиск товаров более удобным и простым. Сейчас происходит отладка системы поиска. В скором времени на Торге Вы сможете воспользоваться поиском, по возможностям не имеющим аналогов в Рунете! –

Administrator user support Torg.Ru"

Из дискуссии на talk.ru

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

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

У магазина должны быть по крайней мере как минимум два интерфейса конечного пользователя: витрина для покупателей и странички администрации магазина (интерфейс back-office).

Если отбросить из рассмотрения голосования, отзывы, рейтинги и т.п., то витрина – это поисковый аппарат покупателя. В ней могут быть реализованы различные принципы навигации от простого прохода по каталогам до ассоциативных стратегий поиска. Но все-таки, это только поиск. Конечно, есть еще и оформление покупки, и связь с платежной системой, но это отдельная тема.

Задачи администратора гораздо более сложны и многочисленны. Это и пополнение каталогов, и учет прохождения товаров, комплектование, бухгалтерия и много чего еще. Одним словом, без автоматизации этого процесса никак не обойтись. Любой разработчик автоматизированных систем управления Вам скажет, что развитие и поддержка подобного сорта систем есть задача очень сложная. Из общего объема трудозатрат на разработку магазина 80% придется на back-office, и только 20% - на интерфейс покупателя.

Задача усложняется еще и потому, что интернет-проект всегда запускается недоделанным. Он напоминает автомобиль, который уже выкатили из гаража, и он катится по дороге. Но у него даже четырех колес нет, хорошо, если три приделали. Но пассажиров уже зазывают, а некоторые из них (пассажиров) даже садятся в удобные или не очень кресла.

На этой стадии очень важно правильно распределить ресурсы. Что сначала делать: удобные сидения и катить машину вручную, или все-таки поставить на нее мотор? В большинстве случаев предпочтение отдается сидениям.

Если проект не раскручен, то поток посетителей мал, а число покупок мизерно. Их можно просто обработать вручную. Такой магазин может обойтись только статическими HTML-страницами для витрины и электронной почтой для получения заявок. Но даже в этом случае при большой номенклатуре товаров странички их (товаров) описаний вручную никто не набивает. Обязательно будет написан генератор страниц, который из офисной базы данных, например, Exel, будет по шаблону производить на свет HTML-страницы сайта.

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

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

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

Другой пример - 24x7. Должен был бы сдан заказчику еще весной. Но думаю, что функционально не завершен до сих пор, а то, что не оттестирован на устойчивость к возможным нагрузкам, я почти уверен. Кстати, там тоже применяются не очень пока распространенные решения, например JSP. Кто их будет поддерживать в NetBridge – это большой вопрос. Да и на какие реализации этих самых JSP следует закладываться: Tomcat, Resin или что-либо еще. На каких платформах? Все это не ясно и туманно.

Вообще говоря, учеба на заказчике – это типичная практика наших разработчиков. Отчасти это предопределено неразвитостью отрасли, а отчасти и персонажами, которые занимаются этим родом деятельности. Не будет слишком большим преувеличением утверждение о том, что ни один наш разработчик, за исключением разве что Яндекс, РБК и, может быть, Рамблер, не имеет исследовательского отдела. А это значит, что все новые технологии, а без них наши программисты жить не могут, будут тестироваться и уже реально тестируются на заказчике.

Но вернемся к распределению ресурсов при реализации проекта. Надеюсь, что уже понятно движение нашего проекта от мотоциклетной инвалидной коляски к междугороднему комфортабельному автобусу. Это движение должно происходить по графику. И коляска и автобус должны быть запланированы. При этом следует учесть, что автобус может никогда не получиться. Т.е. проект может быть остановлен в любой момент. И в этот момент должно быть конечное работающее решение, а не полуфабрикат. Каждое из составляющих проект решений должно быть документировано, независимо от других, и реализовано таким образом, чтобы его можно было использовать в других проектах. В прочем это все избитые истины, и я просто напомнил о них, т.к., судя по дискуссиям на отдельных сайтах :) эти истины стали забывать.

Да, и еще. Все, что здесь написано справедливо не для всех случаев жизни. Если вы не специализируетесь на разработке ПО, то, может быть, Вам и нет смысла думать о «правильном» планировании, т.к. оно увеличивает расходы за счет некоторой избыточности решений. Может быть вообще лучше решение у кого-нибудь заказать и потом драть с исполнителя три шкуры за свои кровные денежки. Вообщем, все неоднозначно.

И напоследок желаю всем удачи в ваших начинаниях :)!