Я не буду устраивать холивары по поводу — «на какой операционке (в качестве десктопа) должен работать PHP кодер». Я скажу честно, что уже запутался. Раньше работал исключительно на линуксе, теперь пришлось на винде (на работе так удобнее, так как много корпоративного софта именно под винду). У винды есть свои преимущества, например для разработчика много софта работает только под виндой, да и вообще с ПО у винды получше. Но сейчас не об этом.
В чем работать — проблема ваша, как вам удобно. Но вот, если у вас apache и PHP запущены на винде, то скажу вам совершенно уверенно — вы идиот. Так как девелоперский сервер однозначно должен работать под Unix подобными системами.
Хочу написать как можно комфортно работать PHP кодеру под виндой.
Устанавливаем виртуальную машину (любую), ставим туда ubuntu. Сеть настраиваем так чтобы машины видели друг друга.
Файлы проекта размещаем в виндовой папке. На нее натравливаем IDE. Расшариваем эту папку. И в fstab ее монтируем под пользователем апача. Вот так:

//10.1.10.28/server /var/server smbfs username=*****,password=*****,uid=33,gid=33,umask=000 0 0

Дальше настраиваем все и работаем.

В системе должен стоять пакет ImageMagick
В консоли делается так

$convert image.jpg -gravity SouthEast watermark.png -composite image.jpg

Из php соответственно так

exec('/usr/bin/convert '.$image_path.' -gravity SouthEast '.$watermark_path.' -composite '.$image_path)

Путь к бинарнику может отличатся в разных системах. В данном примере путь корректен для Linux. Для FreeBSD это будет /usr/local/bin/convert.

Продолжение темы поднятой в статьях Часть1 и часть2

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

( Читать дальше )

Иногда нужно записывать файлы в одну папку, и нужно предусмотреть, что файлы могут иметь одинаковое имя, т.е. можно перезаписать старый файл. Существует много методик которыми пользуются веб-мастера для уменьшения вероятности коллизий (совпадений) — именовать файл основываясь на уникальной информации (user_id например), md5 времени и так далее. Эти же методики находят применение в большинстве фреймверков. В подавляющем большинстве случаев этих методик достаточно, но не всегда. Мне понадобилось придумать метод создания уникального имени файла, да так чтобы сохранять оригинальное имя файла и лишь в случае совпадения его изменить. Можно конечно перед созданием файла проверять существование «тески», — но как же быть в случае большого количества потоков? Решение есть

( Читать дальше )

Данный фрагмент кода нашел где-то на просторах рунета и пишу скорее для себя чем для читателей. Предназначена функция для перевода русского текста в транслит. А вдруг кому-то еще пригодится:

( Читать дальше )

Интеграция doctrine(далее доктрины) осуществляеться с помощью создания модуля к Kohana (далее кохана). На исключительное авторство не претендую. Метод взял у какого-то буржуя и немного доточил.
Кто незнает что такое доктрина — это ORM. Намного более продвинутый чем в кохане. Один только ее исходный код раза в три больше чем вся кохана. Так например модели строятся автоматически из базы или конфига (схемы). Есть возможность начальный данные перегнать в текстовые файлы. Есть мигрирование. Полная поддержка связей (one to many, many to many, ono to one). Вобщем могу сказать что она сильно ускоряет разработку, работать с ней одно удовольствие. Но есть только один минус как по мне — тормознутость. По умолчанию она раз в 10 медленнее встроенного орма в кохане. При выполнении она занимает 5 Mb в памяти
После того как создадим модуль, для его корректоной установки понадобиться всего несколько действий:

• Добавить в корень проекта папку modules (если ее еще нет) а в нее папку doctrine. Это и есть наш модуль.

( Читать дальше )

Получив несколько комментариев на свой предыдущий пост, на хабре и здесь, возникли мысли написать этот пост.
Такое впечатление что я все это время чесал правое ухо левой рукой. Впредь компонент для меня — это класс со статическими методами лежащий в библиотеках. Теперь в шаблоне достаточно вызвать метод и сделать ему echo.
Пишем класс widget.php. Кидаем его в папку libraries:

<?php
class widget
{
    public static function example()
    {
        return View::factory('_example',array('var'=>'Привет мир'));
    }
}

?>

( Читать дальше )

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

Конечно мы не можем себе позволить обращаться к области данных из шаблона, иначе это указывало бы на нашу неграмотность. Во многих фрейверках есть для этого свои решения. Но я проведу аналогию с symfony. В последнем имеется такое понятие как компонент. Выглядит это примерно так: вы вызываете в шаблоне статический метод с указанием названия компонентов, далее происходит обращение к одноименному контроллеру, извлекаются данные из области данных и передаются в фрагмент шаблона, последний рендерится и код вставляется в нативный шаблон. Таким образом получается архитектура MVC вложенная друг в друга. Я немного упростил эту схему, сразу говорю, но суть передал точно.

( Читать дальше )

Так исторически сложилось что работаю я в основном с фреймверком Symfony. Но к сожалению она очень тяжела и не для всех проектов годится, поэтому помню каково же открытие для меня был CodeIgniter. Ведь в основном я использую только 20% возможностей symfony, и как раз то что мне чаще всего нужно было у CodeIgniter. А мне в основном от фреймверка нужно следующее:

• Фронтконтроллер( +Routing )


• MVC


• ActivaRecord / ORM


• 2-x проходное отображение


• Система конфигов


• I18N, L10N


• Cache (Drivers)


• Куча хелперов и либ

( Читать дальше )

Сейчас пишу для проверки email регулярное выражение. Вот что своял:

"/^[\w_\.-]*@[\w_-]*\.[\w_\.-]*[a-z]$/i"

Мне кажеться вроде охватывает все. Какие есть мнения?