Да, действительно в новой версии эта проблема устранена.
Жаль потраченного времени на исследование ошибки :(
Столкнулся с проблемой, когда некоторые купленные ссылки переходили в статус "Ошибка" с сообщением "Не найдена на странице". И их действительно не было на странице.
Казалось бы, что такое в принципе невозможно, поскольку код системы у меня проставлен в шаблоне в одном месте и, соответственно, либо на всех страницах должны выводится ссылки, либо на всех - нет.
Стал разбираться в чем проблема.
В файле unilinks.db имеется строка со страницей и ссылкой, которая в статусе "Ошибка". Значит проблема в системном скрипте вывода.
Изучил алгоритм работы ф-ции GetLinks и оказалось, что проблема именно в нём.
Дело в том, что эта ф-ция получает размер файла unilinks.db в байтах и ищет подходящую строку по хэш-коду адреса страницы путем половинного деления этих байтов. Строки в unilinks.db отсортированы по хэш-коду в порядке его убывания, соответственно, сравнивая хэш-коды, алгоритм двигается в нужном направлении.
Однако, иногда возникает следующая ситуация.
Допустим, алгоритм дошел до такого уровня, когда остаются не исследованными 3 строки.
1 и 5 - это строки начала и конца суженного диапазона, а 3, 4 и 5 - необработанные строки.
Алгоритм берет начальный байт 1-й строки и начальный байт 5-й строки, получая среднее значение. Оно попадает на строку 3. Однако она не совпадает с искомой, а её хэш-код меньше искомого. Теперь у нас остается не исследованной только строка 4 (в реальности она и есть та строка, которую мы ищем).
Алгоритм берет начальный байт 3-й строчки и начальный байт 5-й строки, получая среднее значение. И вот тут самое интересное. Волей судьбы получилась так, что длина строки 3 в байтах больше, чем длина 4-й строки. В результате половинного деления алгоритм вновь попадает на строку 3, смотрит, что её уже обрабатывали и завершает цикл, так и не найдя нужную строку.
Я доработал у себя ф-цию GetLinks. Т.е. если мы выходим из цикла и ничего не нашли, то на всякий случай проверим следующую строку за текущей (если рассматривать пример, то принудительно перепрыгиваем на строку 4 и проверяем её). В результате ссылка появилась на странице, а в системе исчезло сообщение об ошибке!!!
Надеюсь, эта проблема будет устранена централизованно в следующей версии скрипта.
Да уж, Mail невероятный молодец.
Решил проверить качество поиска и с первой же попытки был ошарашен.
Ввожу в строку поиска слово "самый" и первая строка в подсказке просто убивает.
А что ещё посетителям этого портала надо :)
Отправил информацию в личку...
У меня добавленный в систему сайт имеет PR = 3. Т.е. это PR главной страницы. Сначала система его определила правильно.
Сегодня я удалил главную страницу, т.к. не хочу продавать на ней ссылки. Теперь система показывает, что у сайта PR = 2.
Т.о., похоже, выводится просто максимальный PR добавленных в систему страниц.
Это ведь неправильно. Если речь идет о параметрах сайта, то обычно PR-ом сайта считается PR главной страницы.
У меня сначала тоже неправильно внешние ссылки посчитались, но потом пересчитались верно.
За неделю работы в бирже купили только 6 ссылок. Вернее их было 11, но остальные я удалил.
Цена выкупа пока неприлично низкая (судя по дневному заработку с этих 6 ссылок).
Через день автоматически добавляются новые страницы - примерно по 1к за раз.
Согласен!
Но вы видели, как люди ломятся в магазины в США в "черную пятницу"? Всё-таки скидка далеко не последнюю роль играет.
Я думаю, что просто скидочные сервисы подходят не любому виду бизнеса.
Полагаю, что клиники вряд ли могут тут поиметь выгоду, поскольку тут действительно важны отзывы, потому как человек рискует своим здоровьем. А рестораны, интернет-магазины различных подарков и т.п. могут реально найти себе массу постоянных клиентов.
Мне кажется, вы не совсем правы.
Люди обычно пользуются услугами в том месте, где они уже получали услуги и были ими довольны.
Чтобы попробовать воспользоваться услугами другой фирмы, человеку нужен стимул.
И скидка для этого очень подходит.
Люди всякие бывают, и, конечно, часть людей, которые придут к вам по купону, больше не вернутся, не зависимо от качества услуг.
Но некий процент, если останется доволен качеством ваших услуг, обязательно вернется, т.к. они уже знают о том, насколько хороши ваши услуги. А потом ещё и порекомендуют друзьям и т.д.
Допустим, я куплю купон в некий ресторан с приличной скидкой. Если мне там понравится, то я скорее всего иногда буду приходить туда снова, в том числе и уже без купона. А так, я бы мог туда никогда и не прийти, потому что меня во всём устраивал ресторан, в который я ходил раньше.
kolchakA, спасибо за ответ!
Тогда остается вопрос с архивными страницами - делать их доступными всегда или удалять через некоторое время.
У меня не будет разделения на каналы - все каналы в одной программе. Просто это будет не полная программа, а выборка передач некоторой тематики по всем каналам. Смысла разделять по каналам нет, так как за день передач нужно тематики суммарно по всем каналам 10-15 в лучшем случае бывает.
Ну если делать страницы с фиксированным адресами на 7 дней (day_1.html, day_2.html, ...), то у них каждый день будет новый заголовок, типа "программа на 21 ноября 2011, понедельник". На следующий день на этой же странице будет уже заголовок "программа на 22 ноября 2011, вторник". Я думаю, что это не очень хорошо.
Если страницы будут с адресом в url, то их со временем будет много. Если ставить редирект на главную через месяц после истечения даты, то накопится много редиректов со временем. Если оставлять все архивные страницы, то они, если будут оставаться в индексе, могут попадать в выдачу вместо более актуальных и быть неинтересными посетителям с этой выдачи.
Пока я начал склоняться к тому, чтобы добавить всё-таки дату в url и через месяц после истечения даты ставить редирект на текущий день программы. Если уж Яндекс этим балуется, то, наверное, и мне так стоит поступить...
Приобрел у ТС методики. Материалов и средств реализации действительно много, а также неплохое детальное описание. Теперь осталось дело за малым - применить это всё для своих сайтов :)
