По сообщениям нескольких англоязычных ресурсов один из инженеров Google раскрыл планы компании о том, что в течение ноября этого года будут внесены изменения в четыре элемента их поисковой машины, а также в систему AdSense. Это связано с намерениями помешать дальнейшему расширению масштабов чёрной оптимизации, жульничеству с использованием PR и AdSense скликиванию.
PageRank должен быть обнулен и заменён.
PageRank (PR), получивший за время своего существования достаточно много нелестных отзывов, должен быть упразднён. Все значения PR, отображаемые на панелях браузеров будут сброшены и больше не будут восстановлены ( вот почему последнее обновление PageRank так затянулось). Это очень печальная новость для людей, зарабатывающих с помощью платного размещения ссылок на своих сайтах. На собственном примере могу сказать, что буквально сегодня была продана ссылка за 3.99 $/месяц на этом блоге через систему .
Упразднение PR по планам должно быть завершено к середине ноября, одновременно с выходом новой панели инструментов Google версии 4.2. В ней уже появится VR (visitor rating). Google VR™ будет использовать систему, похожую на известный социальный сервис digg. Для этого на панели Google появится кнопка для голосования, фиксирующая рейтинги страниц, выставляемые посетителями сайта. Отображение VR будет таким же, как и PR – в виде синей полоски на tool bar.
При расчете VR будет приниматься во внимание несколько факторов, такие, как соотношение между количеством посетителей и голосований и откуда посетитель пришел на сайт (например, с другого сервера или с поисковой машины). Также будет учтено как часто посетитель возвращается на ваш сайт в течение длительного промежутка времени.
AdSense скликивание
С целью уменьшения мошенничества с системой AdSense и непреднамеренного скликивания, Google разработал систему предотвращения случайных кликов. Разработанный механизм, в случае нажатия кем-либо на рекламное объявление, предусматривает показ предупреждения. В нем сообщается, что ссылка является PPC рекламой и будет произведен переход на спонсорский сайт. В случае положительного ответа Вы получаете оплату за клик, если ответ отрицательный – нет. Есть предположение, что это уменьшит AdSense заработки и увеличит CPC (cost per click).
Данные об обратных ссылках не будут доступны
Оператор link: в поиске Google был долгое время способом, с помощью которого можно определить как много существует обратных ссылок на ваш сайт (достаточно важный фактор при размещении платных ссылок на сайте). Но теперь можно об этом не беспокоится, потому что Google убирает все данные об обратных ссылках из поисковой машины, а также из инструментов вэб-мастера и службы аналитики.
Замена rel=”nofollow” на rel=”dofollow”
Не так давно Google предложил великолепную идею использовать атрибут rel=”nofollow” для ссылок. Это сообщало Google-роботу о том, что не надо переходить по ссылкам для индексирования ресурсов, на которые они указывают. Это хорошо помогало бороться со спам-комментариями в блогах. Но, к сожалению, не так много людей использовало этот атрибут, и он постепенно вымер. По этой причине в ноябре Google заменяет его значение на rel=”dofollow”, что должно служить командой роботу перейти по ссылке и проиндексировать ресурс. Все теги ссылок без указания атрибута или с атрибутом rel=”nofollow” будут проигнорированы Google роботом. Таким образом, все линки, приносившие вам прибыль, станут бесполезными.
Вот и закончился первый месяц использования системы купли-продажи ссылок и хочется подвести некоторые итоги, поделиться опытом.
За это время я постарался попробовать все основные режимы со стороны вэб-мастера (ВМ), а также попытался вывести деньги. Надо сказать, что система выглядит ещё достаточно сырой, но, с другой стороны обладает достаточным потенциалом и множеством полезных функций.
Работа в SAPE для ВМ начинается с заведения площадки и выставления цен на страницы. При этом рекомендуется придерживаться средних значений цены, что я и сделал. Ссылки начали продаваться, практически сразу же, но поначалу мне была непонятна избирательность Оптимизаторов. То есть на некоторых страницах все линки уходили на ура за два-три дня, а на других не продавались совсем.
Всё стало понятно, когда в списке страниц, на которых могут быть помещены ссылки, появилась новая колонка ВС, то есть «внешние ссылки».
Оптимизаторы то видели ВС всегда и делали выводы – с большим количеством внешних ссылок страница представляет меньшую ценность для них.
Пришлось срочно заняться оптимизацией контента и других частей страниц, генерируемых блог-движком. С точки зрения SEO считается, что самым подходящим способом скрыть внешние ссылки для поисковиков (и как я надеялся для SAPE) это обрамить их тегом n o i n d e x. Это действует на Яндекс, для Google рекомендуется использовать атрибут rel=”nofollow”.
Частично это помогло, но для некоторых страниц до сих пор отображаются сильно завышенные результаты. Даже элементарный ручной подсчет показывает, что не может быть на странице столько ссылок. Эта тема до сих пор активно обсуждается на форуме, но однозначного ответа всё равно нет. По заявлениям самих SAPE-разработчиков параметр ВС пересчитывается где-то раз в сутки только для тех страниц, где уже размещены sape-links. Для остальных, только во время индексации.
Я пока решил ничего не трогать и посмотреть, что будет после очередном SAPE-индексировании, возможно, оно поможет актуализировать значения для ВС.
Для себя я сделал вывод, что если всё настроено правильно и выставляются адекватные показателям PR, тИЦ и ВС цены, то ссылки будут постепенно раскупаться и кривая роста доходности должна выглядеть как у успешного трэйдера. Ниже график изменения значений ежедневных начислений для моей площадки:
Теперь о приятном, то есть о выводе денег. На момент регистрации в системе поддерживались Яндекс.Деньги и WebMoney. Затем из-за каких-то проблем, остались только WM. Сам процесс перевода заключается в выставлении заявки, где указывается сумма (не более 10 WMZ), затем заявка ставится в очередь. Весь процесс занимает около суток. Процесс перевода при первой выплате в целях безопасности длится гораздо дольше, примерно неделю.
Наверняка уже многие счастливые обладатели сайтов, разработанных на php или html, установили и с удовольствием пользуются системой купли-продажи ссылок sape.ru. Поскольку мой блог использует Typo движок, написанный на Ruby on Rails, то конкретных инструкций по размещению sape-кода мне найти не удалось ни на форуме sape.ru, ни в Интернет. Поэтому пришлось провести небольшое исследование по способам интеграции Rails и PHP и затем реализовать на основе собранного материала Typo sidebar plug-in.
Первое, что я сделал, это вынес php-код для отображения ссылок, в отдельный файл с именем sape1.php. Этот файл был сохранен в директории /var/www/websites/mysite/public
Как показали первые эксперименты с sape, большая часть проблем с отображением ссылок продавцов была связана с тем, что невозможно определить внутри php-скрипта текущую страницу сайта или доменное имя. Поэтому далее в этом скрипте явно были прописаны параметры, в обычных условиях получаемые из контекста web-сервера: ‘request_uri’, ’host’. А также изменён параметр ’charset’ на UTF-8 в соответствии с используемой кодировкой страниц моего сайта. Значение ‘request_uri’ дополнительно преобразовывалось функцией urlencode() для корректной интерпретации символов кириллицы в URL.
Через административный интерфейс добавляем новый plug-in на sidebar. С появлением новых запросов на размещение в sape.ru:
… они появляются в sidebar области Typo блога:
Так что те, кто ещё не присоединился, в действии систему купли-продажи ссылок Sape.ru теперь и на Ruby On Rails сайтах.
* * UPDATE * *
описанная выше методика была протестирована на системе RedHat EL3 c PHP 4.3.2
Позже возникла необходимость перейти на PHP 5.1 и оказалось, что подход к интеграции php-sape клиента в этом случае немного отличается.
При запуске php-скрипта public/sape1.php из typo-окружения элемент массива $_GET[‘uri’] не инициализируется значением, в результате ссылки на странице не видны.
Для исправления ситуации вместо $_GET[‘uri’] нужно использовать $argv[1], также uri имеет уже закодированный вид, так что убираем строку с функцией urlencode():
<?php
define('_SAPE_USER', '999999999999999999999999999999999');
require_once('/var/www/websites/mysite/'._SAPE_USER.'/sape.php');
// replace $_GET[‘uri’] with $argv[1]
$o['request_uri'] = $argv[1];
// remove uri encoding
$o['host'] = 'cooper.ezlibrary.com';
$o['charset'] = 'UTF-8';
$sape = new SAPE_client($o);
unset($o);
echo $sape->return_links();
?>
А в typo-плагине откорректировать файл views/content.rhtml опустив название параметра uri и убрав ключ -q:
После выхода версии typo 4.1 тут же захотелось опробовать её в деле. В принципе, сам процесс обновления практически не отличался от предыдущего, добавился только 4-й пункт, из-за того что изменился адрес и способ доступа к svn-репозитарию проекта. Ещё одна вещь, которая бросилась в глаза после завершения обновления, это проблема с обработкой тэгов typo:code, typo:lightbox. Это только те теги, которые я заметил. Судя по , существуют и другие похожие проблемы. обещает разобраться с этим в релизе 4.1.1. Пока что пришлось для топовых постов поменять <typo:code> на <pre> а <typo:lightbox /> на <img />
Итак, сам процесс обновления описан ниже:
1) Останавливаем lighttpd:
/etc/init.d/lighttpd stop
2) Делаем backup сайта:
tar cfv cooper.ezlibrary.com_r1193.tar www.ezlibrary.com/*
gzip cooper.ezlibrary.com_r1193.tar
Где-то с конца прошлого года казалось, что проект вот-вот закончит свое существование. Об этом можно было судить потому, что разработка не велась несколько месяцев, официальный сайт проекта был недоступен в течение трёх месяцев без каких-либо официальных объяснений. Не была известна дата следующего официального релиза и, если говорить, в общем и целом - будущее проекта. На этом фоне многие приверженцы Typo начали переходить на Mephisto или другие blog-engines.
И вот, наконец, вышел очередной релиз Typo 4.1 , в котором реализовано несколько интересных вещей:
Поддержка Ruby on Rails 1.2.
Внесены функциональные и эргономические изменения в раздел администрирования блога (back office).
Добавлена поддержка интернационализации и локализации, используя localization плагин. Из поддерживаемых языков в данном релизе кроме английского языка доступен ещё французский.
Комментарии и trackbacks по умолчанию модерируемы.
Исправлено множество ошибок и проведено улучшение кода.
Поддержка RSS для тэгов и категорий.
Плагины используют механизм Rails plugin.
Typo 4.2 по прогнозам должно быть выпущено через два месяца, и судя по планам этот релиз будет выглядеть также впечатляюще:
Поддержка пользовательских ролей и процесса публикации статьи.
Возможность реализации на одной копии Typo множества блогов.
Переход с модуля Localization на Globalization для поддержки i18n и l10n.
Интеграция предложенных разработчиками патчей как плагинов.
Завершение улучшения административного раздела блога.
Модем приобрел в мае 2005 года, при настройке подключения к Интернет провайдер предоставил инструкцию для настройки модема исключительно в режиме Bridge. Для меня это было не очень удобным, так как кроме ноутбука через Wi-Fi планировал использовать также КПК. Решил на первое время оставить пока так, а потом перейти на Routingmodeплюс DHCP с Private-адресацией.
И вот, спустя почти два года, настало время осуществить задуманное. Кроме того, под это дело захотелось обновить прошивку микропрограммы. На сайте Zyxel в разделе была скачана последняя версия 3.40(PE.11)C0_20061218 и через web-интерфейс (Maintenance->Firmware) успешно загружена в модем.
Надо сказать, что сразу же после проведенного апдейта обратил внимание на нестабильную работу модема. При обращении к некоторым сайтам он стал надолго задумываться, а иногда и просто выдавать сообщение о недоступности ресурса. Номер предыдущей версии я не запомнил, сделать backup также не догадался.
Ничего не другого не придумал, как сделать downgrade до предпоследней версии 340PE9C0_20050907. Прошивка длилась 15-20 минут, светодиод PWR/SYS мигал зелёным цветом. Предыдущая прошивка по времени занимала около 10 минут, и я подумал, что модем завис и решил перезапустить его. Хотя, конечно, выключать устройство в процессе прошивки категорически запрещено. После этого, при включении замигал PWR/SYS, затем, через некоторое, время буквально на полсекунды загорались янтарным цветом и гаснули все лампочки LAN. Затем, секунд через пять, зелёным загорался индикатор WLAN, через три-четыре секунды гас и всё повторялось снова в цикле. Это могло означать всё что угодно, в том числе, что процесс прошивки завершился некорректно и микропрограмма безнадёжно испорчена.
За советом решил обратиться в службу поддержки Zyxel. Ответ получил достаточно оперативно, но ничего хорошего он не предвещал. Технический специалист посоветовал сделать аппаратный сброс. В случае, если это не поможет, он рекомендовал привезти устройство в сервисный центр. Надо сказать, что HARD RESET я пытался сделать сразу же после неудачной попытки поменять прошивку и, это не имело никакого эффекта. Но для очистки совести решил сделать его ещё раз, предварительно изучив раздел User Guide, посвященный аппаратному сбросу. Прочитав первое предложение, я понял, что надежда есть:
“Удерживайте кнопку RESET (ПЕРЕЗАПУСК)в течение десяти секунд до тех пор, пока светодиод SYS или светодиод PWR/SYS не начнет мигать, а затем отпустите её.”
Я, конечно же, не удерживал RESET десять секунд, а просто нажимал и отпускал. В результате модем нормально инициализировался, я смог подключиться к нему, используя стандартные настройки (пароль и IP адрес). Устройство, на первый взгляд, работало стабильно и перепрошивать микропрограмму я не стал. Сделав необходимые настройки для подключения к провайдеру и работы через Wi-Fi, я забекапировал конфигурацию:
C:\>ftp 192.168.1.1
Связь с 192.168.1.1.
220 FTP version 1.0 ready at Sat Jan 01 03:05:18 2000
Пользователь (192.168.1.1:(none)): root
331 Enter PASS command
Пароль: ******
230 Logged in
ftp> get rom-0 my_zyxel_config.rom
200 Port command okay
150 Opening data connection for RETR rom-0
226 File sent OK
ftp: 49152 байт получено за 0,30 (сек) со скоростью 163,30 (КБ/сек).
ftp> quit
221 Goodbye!
В результате в файле my_zyxel_config.rom мы получили текущую работающую конфигурацию, которую в случае неудачного изменения настроек можно будет восстановить.
Анализируя информацию о статистике использования моего блога, я обнаружил, что ежедневно с конкретных хостов происходит подозрительно бурная активность, характерная скорее для роботов или пауков чем для реальных пользователей.
Кроме того, что эта информация искажала общие данные статистики использования ресурса, к тому же я получал приличный объем зарубежного трафика, за который при определенных условиях приходится платить отдельно.
Я решил найти простое и действенное средство защиты от паразитного трафика, которое, по возможности, должно базироваться на стандартных утилитах LINUX. Для себя я выделил несколько подходов:
Блокировать “плохие” хосты на уровне приложения;
Использовать стандартные средства вэб-сервера Apache или lighttpd;
Настроить правила утилиты iptables, которая присутствует во всех LINUX дистрибутивах, базирующихся на ядрах 2.4.x или 2.6.x
Первые два способа были исключены из рассмотрения, поскольку здесь существует определённая привязка к приложению или к конкретному web-серверу. И если, например, Apache будет заменён на ngnix, придется заново прописывать блокирующие правила. К тому же, паразитные пакеты будут доходить до вэб сервера и приложения, дополнительно загружая их.
Используя утилиту iptables достаточно просто можно настроить набор правил для блокирования, а также получить средство для накопления и просмотра статистики по созданным правилам.
Настройка правил iptables
Процесс настройки достаточно простой и занимает несколько минут. Надо заметить, что Вы должны зайти на сервер как root пользователь или использовать команду sudo для добавления правил.
Итак, у нас есть конкретный хост (crawler.bloglines.com, IP=65.214.44.29) и целая подсеть (84.110.0.0), которые надо забанить. Правила выглядят так:
#Crawler bloglines
/sbin/iptables -A INPUT -s 65.214.44.29 -p tcp -m multiport --dports 80 -j DROP
#bzq-*.red.bezeqint.net
/sbin/iptables -A INPUT -s 84.110.0.0/255.255.0.0 -p tcp -m multiport --dports 80 -j DROP
Для других хостов или подсетей в правилах iptables, меняется только IP источника (параметр -s).
Просмотр статистики iptables
Запускаем iptables с параметрами -L и -v для просмотра статистики.
Опция -L определяет вывод статистики для цепочки (chain). Если конкретная цепочка не задана, то для всех.
Опция -v задает расширенный вывод, включающий в себя счетчики пакетов и байт.
Очень часто добавляется параметр -n, который говорит команде iptables о том, что не надо обращаться к DNS для разрешения IP адресов и вывода их в виде доменных имен. Это значительно уменьшает время на выдачу результатов и позволяет уменьшить нагрузку на сервер.
Для дополнительного удобства список правил может быть пронумерован. Для этого используется опция –line-numbers.
/sbin/iptables -L -v --line-numbers
Сохранение правил и статистики
Если перезагрузить компьютер или удалить iptables kernel modules вся информация о собранной статистике и добавленных правилах будет утеряна. Чтобы предотвратить потерю данных необходимо делать бэкап после каждого изменения в списке правил. Для этого служить утилита iptables-save. Например:
iptables-save -c > /root/iptables-backup.txt
Восстановить данные из бэкапа можно используя команду iptables-restore. Обычно это делается после перезагрузки в одном из скриптов инициализации, например в /etc/rc.d/rc.local для Red Hat Linux.
24-25 ноября в гостинице Рэдисон SAS проходила выставка FOREXEXPO-2006
На входе посетителей встречали симпатичные ангелочки (девушки, одетые в соответствующие костюмы), а посетителей выстаки радовали, а некоторых даже пугали своими речевками девушки из группы поддержки фирмы АЛЬПАРИ
Как сказал представитель АЛЬПАРИ они не в первый раз удивляют посектителей чем-то новым, – на первую выставку принесли живого крокодила, на второй угощали шаманским. И вот теперь пригласили cheer-leeders.
После выступления группы поддержки было приятно получить в подарок книгу “Код Эллиотта: волновой анализ рынка FOREX”. Она раздавалась всем желающим совершенно бесплатно.
Ну и конечно были проведены конкурсы. Разыгрывались книги, футболки, а также призы покрупнее. Две дилинговые фирмы разыграли призы 500$ на торговый счет, а самым крупным призом стал домашний кинотеатр BBK.
Во время проведения выставки также проводились бесплатные мастерклассы. Я посетил один из них – “Особенности спекулятивной торговли на российском фондовом рынке”, докладчик фирма . Прозвучало достаточно много полезной и новой для меня информации, которую можно вкратце описать следующими тезисами:
Кореляция между изменением цены акций одной и той же компании на различных торговых площадках, например Лондонской и Российской;
Коррекляция цен на бумаги нефтяных компаний;
Корреляция между фьючерсами и акциями;
Модные бумаги. Происходящие события вокруг какой-либо фирмы отражаются на цене акции, бумаги становяится модными ( например ЮКОС);
При отслеживании изменения рыночных цен удобно использовать котировочный лист (стакан);
Обязательно учитывать изменчивость рынка. Не рекомендуется использовать одни и те же методы торговля на протяжении длительного промежутка времени. То, что работало раньше, может не работать в будущем.
Отслеживать совокупное количество спросов и предложений. Ловить момент для входа на рынок, когда увеличивается спрос;
Понимать важность увеличения объема торгов. Оно происходит обычно на точках изменения (Hi & Low);
Для Intraday торговли нужен только котировочный стакан. Не важны ни графики , ни новости;
В случае падения акций компаний одной отрасли (скорее всего в нефтяной) отследить по тиковым графикам, кто упал первым. В этом случае для остальных шортить может быть поздно, скорее long. Этот тезис базируется на том, что при поступлении плохих новостей по одной из компаний, по инерции это сказывается на ценах всех остальных. Однако, разобравшись участники рынка начинают скупать подешевевшие акции.
