Вы так жжете, что даже лениво комментировать:) Если бы то, что Вы предлагаете было нужно больше чем оно сложно, то оно давно было бы сделано. Да и любители компиляции должны бы давно посмотреть на asp.net и иже с ними, смысл изобретать что-то на php?
Но вот ответы Вам показались нам достаточно интересными для коммента.
уточним на всякий случай. процесс "компиляции в байт-код" они позволяют опускать, "нормальную" компиляцию они все равно не делают.
Зачастую не проще. Зачастую проще наваять php-кодерами проект, а потом отдать переписывать узкие места Си-шникам, чем изначально использовать Си (для этих узких мест или целого проекта).
Уже не раз замечали, как в других топиках Вы так же безаппеляционно жжете:) Вот честно, не понимаем Вас, Вы иногда говорите просто откровенно неверную информацию преподнося ее как факт, зачем? При чем настолько неверную, что даже возражать Вам лениво. Этот топик не самый яркий тому пример, но раз уж мы тут отвечаем, не удержались от вопроса.
Да, безусловно операции с БД могут занимать до 95% времени. Но в "среднестатическом" (отбрасываем уникальные и редкие) проекте 95% времени на БД это просто признак криворукости человека, писавшего запросы в БД.
Но аргумент у Вас частично верный. Время на php-код действительно занимает, ну положим не больше 50% в "среднестатических" проектах, поэтому даже ускорив php код в бесконечное количество раз, весь проект больше чем в 2 раза не ускорится.
Однако Вы упускаете здесь 2 момента: а) Время выполнения не связано напрямую с нагрузкой на сервер, при бОльшем времени выполнения скрипт может давать меньшую нагрузку (проверяли) б) Поедание памяти, пхп код имеет честь откушивать зачастую на порядок больше времени на те же операции при выполнении, да и даже простой инклудинг файла уже жрет память нехило.
:))) Про объявление зачет:) А где первый рассадник, мы пропустили?:)
Честно говоря от Вас слегка удивлены такое услышать. По программингу Вы всегда выражались предельно правильно. Вообще этот аргумент про "невозможность компиляции языков с нестрогой типизацией" мы встречаем уже не первый раз и каждый раз нам непонятно, откуда корни у этого пошли.
Что делать компилятору? Да то же что интерпретатору. Типов переменных ограниченное количество. Генерить разный код в зависимости от типа переменных. Неужели для кого-то сюрприз, что можно написать на компилируемых языках функцию, которая будет выполнять разный код в зависимости от типа передаваемой в нее переменной? Задача ведь та же самая, в зависимости от типа - выполнять действия по разному, и при этом он все еще останется компилятором. Да, компилятор будет сложнее, а что, разве компилятор должен быть прост как космический корабль на паровом двигателе?:)
Вот это серьезный аргумент, но можно просто запретить ее использовать в компилируемых проектах. К тому же мало кто ее использует полностью по назначению, согласитесь? Обычно ее используют, что бы выполнить достаточно статичный код, а не который меняется при каждом запуске приложения.
/Disclaimer/ (отмаза) Если бы здесь не было похвальбы sweb-у, то мы бы в топик не влезли, т.к. очень не любим говорить о конкретных ТМ свой негатив, без специальной на то причины (те кто нас знают, это знают:) ), но как-то зацепило.
sweb в поле нашего внимания всплывает уже давно и с постоянством достойным лучшего применения уже несколько лет.
Можем ошибаться, но тем кто хочет узнать про sweb, для начала наберите в гугле "sweb sorix", это имеет смысл.
В самом начале выбора хостинга себе, мы обратились в sweb. взяли там аккаунт заранее обговорив манибяк. Там не только прыгало время генерации страницы на порядок (от 0.5 до 5 секунд), но и вылезали всё время какие-то странные ошибки с php. Теперь, задним умом, мы понимаем и откуда эти ошибки и как их надо было убрать (тогда мы были молодыми и глупыми). Но дело не в том. Мы ничтоже сумнящеся написали в суппорт и спросили "что за на фиг", на что получили ответ в стиле "у Вас аккаунт с манибяком, мы решим Вам все проблемы, но только когда манибяк пройдет" (нет, мы конечно понимаем всё, но простите, а в чем логика тогда манибяка?). Впав в шок мы запросили манибяк, и точно не помним почему, но деньги мы не забрали по каким-то "бюрократическим" соображениям (то ли ехать куда-то надо было, то ли нотариально заверенный скан паспорта послать, то ли еще что-то).
После окончания периода манибяка мы попросили решить проблему, напомнив о том письме с обещанием. Суппорт посмотрел и после пары суток размышлений ответил, что мы поставили кривой движок, и что бы мы его не использовали. От себя заметим, что "проблема" решалась закомменчиванием одной строки или тупо отключением вывода ошибок.
В результате выбрали другого хостера (ТМ не назовем, сорри, не об этом тема).
Однако так получилось, что sweb очень активно пиарился на форуме, где мы тогда тусовались. В результате многие знакомые так или иначе с ним соприкасались, да и клиенты в общем-то по программированию почему-то нередко на sweb приходили. Поэтому опыт работы шел и шел:)
С одним из клиентских сайтов мы почти привыкли к ситуации, когда надо было пнуть суппорт, в асю или в почту, что бы он поднял упавший сайт. При этом суппорт вежливо благодарил что мы сообщили о еще неизвестной им проблеме, что само по себе конечно было приятно, но удивляло почему сам суппорт сам этого не знал.
По поводу нагрузки, тормозов и падений. Прослеживалась достаточно стандартная ситуация. Человек покупает хостинг насмотревшись рекламы. И у него все более или менее окей (хотя все равно тормозит и глючи все с достаточной периодичностью, но так, терпимо). Первые полгода максимум... ну за исключением почты. Потом тормоза, нагрузка и так далее. Потом его или переносят на новый сервер с новым хитрым названием, или он уходит от свеба. Если переносят на новый, то опять же, запала "приемлимой работы" хватает на 3-6 месяцов и снова ситуация становится невыносимой.
Что характерно, вроде бы реальные люди (хотя сейчас мы уже в этом не уверены, возможно это были просто пиарщики - т.к. уж очень в унисон поют все время) в таких случаях просто говорят что "свеб на самом деле рулез, просто конкретному клиенту сейчас не повезло с конкретным сервером, а так компания супер!.. ну вот просто с сервером не повезло, уточните Ваш сервер". Как факт отметим, что все наши клиенты сейчас перешли на других хостеров, не всегда более дорогих, но всегда более лучших.
По поводу ограничений. Через phpmyadmin не удавалось сделать хоть каких-либо приличных размеров дампы БД. В принципе ситуация достаточно типовая, когда речь о размерах хотя бы метра 4 дампа БД. Но у sweb-а иногда и 0.5Мб было не сделать. Почему-то 1 или 2 раза у нас был доступ к ssh на sweb ("почему-то" т.к. сейчас у них на сайте такой опции, надеемся это не наши галлюцинации:) ), ситуация была лучше, но опять же mysqldump рвался по таймауту не успев сделать солидный дамп. Никакой радости это нам не доставляло.
По поводу доменов. Клиент покупал домен через свеб. Домен почти истекает. Мы оплачиваем домен через какую-то там страницу на которой можно оплатить продление указав имя домена (по нехилой кстати цене там продление, с учетом сервисов предоставляемых). Пишем в суппорт - как там оно, дошли ли деньги, продлят ли домен, пишем в пятницу вечером. Ответ получаем только понедельник, что мол все хорошо, не волнуйтесь. Слава богу продлили, обошлось, тут ничегоне скажешь, снимаем шляпу, могли бы и подвести. Но елки палки, домен истекал в субботу, неужели нельзя было раньше проснуться? Понятно что клиент опять же не должен был тянуть до последнего дня, но не в этом дело.
Ну и напоследок. sweb недавно вроде как купил рбк? А некоторые хостеры, даже обычно корректно ведущие себя по отношению к коллегам, лишь помянули sweb как присно почившего после этой покупки. Да и об РБК хостинге тоже много где что написано, тут нет смысла что-то добавлять.
Как итог.
Мы не будем навязывать свою точку зрения или типа того.
Но для нас sweb это компания вида "скулхост с лицензией". То есть офис, лицензия, суппорт, безнал, какие-то гарантии что не исчезнет с рынка, но подход к клиенту и серверам всё тот же. При чем их "раньшие" низкие цены, незначительно выше скулхостов, но значительно ниже "китов" только подтверждают эту точку зрения. Sweb когда-то и как-то чудесным образом нащупал ту золотую середину, при которой качество постоянно не очень, но не настолько что бы заморачиваться с переездом (что всегда болезненно). Сейчас мы иногда советуем sweb, но только в одном случае - когда категорически не хочется связываться со скулхостами и хочется взять хостинг у компании, но при этом можно рискнуть качеством, а мелкие проблемы потерпеть во имя чуть более низкой цены.
P.S.: Надеемся никто не поломал глаза об "много текста", честно скажем, старались написать все что вспомнилось максимально объективно.
Какой удивительный топик. Давно такого не видели нигде.
Для начала немного "пофлудим". (в кавычках)
Голосование складывается не в Вашу пользу, а Вы обязались согласится с "многими" без оговорок на их "понятливость". Так что безотносительно всего остального, Вы уже не правы.
Уже причина для возврата денег, ибо Вы не сделали то, что должны.
Не нашли у Вас в списке услуг "телепатию", может поаккуратнее с обвинениями в "злом умысле" будете?
Во-первых, не путайте свои домыслы с фактами.
Во-вторых, Вы вроде бы взрослый человек. Как насчет свежей и революционной идеи отвечать за себя? Речь идет о том, выполнили Вы свои обязательства или нет. А не о том, что там думал заказчик когда что-то делал.
Изумительно просто. Заказчик виноват в том, что предпочел заплатить денег Вам, а не скачал варезный шаблон абсолютно бесплатно. О боже, на кол его!
Мы, например, достаточно часто покупаем шаблоны на монстрах... даже те, которые доступны в "полинтернета". Но если бы мы купили шаблон не на монстрах, а у Вас с доработкой, то мы бы сильно удивились тому, что Вы скинули нам варезный шаблон. И извинений никаких мы бы не приняли, не говоря уже об обвинениях в наш адрес.
В этом Ваша и проблема. У Вас всё "на Ваш взгляд". На Ваш взгляд Ваш заказчик должен был скачать варезный шаблон, а не покупать дизайн. На Ваш взгляд заказчик устраивает уловки с единственной целью подставить Вас. На Ваш взгляд... на Ваш взгляд. А заказчик аппелирует не ко "взгляду", а к фактам.
Развел простите на что? Само то, что Вы упоминаете о "разводе", уже означает, что Вы признаете свою неправоту по этой ситуации. Просто считаете, что она сгенерирована искуственно заказчиком, это Ваше такое личное мнение такое.
И Вы знаете, Ваши доводы звучат особенно смешно на фоне того, что Вы выше по топику сами же утверждали, что дизайнер Вас подвел. Ну и чем подвел Вас дизайнер, если поверить Вашему утверждению, что с заказчиком Вы поступили правильно?
Безусловно посредничество это тяжелый труд. Но часть работы посредника в том и состоит, что он берет на себя риски перед заказчиком за третьих лиц.
Дизайнер не сделал Вам то, о чем Вы договаривались с заказчиком- это Ваша проблема. Вы подписались принять результаты голосования, они Вам не нравятся - это Ваша проблема. Вы подозреваете заказчика в злом умысле, но не можете уличить - это Ваша проблема. Вы должны были предупредить заказчика, но не предупредили - это Ваша проблема.
В общем еще раз можем только повторить. Здесь, по факту, Вы много чего должны были сделать и не сделали. Заказчик Вам ничего должен не остался. И более того, Вы признаете то и то. Так может стоит "ответить за себя" и вернуть деньги в связи невыполнение своих обязательств? Тех, которые Вы сами и признаете.
(закончили "флудить")
В общем и целом мы полностью подписываемся под этой цитатой
Не в этом дело. "Строка запроса" (то что идет после ?) не является частью пути к имени файла и RewriteRule не обрабатывается (RewriteRule сам по себе обрабатывает только имя файла), поэтому и в скрипт параметры запроса не передаются.
Если нужна строка запроса, используйте %{QUERY_STRING}
На Ваш пример экстраполировать не хочется, но смысл в чем.
.htaccess RewriteEngine on RewriteRule ^(.*html)$ index.php?q=%{QUERY_STRING} [L]
index.php print_r($_REQUEST);
при запросе a.html?ddd=fff
выдаст Array ( [q] => ddd=fff )
P.S.: Для Вашего случая придется видимо или разбирать строку запроса внутри скрипта (что самое разумное) или использовать условия в mod_rewrite по строке запроса
RewriteCond %{REQUEST_URI} или RewriteCond %{QUERY_STRING}
например
RewriteEngine on RewriteCond %{QUERY_STRING} ddd RewriteRule ^(.*html)$ index.php?q=%{QUERY_STRING} [L]
будет срабатывать только если в строке запроса встретится ddd
P.P.S.: (что-то нас расперло:))
попробуйте такой код ( http://zc.tj/mr/page.shtml?20080915_1 пример работы )
RewriteEngine on RewriteCond %{QUERY_STRING} ^(.*)$ RewriteRule ^(page.shtml)$ index.php?p=page&id=%1 [L]
(естественно .htaccess куда надо кладите... или правила под свои пути правьте, и не будет 404 ошибки :))
А мы подозреваем, что вся тема ради реферальной ссылки в предыдущем посте, вот в этом:
1) Если это ограничение хостера и хостера никак не сменить, но нужно именно обойти это ограничение, то нередко работает следующий простой способ. Создаете второго юзера и даете ему права на соединение такие же как первому.
Ограничение "по стандарту" на кол-во коннектов как правило действует в отношении каждого конкретного юзера. Чуть чуть доработав скрипт, что бы он через раз выбирал другого юзера для коннекта, можно удвоить свои возможности.
Например банально так
if(mt_rand(1,2)==1) {//коннект через одного юзера } else { коннект через другого }
Способ с точки зрения "этики" не так некорректен как может показаться, т.к. никто не мешает хостеру ограничивать кол-во коннектов на аккаунт или не разрешать создавать несколько разных юзеров для доступа к БД. Т.е. фактически это может быть и недокументированный, но уж точно не хакерский способ.
2) К вопросу о pconnect. В случае наличия такой проблемы, нередко помогает вариант как раз избавиться от pconnect. Не будем сейчас вдаваться в детали почему, но как бы это не казалось странно, именно обычный connect нередко помогает в таких ситуациях, и это обосновано.
3) Проверьте не "подвисают" ли у Вас некоторые скрипты дольше чем необходимо. Может быть ситуация, когда они выполняются дольше чем Вы ожидали и держат коннект к базе не закрытым. Особенно если Вы выставили ignore_user_abort. Запрашивающему уже Ваша страница не нужна, он ее закрыл, а скрипт еще работает и отваливается только по таймауту допустим, все это время держа занятый "слот" коннекта.
Если у Вас есть права на рестарт мускула, может Вам проще увеличить кол-во возможных коннектов к базе в конфигурации мускула? Благо это одна строчка в my.cnf: max_connections=200 или другое число и всего делов.
Слегка задержались с "апдейтом", приносим извинения.
По 1-ому пункту решили все-таки модификаций не делать, т.к. для всех текущих проектов и так все отлично настраивается по текущим фильтрам. Если кто-то сможет показать проект где это реально будет нужно, с удовольствием сделаем.
По 2-ому пункту (пересчет внешних ссылок на автомате), пока упрощенный вариант http://abazaba.ru/sape/index2.php (требует логина и пароля, а так же ИД сайта... ). Работает и от нас, но в идеале скачивайте себе, у нас там 1 IP-шник и сапа не факт что этому обрадуется. Метод работы простой - вбиваете все как положено, скрипт автоматом раз в 6 секунд пробует обновлять количество ссылок в проекте. Что бы начать "не с самого начала" нужно ввести "link #" (порядковый номер ссылки с которой начинать). За раз обрабатывается по 50 ссылок (кол-во можно поменять 50 на другое число в строке if($ii>50) ).
После обработки 50 ссылок надо вспомнить об открытом окне и нажать "продолжить" внизу. Сделали так из-за относительно "хилых" хостингах в большинстве своем, изменить количество хоть на безлимит можно самостоятельно.
Программерам: мы в курсе что код ужасный:) Но тулза "на один раз" и узкоспециализированная, так что не обессудьте. Кому хочется окрасивить - велкам, благо гну/гпл.
Вот по этому поводу хотелось бы сказать. Сразу отметим, с одной стороны, что сами мы в общем-то не хостеры, поэтому наблюдаем со стороны и ситуация нас не задевает ни разу, поэтому все претензии типа "ага, шапка горит" идут мимо кассы. А с другой стороны отметим, что ТС не знаем, наездов на него не видели, поэтому это спич не в его защиту, а просто на тему Вашей отквоченной цитаты.
Вы знаете, тесты на школьников безусловно неплохая вещь, но последнее время (с тех пор когда стали чаще заглядывать в раздел "хостинг") подмечаем, что это уже не столько тесты "на школьников", сколько зачастую тесты "школьников". Никого конкретно не имеем ввиду (т.к. лениво лезть в старые топики вспоминать конкретных персонажей), но реально логика вида "сначала окунем с головой, а если адекватный человек, то выплывет, оботрется и будет радоваться жизни" она как бы не только школьников отсеивает, но и нормальных людей. Потому что доказывать "через окунание" свою состоятельность не всегда хочется, как раз нормальному человеку.
А значит для того, что бы лезть в это "окунание" сейчас и что-то доказывать нужно быть или отморозком (ситуация со школьниками) или иметь серьезный стимул (ситуация с хостерами, которые конкретно приходят сюда за клиентами и готовы ради этого на всё). Отличная аудитория пройдет тесты, да? При чем вторые иногда позволяют себя вести настолько некорректно (клиенты-то нужны), что и противоречить им уже не особо хочется, просто что бы не испачкаться (вспоминаем анекдот про спор с адвокатом и свинью), даже если они городят полную чушь.
Безусловно от этого раздел не умрет, писать будут, хостеры будут, и с пользователями "никакой чахотки от этого не случится" (с), но наблюдать это даже со стороны не очень приятно. Мы до этого наблюдали такую же ситуацию на руборде, а чуть позже на хостобзоре. Руборд сейчас считайте уже мертв (хотя по хостингу когда-то был очень неплох раздел), на хостобзоре (при всем нашем к нему уважении) стало намного меньше разносторонних личностей со своим мнением. Так что мы совсем не уверены что "все беды" от новичков, которым непременно надо "прописку" устраивать, а то "мало ли что".
Конечно отметим, что как и на любом форуме, большинство старичков хостеров здесь адекватны (примечание для тех, кому показалось что мы на всех бочку катим), но тут в тему та самая пословица про "бочку меда". Выступают-то в основном те самые "ложки дегтя" и общее впечатление нередко складывается именно по ним.
Сорри если кому-то показалось что это спич в чей-то конкретный адрес и заодно за оффтопик тоже сорри, просто не считаем мы правильными такие "тесты". И уж по меньшей мере они не предмет для гордости. Конечно "школьников" надо отсеивать, но не таким методами, которые отпугивают нормальных людей и уж никак не надо забывать про старших товарищей, нередко ведущих себя хуже школьников.
Проблема состоит в том, что наказание без вины бывает:) Как говорит одна древняя поговорка - "старые цитаты всегда стары, но не всегда верны". ТС (посмотрели все-таки его мессаги на форуме) действительно.... мммм... э.... скажем так - не идеал хостера. И пара серверов там и сям не предмет для гордости и признания заслуг (тут знаем у многих для своих лично проектов по паре серверов стоит). Но тем не менее, иногда складывается впечатление все-таки, что "с водой выплескивают и ребенка", это еще ребенок вообще сюда заходит посмотрев на предыдущие "выплескивания". Мы как бы это этом, сорри что повторяемся.
1) Гав:)
2) Не помним хаяния в Ваш адрес, вот честно. Бредовые претензии да, но они все настолько бредовые были, что как-то даже смешно. Но с другой стороны, давайте скажем честно, Вы здесь на форуме не особо за тем, что бы свои услуги предлагать, т.е. опять же "атипичный-хостер-участник-форума", свой кусок отъели, лишнего Вам не надо...
3) Стимул нужен что бы не срываться, вот в чем дело. Если где-то на тебя сразу гавкают, то зачастую проще проложить новую караванную тропу, чем идти по граблям и доказывать что ты не верблюд.
P.S.: На самом деле по факту - помеха. Не сама молодость конечно, а тот факт, что для многих возраст имеет значение и отношение к молодым другое. Опять же, если ты молодой, то надо доказывать что у тебя достаточно мозгов и опыта. Правда если слишком старый (уже почувствовали сами :D ) то приходится доказывать что ты не впал в маразм и еще не склеротик:)
У Вас очень странный подход и очень странные требования. Мы из СПб, поэтому на вакансию ни в коем случае не претендуем, но раз уж Вы задали вопрос "есть ли спецы", позволим себе отметить, что даже будучи в Москве на эту вакансию мы бы претендовать не стали если оплата в пределах разумной (понятно что безумно высокой оплатой можно кого угодно соблазнить:) ). Объясним почему мы так думаем
1) Когда Вы искали дизайнера /ru/forum/280309 - мы попробовали объяснить почему мало отзывов, все те же аргументы годны и сейчас. Кстати, кандидатура подходящая под те требования нашлась, если не секрет?
2) Мы еще год назад почти тут /ru/forum/comment/3101588 писали про откровенный косяк (пункт 5, ну некрасиво это, и это именно косяк, а не "силы безопасности"), а сейчас на том же сайте что там обсуждался, еще и сессии иногда в урлы вылезают (это уже к вопросу о сео). То есть у нас сразу рождается подозрение, что косяков-то по программингу будет много в старых проектах, а бороться с ними занятие малоприятное и малоинтересное... но шишки в любом случае будут на программере.
2.1) Из этого же следует еще одна вещь. Понятно что работа срочная, что стартует новый магазин каждые 3 месяца и все такое. Но у хорошего работника обычно аллергия на халтуру, даже если все надо делать срочно, поэтому опять же интерес будет ниже среднего.
3) По требованиям в этом проекте.
3.1) Требуется вебмастер/программер, но при этом от него требуются минимальные знания php/mysql и одновременно с этим отличное умение разбираться в чужом коде. Это как вакансия "с базовым знанием математики" с требованием "разбираться в математических моделей ядерных двигателей":)
3.2) Требуется вебмастер/программер, однако суровые требования к нему как к юзабилисту и сеошнику. Да еще и хтмл он должен знать. По сути требуется аналог эникейщика, но при чем работодатель ожидает профессионализма по любому направлению. Просто стремно (при всем уважении к Вам и это не личный выпад) устраиваться на такую работу, ведь почти гарантированно на чем-то проколешься и тут же обоснованно можно вылететь за дверь... с комментом "предупреждали же" - а ведь и правда - предупреждали. Да и эникейщиками не все хотят быть, многие предпочитают специализироваться и это объяснимо.
3.3) По возрасту 25 лет тоже конечно ограничение странное. Понятно что коллектив молодежный, но если Вам нужен профессионал, то таким ограничением Вы отсекли пожалуй половину аудитории потенциальной, хотя учитывая вышесказанное возможно надо как раз минимальную планку возраста опустить.
P.S.: Сорри если оффтоп, но Вы сами задали вопрос и возможно наш ответ Вам поможет. Не то что бы мы пытались тыкать в ошибки или доказывать что Вы не правы, но подход с нашей точки зрения настолько дикий, что вообще непонятно как Вы кого-то находить умудряетесь:) (что кстати частично подтверждается кол-вом отзывов в этом и прошлом топике с дизайном).
P.P.S.: И еще странный момент. Компания которая стартует с такой скоростью магазины, могла бы потратиться на разработку своего, благо оскоммерц далеко не лучший продукт по многим параметрам и основное его достоинство это нулевая стоимость покупки.
Сделали "следующую версию".
Видит "новые" цены (подчеркиваются красной чертой).
Добавлен краткий мануал.
Нет необходимости ничего chmod-ить ничего для работы.
Напоминаем, что для работы нужен curl/iconv и неплохо бы памяти выделять скрипту побольше.
Выложили на скачку, кто параноит или кому просто удобнее пользоваться скриптом у себя - ставьте у себя и используйте ( gnu/gpl лицензия со всеми вытекающими ).
В будущих планах 2 вещи
1.1) Вывод страниц для увеличения цен из конкретной области (пр/ув/цена/статус).
1.2) Наверное будет желание загружать список урлов для фильтра по пункту 1.1 (применимо будет при желании поднять цены только для проиндексированных страниц, ведь понятно, что те кто покупает на не проиндексированных, покупают или не для яндекса или просто на всякий случай и просто так не надо им задирать цены)
2) Релиз штуковины для автопересчета ВС на странице по всем страницам проекта (если под 400 страниц, то учитывая еще и задержку по 5 секунд, вручную их перетыкивать сложновато).
И то и то хотим сделать в течении недели (не уверены пока насчет пункта 1.2 правда).
Для тех кто еще в недоумении "на фига это надо" отвечаем.
Допустим для некоторых ссылок пересчитался ПР или вдруг при переиндексации изменилась вложенность. Фактически изменились параметры ссылки. Или раньше Вы поднимали цены только на часть ссылок из блока УВ/ПР. Тулза помогает увидеть картину по сайту в целом и сделать выводы о необходимости коррекции цен, увидеть по каким ценам наиболее хорошо раскупаются ссылки, на сколько теоретически можно поднять цены и так далее.
P.S.: Понимаем что ажиотажа особого нет и не будет:) Но если кто-нибудь сможет высказать мнение, насколько людей от использования этой штуки останавливала необходимость "свечения" данных на стороннем ресурсе, нам было бы интересно.
