Да конечно всё имеет право на жизнь. Просто это совсем разные алгоритмы для разных случаев. "PR гугла" - это алгоритм во-первых сетевой, а во-вторых накопительный, то есть когда вес передается не просто от сайта к сайту, а еще и дальше с затуханием. И этот вес у каждого участника свой и итоговый вес передаваемый рассчитывается по сложному многоходовому алгоритму. Выше в обсуждении уже предлагалось назначать разный вес каждому голосу за картинку в зависимости от возраста и чего-то еще. Greenwood сказал что это неоправданное усложнение. Поэтому, я предложил намного более простую по принципу работы схему, где вклад каждого голоса считается примитивно. Подойдет ему или нет - он сам решит (5 WMZ мне однако не нужны :), чисто любопытная задача).
Насчет догнать того кто выше в рейтинге как раз все получится. Ну, предположим всего две фотки и два места. Если фотка на первом месте - голос добавляет 1 балл, а если на втором - 2. В начале имеем так (в скобках - баллы):
Ф1[0] и Ф2[0] стартуют с нулями, оба считаем на втором (самом нижнем) месте
Ф1[2], Ф2[0] (первый клик по первой, +2 балла, в итоге Ф1 на первом месте, Ф2 на втором)
Ф1[3], Ф2[0] (второй клик по первой, +1 балл)
Ф1[4], Ф2[0] (третий клик по первой, +1 балл)
Ф1[5], Ф2[0] (четвертый клик по первой, +1 балл)
Итого, после 4х кликов Ф1 вырвалась вперед, у неё 5 баллов! Тут пришли фанаты "сисек" и начали кликать на вторую картинку.
Ф1[5], Ф2[2] (первый клик по второй, +2 балла)
Ф1[5], Ф2[4] (второй клик по второй, +2 балла)
Ф2[6], Ф1[5] (третий клик по второй, +2 балла, фотки меняются местами)
Итого, после 3х кликов по Ф2 она оказалась выше в рейтинге, чем Ф1 у которой 4 клика!
Далее все будет наоборот - клики по Ф2, которая залезла наверх, будут давать ей уже только по баллу, а Ф1 получать по 2. Таким образом, при примерно одинаковом числе кликов по фоткам они будут регулярно меняться местами, чего при традиционном рейтинге будет происходить гораздо реже (не силен в комбинаторике, но вроде бы раза в 2 примерно). Плюс, такое соревнование будет между любыми двумя соседями, поэтому и совокупное количество перемешиваний во всем рейтинге должно быть гораздо больше, чем при простом линейном начислении. И это даст по сути некоторую ротацию баннеров и затруднит (хотя и не сделает невозможным) убегание фоток на самый верх с большим отрывом.
Сразу говорю, что с вашим алгоритмом не сравнивал, поскольку "с ходу" его не понял. Может быть он более эффективен, но, соответственно, и немного более сложен в реализации.
Ma-)cTpo, нет, не кажется. В условиях задачи нет ничего о логике выбора и о критериях "достойности". "Сиськи или жопа" будут в топе независимо от алгоритма расчета рейтинга если посетители это любят и кликают. Более того, мне кажется вы неверно поняли предложенный алгоритм. В моем случае будет выше вероятность смены близко расположенных картинок местами, поскольку образно говоря дистанция для преодоления разницы в голосах картинкой "снизу" будет для нее меньше, чем для убегания "верхней" еще выше. Но в любом случае выше будет та картинка, за которую голосовали больше, а уж за что голосуют - это дело посетителей.
Я, возможно, не в теме, поэтому лично мне совершенно все равно какая фотка будет на первом месте. Здраво рассуждая, скорее всего не все равно будет а) посетителям (фанатам) и б) владельцу баннера, который ассоциирован с фото. Посетители которым что-то не понравятся выведут быстро любую другую фото в топ по принципу "а вот эта, на мой взгляд лучше", а владельцы баннеров пусть соревнуются, у них появится такая возможность (я так понимаю как раз сейчас то её и нет).
И вообще, задачи часто решаются по аналогии. Если мы имеем некоторое неравенство, когда рейтинг растет слишком быстро и его нужно ограничить - легко найти аналогию в RPG играх, где требуется дать возможность быстро вырасти новичку, но требуется больше сил на взросление и заработок experience на более высоких уровнях. Для задач когда нужно выравнять всех по одной линеечке годятся алгоритмы выделения тайм-слайсов для процессов операционной системы (например мультизадачность Юниксов). Для случая когда вес голосов разный и нужно считать общую "карму" подойдут такие схемы расчета, как расчет PR в Гугле, например. И так далее. Нашел аналогию - попробуй применить, а потом уже подкручивай коэффициенты под себя, поскольку почти все задачи "в принципе" давно уже решены.
Нормировать рейтинг по логарифмической или степенной шкале (с дробным коэффициентом). Например, Чтобы голос первому месту давал 1 балл, второму 2, третьему 4, четвертому 7, пятому 13, шестому 24, седьмому 44, восьмому 81, девятому 149... В итоге пока фото внизу - оно быстро поднимается вверх, но как только оно в топе - держаться ему на плаву становится сложнее.
Типа experience в RPG - чем мощнее персонаж, тем меньше опыта ему дает каждый новый труп.
mapbuilder создает растровую карту стянутую с гугла/яндекса + файл привязки в формате OZI (map файл), соответстветственно если ваш карманный GPS софт умеет читать такую карту - вам повезло. Вероятно можно также попробовать этот формат конвертировать при необходимости. Я пользовал такие самопальные карты на ноуте при поездке в Австрию/Германию, никаких проблем, отличная точность. Только нужно подобрать увеличение для своих целей (растр жрет память при загрузке), поэтому лучше опытным путем погонять карту Москвы во дворе перед поездкой.
какая разница - гетом или постом? и так и так все спамится.
есть куча достаточно эффективных методов защиты форм от ботов без всякой капчи.
Нет "отселя" никаких выводов. Заражаются сайты не всегда автоматом, зависит от того какая система украла пароли и как работает скрипт-"заражатель". Иногда бот-заражатель получив от трояна пароли к FTP сканирует сайт полностью и ищет файлы с определенными именами (например, index.html и default.html) после чего ставит в расписание "ходить каждые 6 часов и дописывать в конец файлов яваскрипт (iframe, include etc) код". Иногда поиск ведется только в корне сайта. Иногда заражение делается вручную, а бот только повторяет его по сценарию.
Поэтому если у кого то притырили десяток FTP логинов а заражены оказались половина - это еще ни о чем не говорит. Может бот еще не дошел до остальных сайтов, может на этих сайтах структура директорий другая или есть еще какие-либо причины.
В любом случае при любом подобном инциденте нужно:
- прибить трояна. быть уверенным что 100% троян изведен.
- полностью менять все пароли. На email, FTP, ICQ, WM, YM и все все все остальное что хранится как в реестре, так и в save параметрах различных программ.
- сменить все FTP аккаунты на хостинге.
В описанной ситуации вряд ли, но на практике это возможно. Трафик легко может быть прослушан как соседом по лестничной клетке (если доступ к инету через WiFi) так и по пути следования к целевому серверу (у любого из провайдеров) если вы или ваш используемый софт не используют шифрование и другие приемы защиты информации.
Посему если сервер свой очень рекомендуется работать через SSH каналы даже по FTP, хотя это бывает не очень удобно и затратно по трафику, а также ограничивать соединение по IP адресам. Хотя это тоже доступно не всегда и не всем, но кому доступен свой сервер и выделенный IP на клиентском месте - лениться делать дополнительные настройки не должны.
Рубить 5000р платеж на десять 500 рублевых в большинстве интернет-магазинов - невообразимый гемор. Поэтому если они это узаконят - интернет торговля по WM или ЯД в России свернется. Мало кто захочет оставлять на сайте паспортные данные чтобы купить книжку. Подозреваю что курьеров потом заставят таскать с собой кассовые аппараты или еще что-нибудь придумают.
А не в двигателе дело. У Сапе модуль лезет на их диспенсер за ссылками как только проходит час с момента последнего обновления файла со ссылками. И естественно если этого диспенсера нет - как сейчас - любая страница где стоит код Сапе будет генерироваться на 10 секунд (таймаут по умолчанию, по крайней мере в Перловом модуле такой зашит) дольше. А по факту чуть больше, около 15-18, поскольку накладные операции еще. А если посещаемость высокая... Сайту на любом движке поплохеет.
Смотря что именно вы под этим подразумеваете. Если представить таблицу с перечнем ссылок с каждой страницы или указанием что с чем связано - не совсем понятно как вы этим будете пользоваться, для запутанных структур это будет совершенно бесполезная штука.
Есть вот такая вещь (см. аттач). Здесь показаны реальные переходы посетителей между страницами сайта (отображена только часть сайта интересная для конкретного анализа). Это структура сайта глазами посетителей, если хотите.
Уточните конкретно на какой площадке будете ставить машину. Если на профсоюзной (прямо в здании самого РБК) то там до ремонта было все нормально и с аптаймом и со временем отклика. Потом сделали ремонт, поставили модные красивые стойки с контролем температуры, но на момент моего отъезда оттуда еще не везде. На момент ремонта там были проблемки пару раз. С саппортом беда - если что-то понадобится - не дозвонишься.
А вообще, насколько я знаю вроде бы у них наклевывалась вторая отдельная площадка, как раз под брэнд hc.ru (типа разделились - rbchosting в одну сторону, hc.ru - в другую). Там про колокейшн ничего сказать не могу, не был, не видел.
Еще нужно помнить что они (РБК) в свое время купили хостинг компанию highway.ru, не знаю, но потенциально и теоретически они могут и туда запихнуть сервер, наверное. Если они конечно не слили все площадки в одно место и не убили хайвэй как класс. С хайвэем сталкивался один раз, там суппорт был жив даже в 3 ночи по телефону, что бывает в нашей стране крайне редко.
