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

Почему не сделать бота, который чистит почту, тем более спам четко виден по некоторым признакам?
Вот что я выделил, что в моих глазах спам:
— всё написано в верхнем регистре
— сообщения, где главная мысль: порнуха, знакомства, казино, деньги и т.д.
— если кто-то регулярно высылает почту и я её не прочитываю

Жил-был в составе поиска по блогам Яндекса рейтинг популярных записей, который для многих был такой себе ежедневной газеткой. Но решили в Яндексе его закрыть да предоставили API, чтобы каждый желающий мог сделать свой рейтинг популярных записей по блогам, чем мы собственно сегодня и займемся. Писать будем на PHP.

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

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

За последнее время мне пришлось активно работать с сайтами, которые большие объемы информации хранят в файловой системе. Это разнообразные сайты фото и файловых хостингов, а также сайты с загрузкой видео контента, некоторые сайты проектировались и программировались мной с нуля, некоторые переписывались, дописывались или «приводились в порядок».
Должен отметить, что хранение файлов в файловой системе является для многих программистов областью, которая проходит мимо их внимания.

1. Введение.

Что из себя представляет эта статья.

Данная статья является простым введением в использование шаблонов Smarty с классами PEAR HTML_QuickForm. Статья не является исчерпывающим руководством, и фактически представляет лишь малую часть функциональности шаблонов Smarty. Однако для новичка в использовании шаблонов Smarty данная статья будет полезной базой.

Задача — сделать на PHP эвенты а-ля C# т.е. произвольный объект может генерировать события. Другие объекты могут на эти события подписываться непосредственно у экземпляра генерирующего объекта.

Основное отличие от того что видел ранее — строгая проверка навешиваемого хука. Проверяется наличие метода, количество его аргументов, etc…

Навеяно практически одноименным постом

Я вспомнил как однажды решал указанную проблему. Мой способ очень похож но имеет несколько дополнительных плюсов… и минусов )))

Плюсы:
— Картинки генерятся только когда они нужны (т.е. мы не храним ненужных изображений и не нагружаем сервер в случае массовой загрузки изображений)
— PHP работат только первый раз (когда картинка нужного размера еще не существует)
— Размеры нужного изображения фигурируют только на стороне шаблона, т.е. грубо говоря в html

На хабре уже были топики, посвященные открытому API для работы с сервисом ruTube. В примере, который можно скачать с сайта ruTube (http://rutube.ru/partners/phpapi.html), отправка ролика осуществляется следующим образом (код взят из примера без правок):

По следам хабратопика Наследование шаблонов в Smarty хочу рассказать как около полутора лет назад я решил подобную задачу. В оличие от marazmiki с Django я знаком не был (хотя сейчас занимаюсь изучением именно его). Но крайне поверхностно был знаком с механизмом Master Pages из ASP.NET. Механизм заключается в том, что у нас есть практически полноценная страница, у которой отсутствует только блок с основным контентом.

Немного прикинув придумалось решение через стандарные функции Smarty и механизм наследования в PHP.

 

Эта «небольшая» статейка является развитием темы затронутой в этой статье.
Как известно, PHP зародился довольно давно и уже тогда возник вопрос, что делать с возникающими ошибками. Perl, который является несомненным прародителем PHP по умолчанию не имел какой-либо системы обработки ошибок. При возникновении любой ошибки сервер выбрасывал 500-ю ошибку и на этом все заканчивалось. Поэтому Warnings, Fatal Errors и Notices были настоящим прорывом в облегчении и без того нелегкого труда программиста. Однако время шло, механизмы PHP не менялись, а технологии, как известно, на месте стоять не любят.

Предыстория

Решив запустить небольшой сервис на подаренном мне хостинге, оказалось, что там нету ни одного xml-парсера: ни SimpleXML, ни DOMXML, а только libxml и xml-rpc. Недолго думая, я решил написать свой. Мне требовался разбор не сложных rss-лент, поэтому хватило достаточно просто класса xml => array.^[1]

Но для интересной статьи этого было явно не достаточно, поэтому сейчас мы напишем свою замену для SimpleXML. А заодно пробежимся по многим интересным возможностям PHP 5.

Постановка задачи

Доступ к элементам у нас будет осуществляться как доступ к свойствам класса, например $xml->element, а доступ к атрибутам элемента, как к массиву, те $xml->element['attr'], также реализуем проверку на существование атрибута при помощи isset() и итерацию по элементам при помощи foreach. И так, начнем.

Возникла мысль сравнить два способа хранения абстрактных данных в виде строк, реализованных в PHP: старая добрая сериализация и относительно недавно поддерживающий в языке формат json.

Для сравнения небольшой скрипт генерирует массив из 1000 элементов, две трети элементов которого — строки, длинной 15 символов (напополам — только буквы и только цифры), а оставшаяся треть — массивы по 50 элементов (также — буквенные и цифровые элементы пополам).

Итог весьма неоднозначен, подробности во второй части.

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

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

Поискал ссылки поиском по хабру, не нашел.

Итак, прежде чем изобретать велосипед, у разработчика часто возникает необходимость посмотреть, какие же продукты уже были реализованы.
Кто-то начинает гуглить — что же, наверное, это правильно.

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

Итак, вот они:
www.hotscripts.com
www.planet-source-code.com
php.resourceindex.com
cgi.resourceindex.com
www.scripts.com/php-scripts
www.phpclasses.org
mymans.org/category/php

И так. Объясняю популярно. Ибо сам пока разобрался потратил ни 10 минут. Делаем на примере условного сайта "Travel".

• Движок CakePHP [cakephp/cake и cakephp/vendors] я перенёс(!) в /var/www/cake.core (/var/www у меня apache wwwroot) — то есть, этот движок будет использоваться для всех проектов и не будет меняться до следующей версии CakePHP.
• Содержимое cakephp/app/webroot переносим(!) в /var/www/travel (в этой папке у нас будут все css, images, js, uploads и т.д.)
• Всё из cakephp/app (там уже нет webroot, мы его прошлым шагом от туда перенесли) переносим(!) в /var/www/travel.app (там у нас будет вся логика и темплейты. MVC то есть).