bizwood.ru

[ermouth]

Сегодня в правительстве представлял местным предпринимателям и чиновникам бета-версию нашего нового проекта – над которым я без продыху работал последние два месяца по 8-10 часов в день.

Мы запустили в тестовом режиме (ограниченная функциональность без возможности регистрации пока) торговую площадку леспрома Северо-запада – bizwood.ru

Фоточки вот, пока превьюшками:

 

Я невероятно устал за эти два месяца – мы ведь ещё параллельно два журнала подготовили – но очень доволен ) У меня впервые в жизни было такой силы вдохновение.

Подробности немного позже.

Comments

[morfizm.livejournal.com]

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

[ermouth.livejournal.com]

спасибо.

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

ну и плюс в ближайшем будущем это всё будет индексироваться -- хоть это и аякс. всё затачивалось под вот это http://code.google.com/intl/ru-RU/web/ajaxcrawling/docs/specification.html

[morfizm.livejournal.com]

O, cool! Я как раз писал тебе коммент про индексирование, но, я смотрю, ты просто ещё не сделал его. Интересный спек, почитаю. Жду поста с internals :)

[morfizm.livejournal.com]

По поводу "кэшироваться локально" - идея для небольших сайтов (в которых товаров, в принципе, не очень много, скажем, мегабайт в zip'е): пользователь открывает страницу и javascript параллельным потоком начинает по кусочкам скачивать zip. Когда всё скачалось, склеивает, распаковывает и переключается полностью на локальный кэш. С апдейтами будет гемор, но если апдейты редкие, то большинство времени всё будет "летать", кроме первых нескольких секунд - и, возможно первого запроса, если пользователь успеет его сделать :)

[ermouth.livejournal.com]

не, не так совсем.

у меня поиск идёт в два запроса, а не в один.

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

потом клиент разбирает ответ и запрашивает у сервера уже развёрнутое описание айтемов. причём только тех, которые в текущей сессии ещё не запрашивались -- уже полученные берутся из кэша.

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

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

[morfizm.livejournal.com]

Мы по-моему, про разные вещи говорим. Моя мысль была делать массированный read-ahead - т.е. что если информации не так много, то клиент может (в бэкграунде, не зависимо от действий пользователя) закачать всё в кэш. Т.е. в твоём дизайне это будет запросить полный список хэштэгов, а потом выкачать всё, что ещё не закэшировано. Можно оптимизировать, использовав сжатие. Просто для небольших магазинчиков заархивированной инфы с гулькин нос (никак не больше мегабайта-двух), а benefit огромен: после того, как всё скачалось, вообще никакого взаимодействия с сервером больше не нужно. Кроме, разве что, очень редких обновлений.

Насчёт двух проходного поиска - надо подумать.

У идеи есть один мега-недостаток - это минимум два round-trip'а на каждый "живой" запрос (когда кэш ещё пуст). Два round-trip'а это два round-trip'а. Конкуренты, делающие один round-trip побьют. Ну и для клиентов с медленным соединением это может hurt their experience.

Во всём остальном идея весьма соблазнительная. Надо ещё подумать. Например, очевидно, что нагрузка на сервер будет меньше. Суммарного трафика будет меньше. Хэши, если их очень компактно пересылать, могут уместиться в один TCP пакет, что есть very, very good.

Кстати, очевидно, ты можешь оптимизировать запросы по категориям, чтобы укладываться в один round-trip: если ты заведёшь id категорий ("категория" это прямой линк на список, с главной страницы), и у каждого "документа" будешь держать список id-шников, к которым он принадлежит, то в этом случае ты можешь, когда юзер кликает на категорию, вместе со строкой запроса пересылать серверу список хэшей, которые у тебя уже есть в кэше на эту категорию. Сервер пусть вернёт сразу все детали, но только для тех items, которых у тебя ещё нет.

[ermouth.livejournal.com]

а, ну так я уже так делал (про выкачивание всей базы) -- zoo29.ru

хэши пересылаются очень компактно -- примерно 30+9*n байт

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

автокомплит будет (это к следующему комменту)

[morfizm.livejournal.com]

zoo29.ru - офигенно! Здорово! *Очень быстро* Первые впечатления, наверное, получше, чем от bizwood.ru

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

Я не уверен, что ты понял последнее предложение. Отсылать на сервер не надо 10 тысяч. Отсылать надо только те хеши, которые входят в категорию. Если max по категории - пару сотен, то только пару сотен надо отправить. Это чтобы опитмизировать клики, которые не поиск по введённым словам, а клики на название категорий в меню.

[ermouth.livejournal.com]

про зоо29 -- да, там всё быстро, и как раз магазин без регистрации -- но оно не индексируется. ну правда и цели такой не стояло.

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

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

[morfizm.livejournal.com]

Про задержку - вау! Вот это да! :)
А как ты определил факт феномена? (Жаловались, что поиск не работает?)

[ermouth.livejournal.com]

я показываю человеку магазин, он наколачивает в поиск что-то и потом несколько раз кликает по кнопочке с лупой -- не заметив, что всё уже нашлось. показываю другому -- та-же песня.

поэтому я сделал моргание.

[morfizm.livejournal.com]

Кстати, ещё одна идея: первый запрос (на хэши) можно делать ещё до того, как пользователь нажал "enter". Просто спрашивать раз в секунду-две, пока он вводит поисковые слова. Трафик небольшой, а у тебя уже хэши будут наготове. Ну и можно хранить на будущее таблицу хэшей для всех префиксов. Скажем, я ввожу слово "доска резная", и пока я его набираю, ты делаешь запросы на "д", "до", ... "доска", "доска р", ... "доска резная". Конечно, хэши на "д" и "до" можно будет выкинуть, но вот хэши на "доска" могут пригодиться. Например, резных досок не нашлось, и я уберу слово "резная", чтобы вообще понять, есть ли там доски. Останется просто "доска". А для неё хэши уже скачены.

[morfizm.livejournal.com]

Почитал спецификацию, хорошо сделали, одобряю :)