Urth’s Freehold

Делая почтовые рассылки, не забывайте:

1) Прописывать from и return-path.
Ваш SMTP (MTA) должен возвращать недоставленные письма на этот адрес. С пояснением о причине недоставки. Лучше вычищать кучу недоставленных писем из ящика, чем иметь жалобы клиентов. Адрес должен существовать, поскольку некоторые сервера проверяют его работоспособность.
При отправке через PHP mail(), адрес from указывается через дополнительный параметр -f sendmail.

2) Следить за заголовками писем.
Фильтры (SpamAssassin в частности) не любят поддельных X-Mailer. На баллы SpamAssassin влияют Message-ID и boundary, поскольку как правило они зависят от почтового клиента. Компоненты Indy (Delphi), к примеру, имеют boundary давно занесенный в черные списки.
А X-Powered-By с PHP - не лучшая строка в headers ваших писем.

3) Не стоит делать рассылку одновременно большому количеству адресатов на одном хосте (например, пару тысяч писем на mail.ru за один заход)

(more…)

Сделал себе RSS-канал новой музыки что выкладывает в локальный доступ провайдер. Дабы не караулить новинки на сайте. Со списком url’ов, чтоб сразу в качалку.

Конверсия парсера. Нефиг ему пылиться.

Будет интересно только клиентам Оптимы:

• RSS канал optima-mp3.alkar.net-new
• Получать на свой e-mail

На днях увлеченно вспоминал опыт годичной давности по парсингу сайтов разработке информационных баз в сети Интернет. В общем пиратствовал.

На этот раз все прошло существенно быстрее и комфортнее.

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

Набор включает:
1. Человека с прямыми руками и со знанием PHP и регулярных выражений.
2. Сервер или локальную машина с апачем+пхп+mysql, подключенную к безлимитному каналу.
3. Скрипт загрузки индекса необходимых страниц и скрипт загрузки самих страниц.
4. Парсер, вытаскивающий нужные данные из выкачанной кучи мусора.
5. Красивый шаблон для оформления результатов. Excel, xml, csv или html.
6. Ну и какой же пират, без попугая-матершинника и черной повязки на глаз.

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

При загрузке данных все решается просто - через curl. Пока админы пьют пиво - качаем все в один поток, с одного IP, без refferer, с простым User agent. А пока они допьют - все ихнее золотишко уже у нас. Хе-хе.

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

Самое трудоемкое во всем этом - написать регулярное выражение и исправить в нем все ошибки. Дальше - дело техники.

И… соблюдайте копирайт! :)

Созданный прежде RSS поток начал транслировать на открытые платформы.

Уже при эксплуатации потока появилось неожиданное ограничение. Информации на вход RSS-потока подается больше, чем тот может экспортировать. Экспорт выставлен в 30 записей (кто сказал, что робот не может подавиться?) и 6 часов обновления. Поначалу казалось этого будет хватать с запасом. Но специфика подаваемой информации оказалась таковой, что несколько дней ее может не быть вообще, а потом создается сразу пол сотни записей.

Поэтому придется в скрипт добавлять отложенную публикацию, публикуя посты с задержкой для роботов. Ну и для приличия. Ведь 50 постов за 2 секунды, а потом трое суток молчания - это как-то… ненормально.
Лучше реже, но регулярно ;)

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

И как оказалось, удобных открытых платформ для трансляции, вроде beta.ya.ru, можно пересчитать на пальцах. Но это уже другая история.

P.S. Да, да, проще купить ссылок на сапе :)

…красота кода и структуры - разговор отдельный.

С одной стороны красота это по большей части ООП-шные рюшечки с тоннами формальных деклараций и тормозящий код.

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

И компромисс - где-то посередине. И поиск его - весьма мучительное занятие.

RSS-канал (фида, лента, эрэсэс - нужное подчеркнуть) - создана, запущена в автоматическом режиме и опубликована.

Хотя у меня до сих пор недуомение по поводу необходимости замены html specialchars (&,>,<,’,”)  самих html tags внутри xml. Модуль работает с стандартным пространством имен RSS 2.0 плюс dc. Намеренно пропустил разве что проработку атрибутов enclosure, это пока незачем. Валидатор светит зеленым и это хорошо.

Есть большая надежда в то что лента повлияет на оперативность включения новых страниц. Во всяком случае в самых ближайших планах - google sitemap. Хотя кто придумал так называть список страниц сайта? Это определенно siteindex, а не sitemap. Поскольку карта на то и карта, что должна содержать структуру. В данном случае - сайта. Ведь в простейшем случае все эти sitemap’s - только список страниц тупому роботу, который почему-то кладет на под полку большую часть страниц.

С точки зрения движка, создание карты индекса сайта это а) один простой SELECT и форматированый фильтрованый вывод в XML и б) опрос модулей о их виртуальных страницах, что уже на порядок сложнее. И сложнее не столько в техническом плане, сколько в организационном. Код и структура - должны быть красивыми.

Но красота кода и структуры - разговор отдельный…

Гугл практически перестал есть новые страницы сайта. Терзают смутные сомнения. Делаю rss ленту новых страниц. На очереди sitemap.

Кстати о RSS. Два года назад разбирался в формате (2.0) и написал модуль для создания. Тогда тема не особо пригодилась, хотя все еще используется. Вечер доработки и модуль с админкой встали под новый движок. От кошерного RSS с юникодом отказался ввиду возни с перекодировкой. Сейчас остро стоит вопрос времени.

“Изменились” приоритеты развития. Теперь в спешном порядке подключаю магазин к порталам. Для начала bigmir.net, на очереди объявления в ПС. С рекламой в ПС - идея плохая, но пока рекламный бюджет не откусил кусок больше прибыли - идея хорошая.

По мере работы копирайтер(ов) появляются факты плагиата и случаи успешной борьбы с ними. Пока что несистематической. Но об этом я еще напишу пост. А пока - вкалывать! :)

Проводя поиски истины о SEO-значении атрибута title у изображений и ссылок, наткнулся на одну старую статейку - “Растолкованный Pagerank” в переводе А. Садовского. Статейка припала толстым слоем пыли, а перевод скажем так не блистает качеством. (Старая моя учительница английского назвала бы это калькой. Поэтому переводчику ни малейшего спасибо) Так вот статья написана в стиле “for dummies”, тем не менее, простота эта оказалась полезна для формализации моего понимания способов перераспределения PR.

Рекомендую, классика.

В тот же день, под впечатлением, слегка доработал движок, добавив возможность ссылкам меню иметь атрибут rel=nofollow. И соответственно еще больше перераспределил PR на страницах сайта. Ранее же это делалось вручную. Теперь можно выставить nofollow для сквозных ссылок на страницы вроде “О нас”, “Контакты”, разных справочных страниц и pdf-/xls- прайсов. Только не забыть оставить пару индексируемых ссылок на такие страницы.

Всегда, выстраивая логику из трех переменных, вспоминаю своего преподавателя физики. Помню, любил при случае поговаривать, мол с двумя величинами в задачках разбираемся, а в трех березах - заблудились. И по-доброму так посмеивался. :)

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