IHHI-Blog

36717 пунктов

IHHI — Thu, 28 Jan 2010 23:43:08 GMT

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

Напоминаю, что оперативная информация о публикации IHHIndex доступна в Twitter и RSS - регистрируйтесь и следите.

Предыдущая статья серии со ссылками находится здесь

Удачи.

Итого: 36717(+1177)

35540 пунктов - прошлый выпуск IHHIndex

IHHI — Thu, 28 Jan 2010 19:40:25 GMT

На прошлой неделе я забыл про выпуск IHHIndex. Сам не пойму как. Скорее всего замотался с выпуском подкаста "Radio-coworking". Для полного новичка в звуке это было очень непросто. Но жутко интересно. Пока возвращаю должок, а затем выпущу сегодняшний и пойду делать новый подкаст. Если среди моих читателей есть специалисты по записи в формате подкастов - откликнитесь. Есть несколько вопросов.

Напоминаю, что оперативная информация о публикации IHHIndex доступна в Twitter и RSS - регистрируйтесь и следите.

Предыдущая статья серии со ссылками находится здесь

Удачи.

Итого: 35540(+139)

35401 пункт - заканчивается марафон новых годов

IHHI — Fri, 15 Jan 2010 00:57:49 GMT

4-й выпуск подряд я вынужден объявлять, что выпуск IHHIndex пришёлся на очередной новогодний праздник. На этот раз - Старый Новый Год. Самый непонятный миру и очень уютный обычай. Каждый год в этот день я достаю старую записную книжку, нахожу в ней человека, которому ни разу не звонил за прошедший год и звоню. А у вас есть традиции, связанные со старым Новым Годом?

Напоминаю, что оперативная информация о публикации IHHIndex доступна в Twitter и RSS - регистрируйтесь и следите.

Предыдущая статья серии со ссылками находится здесь

Удачи.

Итого: 35401(+885)

Кому-нибудь нужен хостинг и антивирус по цене хостинга?

IHHI — Thu, 14 Jan 2010 01:15:21 GMT

Не собирался сегодня ничего писать в блоге, но пришла рассылка от провайдера со специальным предложением. Я подумал, подумал, да и решил предложить тоже самое моим читателям. Если кратко, то каждому оплатившему хостинг на один год по любому тарифному плану (Year, Optimo, Century, Millennium или Eterno[B]) полагается бонус: годовая лицензия на антивирус Dr.Web (включая Dr.Web для Windows Mobile). Провайдер, разумеется - TimeWeb. Думайте, не тяните - акция действует до 31 января и распространяется на вновь зарегистрированные аккаунты.

Sypex Dumper - храни наши базы MySQL [4]

IHHI — Tue, 12 Jan 2010 19:36:56 GMT

Я считаю, что самый распространённый инструмент для работы с базами данных MySQL - PHPMyAdmin - является ещё и самым непригодным. Чем заменить его при администрировании баз данных я расскажу в одной из следующих статей, а сейчас, продолжим осознание процесса самосохранения. Я остановился на том, что данный процесс должен быть автоматизирован и контролируем. Т.е. создание резервных копий должно производиться без непосредственного участия человека, но не бесконтрольно.

Скриптом Sypex Dumper я пользовался с версии 1.0.8 и был очень доволен: простая установка и минимальная настройка позволяли сделать за доли секунды резервную копию базы данных и упаковать её в архив. После этого загрузка базы на локальный компьютер становилась делом нажатия одной кнопки. При этом можно было настроить скрипт так, чтобы для каждого сайта, расположенного у одного провайдера, можно было делать отдельный архив из одной установки. И я даже не думал о необходимости апгредиться до 2-й версии - от добра добра не ищут. Ситуация изменилась, когда увеличилось число сайтов, на которых размещалась важная или уникальная информация. Пришло время автоматизации. В поисках решения я покопался в сети и обнаружил, что проверенный боями скрипт в версии 2.0.5 поддерживает работу из командной строки. Это значит, что можно запускать команду сохранения базы по графику с помощью утилиты cron. А далее файлы автоматически собирать со всех серверов, или отправлять от хостера по e-mail по тому же расписанию.

Сейчас у меня свет выключили и я не могу проверить всех своих провайдеров на предмет наличия возможности составления расписания (cron), но рассмотренная вчера пятёрка (.masterhost, ТаймВэб, BeGet.ru, Домишко, LavaHost) эту функцию обеспечивает. Думаю, что большинство тарифных планов у других провайдеров тоже содержит это пункт. Если же нет, то и это не страшно: всегда можно придумать решение в стиле "после публикации очередной статьи запустить процесс ___". Поставьте в нужное место правильную команду и всё заработает. Как эта команда выглядит - чуть позднее. А пока - процесс настройки и установки на Денвере - батареи ноутбука хватит ещё на час-другой.

Установка скрипта проста. Вот как она описана на сайте:

Разархивировать и закачать содержимое каталога на сервер.
Установить chmod 777 для каталога backup.
Установить chmod 666 для файлов cfg.php и ses.php.

К этому я хочу добавить: разархивировать содержимое архива, Dumper 2.0.5 Beta можно в любое место на сайте, которое будет "видно" по сети. Рекомендую заменить используемую по умолчанию директорию sxd на что-нибудь своё. Дело в том, что у некоторых провайдеров аккаунты для доступа к базе данных можно вычислить, а зная имя и имея доступ к интерфейсу описываемой программы... Вы ведь не используете один и тот же пароль для аккаунта в социальных сетях и к базам данных?

Для демонстрации я развернул на Денвере копию сайта SEO опыты - Textpattern и скопировал Sypex Dumper в корень, в директорию backuper.

backuper                                      Folder
css                                           Folder
files                                         Folder
images                                        Folder
rpc                                           Folder
sites                                         Folder
textpattern                                   Folder
.htaccess                                        531
css.php                                          574
index.php                                       1195
robots.txt                                        26

Далее, если установка идёт на Unix-сервере, нужно выполнить три пункта из инструкции выше. Под Windows - нет. Теперь открываю в браузере http://ih6.dev/backuper и получаю приглашение ввести логин и пароль для доступа к базе данных. Это тот же набор, что указывался CMS при её установке. Запоминать ли введённые данные - решать вам. Здесь же можно выбрать язык - скрипт сразу включает в себя возможность работать на русском, английском и украинском языках. Если этого мало - на сайте программы можно скачать ещё несколько вариантов локализации, или предложить свой. После нажатия кнопки "Войти", программа сохранит введённые данные и готова к работе.

Можно выбрать базу данных, кодовую страницу для соединения (рекомендую ту же, что и CMS - в моём случае это utf8 ), степень компрессии, пару слов для памяти и указание, сколько дней и сколько файлов хранить. Ну и сохраняемые таблицы, разумеется - при правильной настройке CMS могут уживаться в одной базе данных и не мешать друг другу.

Всё настроили? Жмём "Сохранить" и вводим название данной конфигурации - в соответствии с ней будет производиться резервирование данных.

Имя запомните - оно пригодится для автоматизации. Теперь нажмите на кнопку "Выполнить" - запустится процесс создания резервной копии.

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

Ну и завершающее действие этапа настройки - проверка работоспособности созданной резервной копии. Лучший способ - создать сайт-двойник и для него произвести тестовое восстановление. Мой подопытный - именно такой двойник. Поэтому я просто удалил базу данных в предыдущем экране выбрал созданный backup и нажал кнопку "Открыть" - после этого попал на страницу импорта базы данных.

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

Импорт базы данных занял немного больше времени - 3 секунды. Запуск сайта после восстановления показал, что всё работает нормально. Теперь я имею настроенный инструмент для загрузки на сайт-дубль копии рабочего сайта. Осталось проверить, как работает создание резервной копии из командной строки.

Sypex Dumper начиная с версии 2.0.5 поддерживает работу из командной строки (консоли/крона) - помните эту фразу. Формируем команду, которая освободит нас от рутины. Для этого нужно знать путь к интерпретатору PHP и путь к папке с Sypex Dumper. В Unix системах, это может быть /usr/bin/php. Если нет - пытайте документацию, провайдера и phpinfo(). На Денвере путь - z:\usr\sbin\php5. И вторая часть команды - путь к скрипту Sypex Dumper. У меня это Z:\home\ih6.dev\www\backuper\index.php. Всё, можно настраивать cron - задать время и частоту запуска. А в качестве команды - комбинацию из пути к интерпретатору, скрипту и ключ j с указанием имени сохранённой конфигурации. У меня она выглядит вот так:

z:\usr\sbin\php5 Z:\home\ih6.dev\www\backuper\index.php -j=cron-backup

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

Теперь резервные копии базы данных будут создаваться регулярно, если регулярно выполнять описанную выше команду, а их число и срок годности будет отслеживаться автоматически. А я буду готовить статьи о том, как запускать резервирование без вмешательства человека и автоматически сохранять эти файлы на другом компьютере. Мы защитились от краха базы данных, но если накроется жёсткий диск сервера или весь дата-центр, то вместе с ними канут и наши резервные копии. Но не нужно бояться, что это всё сложно - я уложился с настройкой минут за 50. Если посмотреть на время создания бекапов, то видна разница в их создании - 36 минут. А ведь я ещё писал статью и делал скриншоты. То же самое будет и с копированием. До следующей статьи.

Резервное копиование базы данных MySQL [1]

IHHI — Tue, 12 Jan 2010 01:03:47 GMT

Печальную историю МК помните? Не хотите, чтобы это повторилось с вами? ~~Предохраняйтесь.~~ Сохраняйтесь. Что делать с файлами, знают все - их нужно просто периодически копировать в надёжное место. Но современные сайты в 9 случаях из 10 используют базу данных. Остальной 1 случай готовится её использовать. И вот с этим элементом всё немного сложнее. Разберёмся с MySQL - а именно эта система управления базами данных (СУБД/DBMS) используется на простых сайтах, блогах и т.п.

Практически каждый, кто слышал про MySQL, слышал и про phpMyAdmin - веб-приложение, которое позволяет произвести ряд манипуляций с базой данных и, при необходимости, сделать копию самой базы. Овладев этими знаниями, владельцы сайтов успокаиваются: не ищут иных знаний и не делают резервных копий. Признаюсь честно: я тоже не делаю. Есть люди, которые могут ежедневно запускать браузер, заходить в нужные места и делать правильные действия. Я не из их числа. Для однообразных и повторяющихся действий нужно использовать компьютеры и соответствующее ПО. И второй минус phpMyAdmin - ограничение на размер импортируемой базы данных. Конкретная цифра зависит от настроек провайдера. Вот данные по провайдерам по состоянию на дату выхода статьи (часть ссылок - реферальные):

.masterhost - 32mb
ТаймВэб - 40mb
BeGet.ru - 999mb
Домишко - 50mb
LavaHost - 32mb

Много это или мало? Для примера: размер базы данных этого блога, созданных сборок ("Край земли", "Валентинка", IHHI-X) и данных IHHIndex составляет (!) 140 мегабайт. Наверное 80% занимают логи, но почему я должен отказываться от них? Там огромное количество IP спамеров, поисковых и других роботов, которыми я собираюсь воспользоваться. Т.е. только один провайдер позволит сделать backup и последующее восстановление из него без дополнительных шагов. И если припрёт, я соображу, как перепрыгнуть пропасть тройным прыжком, но ведь должны быть способы лучше.

А теперь представьте себе увлекательный процесс перегонки веб-странички размером в 140 мегабайт от провайдера к себе и обратный процесс? Если эта перспектива не вызвала внутреннего отторжения, то составьте расписание создания резервных копий и неуклонно следуйте ему. Всех, кого перспектива ручного резервного копирования блога (а может блогов?) не радует, жду здесь завтра - проведу мастер-класс по облегчению собственной участи.

Но данные сохраните прямо сейчас ;). Любым способом. И самое главное - проверьте, можно ли из полученной копии восстановиться. История знает массу случаев, когда многолетнее резервное копирование на поверку оказывалось пшиком и накопленные данные были непригодны для восстановления.

34516 пунктов - Новый Год. Даже для блога.

IHHI — Fri, 08 Jan 2010 02:00:44 GMT

Время идёт, а праздники не кончаются. Рождественский выпуск IHHIndex - он же первый выпуск в этом, 2010 году. И ещё мне напомнили, что пару дней назад стартовал этот блог. Если за всё пить, то не выдержит, ни организм, ни кошелёк.

Поэтому буду краток: 21 статья, +263 пункта, 12,52 пункта на одну статью. Общее значение по IHHIndex - 20,64. Зачем и пишу эти цифры, что они значат и будут ли другие - на все эти вопросы я отвечу в конце января - к этому времени я перенесу блог на новый хостинг, на котором сейчас собирается отдельный сайт для IHHIndex. Новый сайт будет аккумулировать цифровые статьи, но сбор, обработка и отображение статей, статистики и прочая информация будет выдаваться абсолютно иным способом. Наберитесь терпения.

Напоминаю, что оперативная информация о публикации IHHIndex доступна в Twitter и RSS - регистрируйтесь и следите.

Предыдущая статья серии со ссылками находится здесь

Удачи.

Итого: 34516(+263)

34253 пункта к концу 2009 года

IHHI — Fri, 01 Jan 2010 22:37:29 GMT

Вот и новогодний выпуск IHHIndex - он как бы подводит итоги 2009 года, т.к. данные обсчитываются по четвергу. Следующий выпуск будет содержать статьи, добавленные начиная с 1 января 2010 года. Признаюсь честно: никаких особых рубежей для него не намечалось. И в дальнейшем не планируется. Я вообще был удивлён, что собрал 28 статей, из которых 22 было написано в последнюю предновогоднюю неделю. Герои.

Тем временем обещанный в прошлой статье эксперимент сдвинулся с мёртвой точки: оба блога запущены. Правда слегка изменились условия его проведения - блоги будут развиваться параллельно, но с учётом особенностей каждой из CMS. И каждый из них будет подвержен дополнительной переделке: сначала я сделаю шаблон для блога на Textpattern, а затем перенесу этот шаблон на WordPress блог. Выбранный изначально шаблон, помимо необходимости ссылаться на автора, подразумевает наличие в блогролле нескольких ссылок на ненужные мне ресурсы.

Напоминаю, что оперативная информация о публикации IHHIndex доступна в Twitter и RSS - регистрируйтесь и следите.

Предыдущая статья серии со ссылками находится здесь

Удачи.

Итого: 34253(+339)

33914 пунктов - знакомьтесь с участниками эксперимента

IHHI — Fri, 25 Dec 2009 01:28:07 GMT

Сегодняшний выпуск IHHIndex - "ихнерождественский". Поздравляю тех, кто празднует не за компанию, а по делу. В связи с этим не только не предъявляю никаких претензий по поводу значений этого выпуска индекса - +281/26/10.81, но и не возлагаю особых надежд на следующий, который должен публиковаться в ночь с 31-го на 1-е. Практически уверен, что график будет сорван.

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

SEO-опыты - сайт на TxP 4.20, на котором я НЕ собираюсь следовать чьим-либо советам;
SEO по инструкции - сайт на WP 2.9, чьё развитие будет происходить в соответствии с собранными в IHHIndex статьями.

Сайты я разместил на каком-то недорогом хостинге. Теперь подберу соответствующий шаблон, в который и "одену" соревнующихся. Если есть какие-нибудь предложения - пишите. Рассмотрю.

Напоминаю, что оперативная информация о публикации IHHIndex доступна в Twitter и RSS - регистрируйтесь и следите.

Предыдущая статья серии со ссылками находится здесь

Удачи.

Итого: 33914(+281)

Четвёртый вебинар Бегуна

IHHI — Tue, 22 Dec 2009 19:54:54 GMT

17 декабря компания Бегун провела заключительный в 2009 году Вебинар для специалистов рекламных агенств и партнёров.

С докладами от компании Бегун выступили Евгений Рыжов и Виктория Алиева, а так же Денис Кучумов — приглашённый специалист.

Программа вебинара:

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

Евгений Рыжов уделил внимание реалиям сегодняшнего времени, разобрал пример составления успешной рекламной компании при ограниченном бюджете у рекламодателя. Задача была сформулирована следующим образом: как сделать переходы по объявлению клиента, не используя ключевые слова - "высокочастотники".

Виктория Алиева рассказывала и показывала на конкретных примерах, как не надо делать рекламные банеры.

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

В заключении вебинара прозвучало объявление о продолжении бесплатных закрытых вебинаров для специалистов компании Бегун в январе 2010 года. По решению компании, материалы прошедших 4-х вебинаров не будут публиковаться для широкой аудитории.

Напоминаю, что рекламодатели, зарегистрировавшиеся по моей партнёрской ссылке получат бесплатные консультации и помощь в проведении рекламных кампаний. Кроме того - 500 рублей на счёт для проведения пробной рекламной кампании.