PHP *

Недавно в блоге PHP пролетала статья про наследование шаблонов в Smarty, которая навела меня на мысль: я уже на протяжении нескольких лет использую Smarty в качестве основного шаблонизатора и у меня накопилось множество написанных мною плагинов для расширения базового функционала. Почему бы не поделиться с сообществом своими наработками и послушать других? Я думаю, у многих есть чем поделиться по этой теме…

Данная статья рассматривает одну из проблем хранения PHP-сессий в memcached: отсутствие их блокировки.

Введение

Ни для кого не секрет, что одним из самых популярных способов повышения производительности сайта является использование memcached. Об этом неоднократно говорили и приводили многочисленные примеры. Самый простой способ сделать это — использовать memcached для хранения сессий PHP. Для этого нет необходимости переписывать весь код, достаточно нескольких простых действий. Я не буду рассказывать, почему надо хранить сессии в memcached. Я расскажу о том, почему хранение сессий в memcached опасно.

Отсебятина

А вот и перевод третьего урока по Google Maps API. Этот урок — как видно из названия — посвящен созданию карт при помощи данных, хранящихся в БД. Как и предыдущие — кросс-пост из моего блога.

В очередной раз ковыряясь в чужом коде, понимаю насколько больная тема — стандарты кодирования в PHP…

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

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

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

Реализация для PHP, кеш ориентирован на хранение и извлечение данных из файловой системы: code.google.com/p/ewgra/source/browse/#svn/trunk/cache

В последних версиях PHP появились namespace'ы — пространства имен.

У них есть очевидные преимущества:
— помогают сократить названия классов;
— позволяют избежать конфликтов имен;
— помогают лучше структурировать классы.

Но, помимо этого, есть еще преимущество, на которое не так часто обращают внимание: namespace'ы помогают разработчику видеть зависимости того или иного класс, причем это не приводит к какому-либо оверхеду. Поясню.

Помните, как в PHP4 мы писали перед объявлением класса:
require_once "MyClassParent.php";
require_once "MyClassDependency.php";

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

И тут — появляется батут php-5.3. Теперь, без лишнего оверхеда мы можем, и даже не только можем, но и в определенных случаях должны — указывать зависимости нашего класса:
use myns::MyClassParent;
use anotherns::MyClassDependency;

Отметим, что при использовании use не происходит подключения файлов с классами.
Теперь, как говорится, и программисты волки сыты, и харды овцы целы.

Когда-то, давным-давно, мне пришлось использовать небезызвестный шаблонизатор Smarty. Сначала я, понятное дело, возмущался и кричал, какая же гадость эта заливная рыба Smarty, а потом «распробовал» и втянулся. Те удобства, которые он давал, с лихвой компенсировали мысли о том, что есть и более быстрые шаблонные движки.

Шаблоны я обычно строил с помощью инклюдов: в начале подключался header.tpl, в конце — footer.tpl, в середине ещё что-нибудь нужное. В целом разметка получалась довольно аккуратной, но не проходило ощущение, что не хватает чего-то важного. Окончательно понимание этого чего-то появилось, когда мне случилось написать простенькое приложение на Django. И это «что-то», как все поняли, оказалось наследованием шаблонов. Простая, как и всё гениальное, идея позволяла существенно упростить шаблоны и избавиться от дублирующих блоков.

Подборочка ошибок начинающих PHP разработчиков…

Приветствую всех читателей!

Я начал заниматься SEO недавно, и сразу же столкнулся с задачей определения позиций продвигаемых сайтов по ключевым словам в поисковиках. Задача тривиальная и решается на ура различным ПО, которое у всех SEO-специалистов на устах: Semonitor, AllSubmitter, etc. Помимо проприетарности, которой попахивает от всех подобного рода программ, в них есть, как это не парадоксально, ряд технических моментов, из-за которых хочется выбросить компьютер в окно.
Я бы не прочь купить Semonitor, но попользовав демо-версию, решил от этой идеи отказаться — на оф.сайте программы доступная для скачивания версия у меня глючила, требовала обновить себя, а после выпрошенного у меня обновления и вовсе отказывалась заниматься анализом позиций. Самому настроить, как Вы понимаете, нельзя.
AllSubmitter в этом плане получше, позволяет даже кастомизировать регулярные выражения для поисковиков, что вроде как делает этот софт устойчивым к смене формата выдачи, однако и с ним не все слава богу — когда 18.08.2008г. Яндекс вдруг изменил формат выдачи результатов поиска, вместе с тем поменяв и URL ссылок (возможно, эксперименты с вводом учета переходов, подробнее об этом писалось здесь), то и AllSub оказался бессилен. Правда, на следующий день Яндекс снова вернулся к старому формату выдачи, но прецедент, тем не менее, произошел.

 

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

Тем, кто ежедневно стыкается с разработкой сайтов, наверняка приходится работать с шаблонами, вот и мне пришлось. Как всегда, наличие выбора отбирает свободу действия. Типов шаблонов и готовых решений – огромное множество, я остановился на таких вариантах:

Вариант 1.

<!--Begin[News_List]-->
 <!--Begin[News_ListItem]-->
  {date} <a href="{link}">{title}</a>
  <br />
  {header}  
 <!--End[News_ListItem]-->
 <!--Begin[News_ListItemEdit]--><a href="#">edit</a><!--End[News_ListItemEdit]-->
<!--Begin[End_List]-->

Достоинства: понятный, читабельный в паре с html
Недостатки: громоздкий

Вариант 2.

<? foreach($news as $item) { ?>
<?=$item->date?> <a href="<?=$item->link?>"><?=$item->title?></a>
<br />
<?=$item->header?>
<? if($permitted) { ?><a href="#">edit</a><? } ?>
<? } ?>

Достоинства: шустрый
Недостатки: нечитабельный, так и хочется дописать логику к отображению

Вариант 3.

<component name="news">
 <item>
  {date} <a href="{link}">{title}</a>
  <br />
  {header}   
  <secured roles="{roles}"><a href="#">edit</a></secured>
 </item>
</component>

Достоинства: понятней некуда, присутствует что-то родное 
Недостатки: нечитабельный в паре с html

В примерах представлено отображение списка новостей.
Хотелось бы прийти к оптимальному результату, по этому интересует мнение опытных front-end разработчиков. Возможно, есть лучше варианты — буду рад рассмотреть.

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

Считаете, что вопрос пустяковый и все тут просто как 2 пальца? Может быть, только недавно мне встретилась занятная бредострочка с толстенным регулярным выражением и все для того, что бы просто получить несколько символов в конце строки после последней точки. Зачем? Итак, начнем с пяти наиболее распространенных способов. Без использования регулярных выражений (только не подумайте, что я считаю их злом). Писать буду как просто и доступно, это не научная статья, а авторская заметка.

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

Полиморфизм — одна из трех основных парадигм ООП. Если говорить кратко, полиморфизм — это способность обьекта использовать методы производного класса, который не существует на момент создания базового. Для тех, кто не особо сведущ в ООП, это, наверно, звучит сложно. Поэтому рассмотрим применение полиморфизма на примере.

Уже продолжительное время доступен сервис Яндекс.XML — сие есть не что иное, как поисковый сервис, который позволяет делать автоматические поисковые запросы к Яндексу и публиковать его ответы у себя на сайте и данный пост посвящен приручению сего зверя с использованием PHP.

Здравствуйте, уважаемые хабрадевелоперы.

С вашего позволения я немного пофилософствую на тему развития нас, как сообщества девелоперов, использующих замечательный язык PHP. Заранее скажу, что многие могут не поддержать мою точку зрения и я буду рад обсудить это в комментариях. Итак, приступим…

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

Так исторически сложилось, что PHP считается простым языком.
Изначально он создавался для быстрого написания небольших динамических веб-приложений низкоквалифицированным (читай — неопытным и начинающим) веб-разработчиком.
Аббревиатура PHP в далеком 1994 году означала «Personal HomePage».

С тех пор прошло 14 лет, движок PHP переписывался с нуля два раза (если мне не изменяет память), обрастая «взрослой» функциональностью и разбивая стереотипы своей ограниченности проектами уровня Фейсбука и Википедии.
Стоит подождать ещё самую малость и выйдет PHP 5.3 с долгожданными неймспейсами, незаслуженно игнорируемым Late Static Binding и некоторыми добавками синтаксического сахара.

В PHP-5.3 появилось расширение phar, причем в последних версиях оно включено по умолчанию. Однако, после того как я наблюдал следующую картину: сегфолт при использовании стандартной функции is_file() (который на самом деле является прямым следствием того, что вместе с PHP у меня установился этот самый phar) — после этого я крепко задумался, нужно ли это расширение ставить по умолчанию и не лучше ли было бы ставить его, наоборот, только по требованию.

Вкратце: расширение объявляет «перехватчики» — interceptors — для вызовов некоторых функций, вовсе не входящих в это расширение. Это поведение, по очевидным причинам, для многих нежелательно — это лишние тормоза, лишние баги (как доказывает вышеприведенная ссылка на bugs.php.net).

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

Однажды я столкнулся с такой проблемой: на странице сайта с помощью PHP-скрипта выдавался пользователю видео-контент (подробнее в моей статье «flash-видео на веб-страницах и PHP»).

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

Ларчик открывался довольно просто. На сайте использовалась авторизация, основанная на стандартных PHP-сессиях. Так вот, когда сессия стартуется, сессионный файл блокируется, и до тех пока сессия не закроется и файл не разблокируется, никто не может открыть файл сессии. По умолчанию сессия закрывается при окончании работы скрипта. Мы добавили непосредственно перед выдачей видео-контента строку session_write_close() — вуаля, все заработало.

Поскольку совсем недавно товарищ пожаловался на точно такую же проблему и был рад полученной подсказке — я решил поделиться этим «хинтом» с хабралюдьми.