Вот именно, я бы посмотрел и другие алиасы. Может что-то там не чисто.
Скрывает элемент с id 'lk' если хост не supersite.ru. ПС не научились обрабатывать js, но вроде к этому все идет, так что я бы поосторожничал и внимательно изучил что оно делает. Ведь если ПС заметит как-то что ему скармливают не то что видет пользователь ...
Было :) Бывает, откроешь тему и забудешь ответить, потом вернешься напишешь ответ - смотришь а там уже все есть =)
Это скорее всего вирус, перенаправляющий ПС на другой чужой сайт.
У меня оно тоже возникло, поэтому я и дополнил ответ :)
Ну это не подробный алгоритм как в ГОСТе, а смысловой.
slice функция он должен знать. Если нет, гугл подскажет по нужному языку.
HraKK добавил 10.03.2009 в 18:59
Скорее для 2 чтоб не юзать slice а то преподы забракуют ( они консервативны, но если что slice и так делает удаление сдвигом)
то надо пройтись циклом с сдвигать элементы от 1 найденого до последнего .
Вот тут кстати есть алгоритм по 1 заданию только для максимального, несложно добавить еще одну проверку и для минимального, а также обьяснсятся как удалять сдвигом
http://window.edu.ru/window_catalog/pdf2txt?p_id=9079&p_page=4.
1) Проходим по масиву минимаксом( if x < min: x = min;if y > max: y = max; ) запоминая положения мини и макс и обнуляем.
2) Ищем итератором с начала первый отрицательный, запоминаем.
Ищем итераторм с конца первый отрицательный нашли - делаем slice.
Пиво не надо, а в репу дать можно, если поможет)
Мораль этой басни такова, очередной сайт сделаный идуссами. Понятно что с таким успехом кладутся сайты и с 1000 уников в день. Это не highload,а джамшут&рамшуд™. В таких случаях xdebug Вам в руки.
Еще раз добрый день, попытаюсь донести до масс, кому действительно интересны высокие нагрузки, немного разъяснений. Я не будут останавливаться на частностях, которые Вы уже должны знать, если Вы их не знаете или не можете узнать используя google, задумайтесь и лучше поручите эту работу кому-то другому (это я пытался донести в прошлом посте)
Во-первых, что такое highload (высоконагруженный) проект, это проект ну хотя бы от 1 млн. хитов в день, хотя это тоже субъективно - правильнее rps - request per second, то есть количество запросов в секунду, может быть проект с посещаемостью 100000 хитов быть более нагруженный из-за пиковых моментов, чем сайт с 1000000 хитов.
Тезис №1
Преждевременная оптимизация корень всех бед.
Если Вы никогда не делали аналогичный highload проект, Вы НИКОГДА не скажите где у Вас будет узкое место, а посему я ( и такое классики как Фаулер, например ) советую Вам не оптимизировать заранее. Это не значит, что можно писать криво, наоборот делайте все правильно, красиво, гибко. Использование ООП и Design Patterns (шаблонны проектирования), только поощряются, а не как многие заблуждаюсь, советуют наоборот. Сейчас мы рассмотрим почему.
Раньше, дела обстояли так, что не было OP cache программ (те кто берут php код и сохраняют его результат интерпретации в кэше), что приводило к тому что интерпретация большого кода (а ООП код всегда несет в себе излишество) существенно замедляла отдачу. Теперь же есть много таких программ, я лично считаю лучшей бесплатную Xcache (которую, кстати, начинают ставить даже на простых хостингах).
Дальше, вспоминая 1 тезис, мы не знаем где будет узкое место, а когда сделали проект и увидели под реальной загрузкой что в таком-то месте у нас тормозит ( для этого можно например погонять в Xdebug) то мы всегда может сделать хак который ускорит это место убрав оттуда ООП или другой код внедрив или дополнительный кэш этого места. Всегда можно от высокого спустится к низшему. А, ухудшая изначально свой код, Вы делаете непоправимое - скоро крупный проект выйдет у Вас из под контроля и Вам придется переписывать заново его или мучаться с поддержкой этого жиле.
Тезис №2
Умный в гору не пойдет, умный гору обойдет.
Любой highload это масштабирование, масштабирование бывает 2 видов:
- вертикальное, когда увеличивают мощность сервера.
- горизонтальная, когда нагрузку разносят на несколько серверов.
Так вот, хайлоад предполагает легкую горизонтальную расширяемость проекта, заложите это в основе своей архитектуры, и все у Вас будет хорошо.
Масштабировать лучше начать (повторюсь, надо смотреть на проект, всё тут очень и очень уникально) с разнесения на 3 сервера:
1) Статические файлы. Поставить веб сервер Nginx, он замечательно справляется с отдачей статических файлов. Сюда относиться js, css, картинки любой контент и если вы используете html кэш, который потом собираете SSI директивой.
2) Логика. Я бы посоветовал тут поставить lighttpd.
3) Базы данных. Ставим MySQL и memcache на отдельный сервер, желательно чтоб на нем было побольше и побыстрее оперативной памяти.
Когда и если вам перестанет хватать этих серверов, Вы спокойно можете поставить еще один и с помощью аппаратного балансировщика нагрузки или программного (например nginx) и увеличить в двое ресурсы. Единственная сложность MySQL сервер, так как там надо поддерживать актуальную информацию, а она часто изменяется, то можете либо при вставке или изменении делать их сразу на всех таблицах или сделать master – slave и синхронизировать контент с мастер на слейв с какой-то периодичностью по cron. Делать кластер не советую на MySQL заметно падает производительность, тут уже стоит посмотреть на другие СУБД.
Тезис №3
Кэшируй все что можно.
Тут думаю все понятно, просто храним в КЭШе все что можно, чтоб не нагружать сервера, в основном это касается запросов в базу данных, как мы видим из предыдущего тезиса, это самое узкое место и сложных расчетов, например статистических. Для КЭШа советую использовать memcache.
Заключение.
Соблюдая эти 3 простых тезиса, Вы может и не сделаете google, но выдержите любую адекватную нагрузку в разумных пределах, а если ее Вам не будет хватать, то тут уже думаю, Вас будет меньше всего заботить, как это реализовать, ведь вы сможете себе позволить курировать этот проект с Гавайских островов!
Надеюсь это кому-то поможет, с уважением Александр.
Можно, но предварительно меня надо выцепить в аське =)
