Общее вводное замечание: joomla все настройки, устанавливаемого модуля, читает их файла <имя модуля>.xml, который в обязательном порядке идет с каждым модулем. Так вот среди прочих параметров в этом файле перечислены и языковые файлы которые идут с данным модулем. Находятся они в секции languages. Пример секции с описанием прикрепленного файла английского языка для модуля rokajaxsearch:

<languages>
	<language tag="en-GB">en-GB.mod_rokajaxsearch.ini</language>
</languages>

как нетрудно догадаться атрибут tag указывает наименование локали а содержимое поля language показывает нам присоединенный файл с описанием используемых констант, который относится к данной локали. Если посмотреть, то файл этот находится, как правило, в корневой папке установочного архива.
Теперь собственно к вопросу руссификации.
Как мне видится есть 2 пути:
1. Более сложный, и как мне кажется более необходимый разработчикам модулей нежели простым пользователям.
Итак:
а) нужно распаковать отдельно установочный архив англоязычного модуля.
б) взять англоязычный ini - файл
языковых констант (в нашем примере это en-GB.mod_rokajaxsearch.ini). Сохранить его под новым именем (например: ru-RU.mod_rokajaxsearch.ini) и далее в этом новом файле перевести все константы с английского на русский


Затем сохранить этот файл в кодировке "UTF-8", поскольку именно эта кодировка используется Joomla
в) после того как вы сформировали файл языковых констант для русского языка, необходимо исправить секцию languages в установочном xml-файле и добавить туда наш новый файл с описаниями:

<languages>
	<language tag="en-GB">en-GB.mod_rokajaxsearch.ini</language>
	<language tag="ru-RU">ru-RU.mod_rokajaxsearch.ini</language>
</languages>

г) далее мы модем упаковать наши файлы в новый архив и установить модуль обычным способом через меню Расширения -> Установить / удалить -> Загрузить файл пакета.

А вот вторым, более простым, вариантом руссификации модулей я с радостью поделюсь со своими подписчиками, необессудьте

Итак, вместо того чтобы править установочный архив модуля мы просто устанавливаем его в систему, как написано выше. А затем в папке /language/en_GB/ находим файл с англоязычными описаниями en-GB.mod_rokajaxsearch.ini и копируем его в папку /language/ru_RU/ с новым именем ru-RU.mod_rokajaxsearch.ini.
Далее делаем перевод значений констант на русский язык, сохраняем новый файл в кодировке UTF-8, и вуаля модуль руссифицирован и на ваших страницах в поле поиска уже написано не Search... а Поиск....

Кстати, вопрос в тему, это хостинг для сайта. Отличным вариантом, как говорится, на все случаи жизни является выделенный сервер. Ваш портал на Joomla будет просто в "восторге" от тех ресурсов, которые дает dedicated server, а ваши пользователи будут признательны за быстро загружающийся сайт.

Как с этим бороться?

Знакомый с SEO человек сразу ответит: "Нужно закрыть ссылки в комментариях в noindex для Яндекса и указать для ссылки nofollow для Google и некоторых других." И будет прав! Встает следующий вопрос: а как сделать это в комментариях WordPress?
Для этого нужно немного поправить файл wp-includes/comment-template.php. Найдите в нем описание функции function get_comment_author_link() и далее исправьте формируемую там ссылку следующим образом:

$return = "<noindex><a href='$url' rel='external nofollow'>$author</a></noindex>";

Вот собственно и все.
После этой манипуляции все ссылки на внешние сайты, указанные в данных комментатора будут закрыты как для Google, так и для Yandex.

1. Я буду показывать пример с использованием библиотеки cURL. Если по какой-то причине вы ее не используете, то, исходя из общих принципов изложенных здесь, сможете переделать код под использование на сокетах.

2. Полезностью в плане общевебпрограммерской эрудиции, в нашем случае, будет чтение раздела 7.2 RFC 1341, который описывается Multipart Content-Type и используется при передаче файлов из формы методом POST.

Итак, теперь по сути вопроса.

Как говорит нам php manual раздел V.38 Handling file uploads, чтобы форма корректно передавала данные на сервер, в атрибутах тега form обязательно должен быть указан enctype="multipart/form-data" , или другими словами нам необходимо применить тип кодирования данных формы multipart/form-data. Кто может быть не в курсе, по умолчанию данные формы, при передаче на сервер кодируются как application/x-www-form-urlencoded, т.е. мы, как правило, не указываем никакого enctype, и все отлично передается именно как application/x-www-form-urlencoded.

Не вдаваясь в подробности application/x-www-form-urlencoded, это все та же строка вида:

<параметр1>=<значение1>&<параметр2>=<значение2>&<параметр3>=<значение3> и т.д.,

которая передается и в GET запросе, только, в отличие от GET, уже не ограничена 255 символами. Подчеркиваю, строка - это именно строковые данные или данные, которые могут быть приведены к этому виду.


А что же такое multipart/form-data?

Как говорит нам вышеупомянутый RFC 1341, этот тип кодирования используется, когда сообщение (у нас это POST запрос) объединяет разнородные данные в едином теле (в нашем случае в контентной части нашего запроса). При этом тело сообщения (контентная часть POST запроса) должно содержать одну или более частей, которые отделены друг от друга заданным ограничителем. Каждая такая часть сообщения начинается с ограничителя, за которым идут поля заголовка именно этой части и собственно ее тело. Для определения конца всего сообщения используется все тот же заданный ограничитель. Это, вобщем, мой довольно свободный перевод обще-вводной части раздела RFC, посвященного Multipart Content-Type. Я постарался описать это понятным языком, но читатель вправе вынести свое суждение и не согласится со моим трактованием документа.

Теперь собственно практический пример, того о чем я писал выше.

// сабмитим форму загрузки файла

// определяем разделитель
$boundary = "---------------------------".mktime();

// формируем тело запроса (контентную часть)
// будем передавать два поля: file1 - это собственно наш файл и comment - поле простого текстового коментария
// поле файла
$data = "--".$boundary."\r\n";
$data .= "Content-Disposition: form-data; name=\"file1\"; filename=\"yourfile.txt\"\r\n
Content-Type: text/plain; charset=windows-1251\r\n\r\n";
$data .= file_get_contents("yourfile.txt")."\r\n";
$data .= "--".$boundary."\r\n";

// поле комментария
$data .= "Content-Disposition: form-data; name=\"comment\"\r\n\r\n";
$data .= "Ваш текстовый комментарий к файлу"."\r\n";
$data .= "--".$boundary."--\r\n";

// массив полей заголовка запроса
$header_fields = array(	"Content-Type: multipart/form-data; boundary=$boundary",
"Content-Length: ".strlen($data));
// url скрипта который принимает данные формы (поле action тега form)
$form_url = "http://yourdomain/fileupload.php";

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $form_url);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, $header_fields);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
$res = curl_exec($ch);

Как вы видите из приведенного примера, сначала мы определяем разделитель (переменная $boundary), затем формируем контентную часть нашего запроса (переменная $data). Контент в нашем случае будет состоять из двух частей (проще говоря переменных). Первая file1 - это наш файл, который мы посылаем на сервер, и который будет обрабатываться в php через массив $_FILES. Вторая comment - поле простого текстового комментария (например, оформленного тегами input или textarea), и которая будет видна в массиве $_POST. Не трудно заметить, что каждая часть, как и говорилось выше, начинается с разделителя, представленного переменной $boundary, за которым идут поля заголовка данной части.

В нашем примере, в заголовках для отправляемого файла мы указали:
Content-Disposition: form-data; name=file1; filename=yourfile.txt
Content-Type: text/plain; charset=windows-1251
т.е. в поле заголовка Content-Disposition указываем, что это у нас form-data и собственно имя поля формы name=file1, а также имя нашего файла filename=yourfile.txt, которое и будет доступно по ключу в массиве $_FILES['file1']['name']

А для поля comment мы указали лишь:
Content-Disposition: form-data; name=comment
Т.е. это лишь определение имени поля формы, значение которого будет доступно по ключу в массиве $_POST['comment']. При этом следует отметить, что согласно RFC 822 и описанию данному в разделе 4 The Content-Type Header Field RFC 1341, если не указано иного, то по умолчанию используется Content-type: text/plain; charset=us-ascii.

А после заголовка каждого поля в контентной части идет непосредственно содержимое.
В нашем примере, для поля file1 вычитываем содержимое файла через file_get_contents, которая, кстати сказать, является безопасной по отношению к бинарным данным, т.е. этой функцией можно читать все файлы.

А для поля comment указываем в качестве содержимого строку "Ваш текстовый комментарий к файлу"

Далее мы указываем некоторые поля общего заголовка нашего запроса как:
Content-Type: multipart/form-data; boundary=$boundary
Content-Length: strlen($data)
и собственно отправляем POST запрос функцией библиотеки CURL

На принимающей стороне скрипт http://yourdomain/fileupload.php увидит наши данные в полях массивов $_FILES['file1'] и $_POST['comment']

Вот собственно и вся техника, спасибо за внимание и до новых встреч в эфире.

Сейчас я не буду касаться таких общих для любого сайта способов, как продажа места под ссылки, продажа прямых ссылок и размещение контекстной рекламы на своем сайте. Мы говорим именно о блоге и способах заработка специфичных для данного вида ресурсов.

Итак, на блоге можно заработать:

• размещая тематические посты "под заказ" или обзоры. Т.е. например, рекламодателю нужна статья с описанием чего-то. Вы пишете такую статью, и публикуете у себя на блоге, и за это вам платят деньги.
• размещая платные ссылки рекламодателя, непосредственно в постах, так называемые постовые. По сути - это 1-2 предложения по теме с нужной ссылкой. Отдельный пост для этих целей как правило не пишется.

Так вот для реализации этих способов первое что нужно это найти человека (организацию), которая согласится заплатить Вам денег за ваши старания, то бишь рекламодателя. И тут нам на помощь приходит большое количество сервисов, которые и занимаются буквально "сводничеством" :), т.е. стыкуют рекламодателя и блогера.

Наиболее известный в рунете это конечно Блогун но он не единственный, среди прочих можно отметить не так давно открывшийся сервис ПрофитБлог.

Общая схема работы подобных сервисов примерно одинакова, разница как правило в комиссии по сделкам, деталях интерфейса и некоторых других вещах. Конечно, первое, что нужно сделать это зарегистрироваться. На Блогуне предусмотрены раздельные интерфейсы для рекламодателя и для блогера, а на ПрофитБлог - е интерфейс общий. По комиссии, на Блогун - е она составляет: 15%, а на ПрофитБлог - е: 10%.

Следующий шаг после регистрации, это добавление своего блога в систему и его активация. Надо сказать что сервисы как правило позволяют добавлять в систему не только блоги на отдельных (назовем их личными) доменах, но и блоги на общедоступных сервисах, таких как livejournal (ЖЖ) и прочих. Активация блога делается администратором, после размещения счетчика - картинки, код которой сервис предлагает разместить в посте на блоге.

Ну и самое важное для нас блоггеров, стремящимся заработать, это конечно предложения реклабодателей. Они выделены на отдельной странице, где рекламодатель указывает что именно его интересует: краткий обзор, подробный обзор или ссылка (постовой), описывает тематику, и как правило указывает пределы стоимости. Вы как блогер подбираете заинтересовавшие вас предложения и оставляете по ним заявки. Далее рекламодатель по идее рассматривает вашу заявку и принимает либо отклоняет ее. В случае если заявка принята, вы должны выполнить то что было указано в предложении (разместить пост или ссылку), после чего рекламодатель проверяет результат вашей работы и если все ок, то вы получаете деньги на счет в системе.

Далее, в каждом сервисе есть система вывода средств с внутреннего счета, с помощью которой вы и получаете свои "кровные"

Вот, вкратце и все.


Ваши комментарии и предложения оставляйте ниже и всем больших заработков.

Один момент, о котором необходимо упомянуть в плане увеличения заработка на сайте, это конечно поисковое продвижение или так называемая раскрутка сайтов. Узнать о том что это такое и как правильно это делать вы можете на сайте www.odica.ru
Еще о том как заработать на сайте, читайте
как заработать на собственном сайте
Также все о прическах и здоровом образе жизни
модные стрижки

Потом немного поковырявшись, пришел к выводу, что для моих целей, а именно отладки приложений, мне совсем нет необходимости в Zend Platform и соответственно Zend Core.

На самом деле для этих целей достаточно скачать и установить Zend Debugger-5.2.12 версия для windows здесь или более полный набор версий в том числе под linux здесь

Вся нехитрая установка описана в принципе в Readme который есть в архиве, но я все же опишу процедуру установки на windows платформе здесь:

1. Распаковываем содержимое архива
2. Выбираем папку с соответствующей вашей версией php и копируем находящийся в ней файл ZendDebugger.dll в какую-то общедоступную папку.
3. Затем добавляем в файл php.ini, следующие строки:

zend_extension_ts="путь к файлу ZendDebugger.dll"
у меня zend_extension_ts="c:\WINDOWS\system32\ZendDebugger.dll"

zend_debugger.allow_hosts=разрешенные для запуска отладчика хосты
у меня zend_debugger.allow_hosts=127.0.0.1/32

zend_debugger.expose_remotely=allowed_hosts
или zend_debugger.expose_remotely=always



а также не лишне добавить настройки самого отладчика, при этом порты на которых он висит вам нужно будет открыть в настройках вашего фаервола. У меня эта секция выглядит так

debugger.enabled=on
debugger.profiler_enabled=on
debugger.hosts_allow=127.0.0.1
debugger.hosts_deny=ALL
debugger.ports=7869, 10000/16

4. Теперь нужно перезапустить вебсервер

После всех описанных манипуляций phpinfo() должен выдать что Zend Engine установлен вместе с дебагером, и там будет присутствовать строка:

with Zend Debugger v5.2.12, Copyright (c) 1999-2007, by Zend Technologies

После этого нажав кнопку в Zend Studio 5.5 меню: Tools -> Check Debug Server Connection должно выдать что сообщение, что все ОК.

История началась с перевода на мой R-кошелек 9.12.2008 суммы в 15000 WMR. После этого я попытался обменять эти деньги на wmz с помощью нескольких обменных пунктов, в частности я обратился в сервис menyala.ru и на биржу wm.exchanger.ru. В обоих случаях интерфейс merchant webmoney выдавал мне сообщение о недостаче средств на R-кошельке, хотя на вкладке "Кошельки" в кипере я видел что деньги есть. Затем я пытался перевести деньги кипером на другой кошелек, но и в этом случае в форме перевода я видел остаток на счету в размере 42,86 WMR, хотя опять таки на вкладке "Кошельки" я видел что есть вся сумма, т.е. чуть больше 15000 WMR. После нескольких дней попыток вывести эти деньги, я 15.12.2008 обратился с этой проблемой в службу поддержки системы webmoney по email: support@webmoney.com, что они в последствии мне подтвердили по телефону. Они начали спрашивать меня сначала о сумме перевода, затем о тех сервисах которыми я пользовался, просили сделать пошаговые скриншоты (не совсем понятно чего, работы merchant - интерфейса, кипера, или всего подряд вобщем по сути проблемы мне не помогли, а с 16.12.2008 я несколько дней не находился в сети, поэтому не мог с ними продолжать выяснять подробности. За время моего отсутствия мне было сделано 2 перевода на Z-кошелек в размере 500 и 150 WMZ, которые я увидел у себя в кошельке 20.12.2008 и эти деньги были видны мне на вкладке "Кошельки" вместе с суммой 15067 WMR
на R-кошельке. Затем 20.12.2008 после нескольких часов работы, мой кипер потерял соединение, и до конца дня я так и не смог его восстановить. 21.12.2008 я также не смог подключиться своим кипером, и пошел на другую машину. Оттуда я подключился без проблем и увидел, что что ни на R-кошельке, ни на Z-кошельке нет тех сумм которые я получал накануне. Причем в истории операций по Z-кошельку я обнаружил что сумма в 660 WMZ была несанкционированно переведена с моего кошелька на неизвестный мне кошелек причем через 3 минуты после зачисления 650 WMZ на мой кошелек 20.12.2008.
В истории же операций по R-кошельку никакого расхода средств не числилось.

После этого 21.12.2008 я смог подключиться кипером уже на своей машине, где в истории операций по R-кошельку обнаружил несанкционированную передачу 14900 WMR на неизвестный кошелек причем дата перевода 11.12.2008, т.е. через 2 дня после получения указанных выше 15000 WMR.

Неясным остается момент, что "показывал кипер" вплоть до 20.12.2008 на R-кошельке (сумма все время была видна 15067 WMR) и почему с 9.12.2008 по 11.12.2008 (день насанкционированной передачи средств) я так и не мог перевести средства со своего кошелька куда либо?

Также неясно что "показывал кипер" несколько часов 20.12.2008 после зачисления 650 WMZ на Z-кошелек, если по истории операций видно, что деньги несанкционированно были переведены через 3 минуты после получения?

Причем в обоих случаях суммы несанкционированных передач соответствовали именно приходу, т.е. на сегодняшний день средств на кошельках осталось практически столько же, сколько было до этих инциндентов.

Также замечу, что после этих событий, т.е. со второй половины дня 21.12.2008 и по сей день никаких проблем с подключением кипера у меня не наблюдается. Однако после вчерашнего моего обращения сначала в службу поддержки по телефону, затем по e-mail, и обращения в арбитраж по e-mail, сегодня
23.12.2008 я обнаружил что у меня обнулен показатель Бизнес уровень (BL), хотя еще вчера там было 42 пункта.

Кстати, ответ арбитража, сегодня, меня тоже "порадовал", т.е. все безусловно логично, но, увы, помощью заинтересованной стороны я бы это не назвал. Вобщем, мне написали, цитирую полностью:


"Здравствуйте!

Возможны два варианта: либо кто-то получил доступ к Вашему кошельку, либо у Вас на компьютере троян.
В первом случае рекомендуем Вам сменить ключи и все пароли, которые используются для доступа к wmid, а также установить блокировку по IP. Если Вы
используете Light-версию, то обратитесь к суппорту с тем, чтобы при создании нового сертификата старый был отозван.
Если Вы не имеете доступа к wmid, то Вам следует проходить стандартную процедуру восстановления доступа -
http://webmoney.ru/rus/about/demo/help/classic/resp1_02_key_lose.shtml
Для того чтобы найти вирус-Троян на вашем компьютере, Вы можете поступить следующим образом, см. http://virusinfo.info/showthread.php?t=1235
Кроме того, рекомендуется внимательно ознакомиться с содержанием https://security.webmoney.ru/asp/default.asp и сайта http://owebmoney.ru"

Однако, это совсем не дает ответов на мои вопросы. Кстати сказать, я направил в арбитраж повторное обращение, в котором еще детальнее описал ситуацию. Интересно, какова будет следующая реакция

Подведу промежуточный итог.


1. Мне кажется, довольно интересное, я бы сказал странное поведение для вредоносной программы. Вопрос в том зачем такие сложности? Зачем воровать деньги с R-кошелька через 2 суток после их получения, а потом в течение еще 10 дней показывать что деньги в кошельке есть? Зачем ей (вредоносной программе) блокировать передачу средств с 9 по 11.12.2008, вместо того чтобы просто их перевести на "левый" кошелек? Зачем, опять таки показывать что средства на Z-кошельке есть? Зачем "выкидывать" кипер из сети, при этом не блокируя доступ в принципе, и не обнуляя, например, файл ключей, что происходит при работе обычных троянов, о которых я читал? Зачем теперь, после факта воровства, доступ кипера в сеть разблокирован, и все работает нормально? Неясно также зачем был обнулен мой показатель Бизнес уровня (BL), он то тут вообще причем?

2. Также мне интересна реакция арбитража и службы поддержки, которую, как я и говорил, не назвал бы заинтересованной. Я читал, о том что они в этом случае блокируют кошельки получателей, проверяют куда пошли деньги дальше и вообще предпринимают какие то действия, кроме простой отписки, о рекомендациях по безопасности. В любом случае я повторно направил запрос в арбитраж, так что ждемс...... Служба поддержки, кстати, начала "шевелиться" и прислала мне запрос, чтобы я и им (не только арбитражу) указал не какие кошельки "ушли" деньги, но почему то только после того как
я вчера около 40 минут беседовал с их специалистом по телефону, и который все таки поднял логи моих e-mail обращений за 15.12.2008

Вобщем, вот моя история, которая еще продолжается. Надеюсь кому-то она окажется полезной.

А теперь небольшое отступление, вобщем тоже в тему Как говорил классик: что наша жизнь - игра. А игра - это азарт. Любителям азартных игр понравится игра покер бесплатно

Итак, ситуация:

На сайте данные из базы данных отображаются нормально, а поиск выдает "фантастические" результаты.

К примеру недавно на одном из сайтов, которые пришлось дорабатывать, по запросу "москва" выдалась кроме всего прочего книжка: "Программирование на С++", при том что поиск работал по наименованию. Вот и пришлось ломать голову как синтаксически связано слово "москва" и "программирование на С++". Не-то MySQL оказался настолько умным и понял что в москве много хороших С++ программистов и им нужно обязательно предложить эту книгу, то ли "почувствовал", что у книги издательство московское, но факт остается фактом, это был результат поиска, который не определялся вхождением искомой фразы в значение поля, по которому он производился.

А теперь собственно, к тому что же на самом деле произошло. Конечно никакого семантического прогнозирования MySQL не делает (не для этого он предназначен проблема оказалась именно в кодировках.

Немного теории:

Скажем так, MySQL может работать на разных этапах обработки данных, в разных кодировках, при этом преобразования он выполняет "на лету". В том числе эти "этапы" и соответствующие им кодировки характеризуются следующими переменными MySQL:

• character_set_client - кодировка в которой данные будут поступать от клиента

• character_set_connection - кодировка по умолчанию для всего, что в рамках соединения не имеет кодировки
• character_set_database - кодировка по умолчанию для баз
• character_set_filesystem - кодировка для работы с файловой системой (LOAD DATA INFILE, SELECT ... INTO OUTFILE, и т.д.)
• character_set_results - кодировка, в которой будет выбран результат
• character_set_server - кодировка, в которой работает сервер
• character_set_system - кодировка, в которой задаются идентификаторы MySQL, всегда UTF8
• character_sets_dir - папка с кодировками

Наиболее значимые для нас следующие переменные: character_set_client, character_set_results, character_set_connection именно они отвечают за внесение , извлечение информации и создание таблиц / баз соответственно.

Все эти переменные определяют дефолтные значения, т.е. если в дампе не указаны кодировки, то используются эти. Есть 3 способа изменить дефолтные значения:

1. Используя SET names
2. Непосредственно меняя каждую из этих переменных через SET character_set_*
3. Через настройки самого сервера

следует обратить внимание что первые два варианта работают только в рамках текущего соединения. Это значит, что при следующем подключении все настройки вернуться в начальное состояние.

Просмотреть возможные значения этих переменных можно так SHOW CHARACTER SET

Для русскоязычных сайтов наиболее приемлимы варианты: cp1251 и utf8

Для реализации третьего варианта установок нужно:

а) править файл my.cnf (конфиг. MySQL):

[client]
# Для местного клиента
default-character-set=cp1251
....

[mysqld]
# Для всего сервера
default-character-set=cp1251
....

б) через командную строку:
shell> mysqld --character-set-server=cp1251

в) задать при конфигурировании из командной строки
shell> ./configure --with-charset=latin1

Теперь о том что же на самом деле случилось и как это "лечить". А произошло я полагаю следующее: по дефолту на сервере выставлена кодировка latin1, данные когда заливали дамп фактически были в windows-1251, MySQL заливая данные перекодировал их на лету, в результате получилась "каша". Как это лечить:

1. Создать бекап базы данных.
2. Создать текстовый дамп базы данных в SQL запросах с помощью mysqldump, PHPMyAdmin, Sypex Dumper или другими средствами
3. С помощью текстового редактора удалить всю информацию о кодировке в запросах на создание таблиц, и кодировку полей.
4. При необходимости, если кириллические символы в значениях полей в дампе нечитабильны (это мой вариант), раскодировать файл с помощью сторонних программ, т.е. привести в читабильный вид кириллические символы.
5. Удалить таблицу / базу
6. Выставить нужную кодировку character_set_client,character_set_connection
7. Импортировать исправленный SQL-дамп базы.

Вобщем после вышеприведенных манипуляций, все стало на место и поиск стал выдавать правильные результаты.

P.S. А книжка по С++, кстати хорошая была :)))

1. «Клинское» тоже можно пить, в общем.

2. Сигареты «Петр 1» содержат больше никотина, чем ваш любимый «Кент».

3. Туалетная бумага «54 метра» дешевле ZEWA в 10 раз, а хватает ее на дольше.

4. Если хлеб черный натереть чесноком, он пахнет колбасой.

5. На рынке все просите попробовать, но не покупайте. Экономия средств и обед в одном флаконе.

6. Покупать холодный чай — это дурость. Налейте заварки в бутылку и пейте себе.

7. Завтрак «кризис»: морозим сосиcку, трем на терке, мажем хлеб майонезом и посыпаем тертой сосиской. Вкусно и практично, а главное много, одной сосиски хватает на 5—10 бутербродов.


8. В парках и лесопарках бабушки и молодые мамаши кормят уток и лебедей хлебом. Если не удастся выпросить у них кусок для себя, можно прыгнуть в воду и побороться.

9. Вместо суши можно прекрасно налепить колобков из риса с куском крабовой палочки и огурца внутри, 1 пачки палочек хватает на 20 порций роллов «Калифорния».

10. Вообще-то пейджеры еще работают.

11. Если вино разбавить пополам водой из-под крана, то вкус даже улучшится.

12. «Ролексы» свои все — в ломбард. Часы и на мобильнике есть!

13. Купите калоши! Этим вы сэкономите на зимней обуви и не потеряете вашего менеджерского вида.

14. Чай можно заваривать семь раз. На восьмой чаинки всплывают, чтобы посмотреть на этого жлоба.

1. Sloger

Одна из самых туссовочных социальных веб-мастерских сетей. Принцип действия - аналогичен предыдущим. Кроме всего этого - там предлагается размещать баннерки, рекламу (кроме сабмита).



То что сеть самая туссовочная влечет и некоторые проблемы - сложнее пробиться в лидеры и им остаться.

И еще иногда бывают глюки при сабмите. Вводишь URL - а оно пишет. что нельзя. ну нельзя и ВСЕ. У меня так долго было с одним из блогов (он автономный, чтоб не было вопросов лишних). Через какое-то время необъяснимым образом отпустило. И слава богу.

2. Korica

Тоже все простенько. Жмем кнопку "Отправить пост", вводим URL, название, описание и выбираем рубрику: блоги, конверт, прочее, софт, adult, SEO, SMO. И все )


3. Showblogs

Достаточно молодая социалка. Можно голосовать за свою же новость (правда. всего 1 раз, но все-равно приятно. Основные категории: SEO/SMO, Блосфера, Интервью, Софт, Конкурсы, программирование, разное, интернет.

Вот такой вот списочек. действуйте - злодействуйте.

Самые сильные "игроки" - первая четверка. Но не всегда именно с них идет самый большой трафик. Да и вообще ждите трафика если статья у вас действительно нужная и вы сумели как следует ее подать - придумав нужный заголовок и завлекательное описание.

Для тех, кто интересуется социалками подробно, рекомендую:

Список русских социалок

Желаю успеха!