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

А вот надписей вроде еще не было. Значит будут. :-)

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

Сегодня хочу рассказать Вам о своем недавно состоявшемся первом знакомстве с фреймворком symfony.

Так как до этого я в течение длительного срока (около полутора лет) разрабатывал свои приложения на Zend Framework'е — мне есть с чем сравнивать.

Сегодня решил сделать то, что собирался уже давно — поставить таки кеширование скриптов у себя на сайте. Все скрипты перед отдачей пользователю собираются в один файл и сжимаются GZIP'ом — все вроде по-уму, но есть проблемка… Браузер отчаянно не хотел кешировать этот выходной скрипт.

Опытным путем было установлено, что PHP устанавливает хидеры запрета кеширования при использовании функции session_start();

Библиотека HTTP_StaticMerger позволяет автоматически «сливать» набор статических файлов (CSS и JS) и, таким образом, ускорять загрузку страницы, экономя HTTP-запросы. Библиотеку рекомендуется применять совместно с кэширующим reverse proxy для минимизации времени ответа.

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

После того как вы прочли статью о ветках в svnbook, вы уже понимаете для чего нужны ветки, как с ними работать и в каких случаях их необходимо использовать. В принципе, после этого, то, что написано под катом вам уже скорее всего не нужно. Но если вам было лень читать, то может текст ниже вас заинтересует, и вы все таки прочтете статью документации. А может, просто поможет вам лучше понять то, что только что прочли в svnbook-е.

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

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

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

Вы, конечно, можете использовать стандартный плагин, но чтобы сделать простой tooltips, Вам достаточно написать всего 10 строк кода jQuery и CSS.

Итак, приступим. Прежде всего обратите внимание на структуру этого tooltips: это обыкновенная ссылка, которая будет выглядеть примерно так:

Это вторая, дополнительная (upd: дополненная), часть моей статьи посвященной кэшированию информации при веб-разработке. Первая имеет название Теория кэша.

UPD: После многочисленных коментариев я сильно переработал статью, внес в неё больше конкретики и примеров, а так же убрал спорные моменты (например, касательно memcached). Спасибо всем, за конструктивную критику.

В данной статье я попытаюсь описать практические стороны кэширования, ориентированные, прежде всего, на сайты и системы управления контентом. Сразу предупреждаю, это мое личное мнение, которое не претендует на истину в последней инстанции. Большинство терминологии — моё, вы можете использовать его, если считаете нужным на своё усмотрение. Конструктивная критика приветствуется.

Введение

Кэширование – это неотъемлемая часть всех сложных систем. Кэширование позволяет существенно увеличить скорость работы приложения, путем сохранения трудновычислимых данных для их последующего использования. Впрочем, не буду вдаваться в определения, большинство разработчиков отлично знает что это такое.

В данной статье я попытаюсь «разложить по полочкам» проблему кэширования, ориентированную прежде всего на сайты и системы управления контентом. Сразу предупреждаю, это мои личные соображения, которые не претендуют на истину в последней инстанции. Вся терминология так же моя, вы можете использовать её, если считаете нужным на своё усмотрение. Конструктивная критика приветствуется.

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

Содержание статьи имеет мало общего с моей прошлой статьей про использование выражений в PHP. Речь не идет об усложнении кода, скорее наоборот.

Разрабатывая сайты мне всегда хотелось облегчить себе жизнь, так я познакомился с jQuery. Все было бы хорошо если бы проекты не погружались в зыбучую смесь UI и js кода. Следующим этапом стало то что мы выделили UI Шаблоны в отдельные файлы, код стал более чистым, но, черт побери, все равно приходилось писать кучу UI кода, например вставка и настройка дополнительных компонентов в шаблон, event bind, надписи и т.д. И только после всего этого на выходе получался нужный нам компонент. Возникало, конечно, много проблем, особенно когда дизайнер менял шаблон, но все это решаемо.

Первая часть текста взята из инструкции хостинг-провайдера Netangels. Вторая — авторская.

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

Для того, чтобы быть уверенным, что ваше сообщение отправляется действительно верно, необходимо иметь по меньшей мере базовые представления о формате почтового сообщения. Формат почтового сообщения описан в нескольких стандартизирующих документах, основными из которых являются RFC 822 (описывает формат передачи простого текста на английском языке) и RFC 2045 и далее (описывает расширения этого формата для передачи произвольных данных).

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

Ниже перевод статьи «Optimizing Page Load Time», в которой автор математически рассчитывает оптимальный размер файлов для эффективной передачи при веб-запросах, рассматривает некоторые прикладные вопросы оптимизации загрузки страницы с учетом особенностей браузеров, а также дает несколько развернутых и ценных советов. Мои комментарии далее курсивом.

Существует распространенное мнение, что быстро загружающая страница положительно влияет на впечатление пользователя (improve the user experience). В последние годы многие сайты начали использовать для этой цели технологию AJAX, чтобы уменьшить время ожидания (при загрузке данных). Вместо того, что запрашивать с сервера новую страницу полностью при каждом клике, браузер часто можно либо поменять вид самой страницы (отобразив или скрыв какие-либо блоки), либо подгрузить небольшую порцию HTML-, XML- или JavaScript-кода и внести изменения на существующую страницу. В любом случае, это значительно уменьшает время, проходящее между кликом пользователя и окончанием визуализации браузером нового содержания.

Что влияет на загрузку страницы?

Однако, для большинства сайтов, загрузка страницы затрагивает десятки внешних объектов, основное время загрузки тратится на различные HTTP-запросы картинок, JavaScript-файлов и файлов стилей. AJAX, возможно, поможет в данной ситуации, но ускорение или удаление этих HTTP-запросов может принести гораздо больше пользы, хотя на данный момент нет единого мнения (a common body of knowledge), как именно это следует делать.

читать дальше на webo.in →

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

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

Когда пришлось реализовывать дерево комментариев, столкнулся с необходимостью рекурсивного вызова представления (view в MVC). Так как представления у меня, да и практически везде, — это обычные файлы с кусками HTML-кода и возможностью вставки PHP, то подключаются они с помощью include. Мне стало не по себе, когда представил как этот include вызывается рекурсивно сотни раз. Первая мысль — засунуть файл представления при первом запросе в память и потом выполнять его через eval. Такой подход позволит кешировать код представлений, и даже хранить его в БД. Так как eval кушает только PHP, а представления у нас чистым PHP-кодом не являются, то обрамляем содержимое в '?>' и '<?php'.

Хочу еще раз поднять тему использования сессий для аутентификации пользователей. Надеюсь услышать критику приведенного в статье метода с высоты вашего опыта.

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

Хорошие фреймворки предлагают инструменты для полного кэширования страниц, фрагментарного, или кэширования экшенов. Недавно я посмотрел 90 выпуск подкаста Railscasts, посвященный именно фрагментарному кэшированию в Ruby on Rails и уважаемый автор решал проблему, как мне показалось, неоптимально.

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

Отчего-то всегда хотел сделать свой сервис для загрузки файлов. Всевозможные slil/zalil не устраивали своей скоростью. ifolder — обилием рекламы. Пользовался не очень популярным (от этого он ни чуть хуже не становился) сервисом up.spbland.ru. Но это как-то не правильно. И тут я решил написать свой сервис. Не буду вдаваться в подробности и рутину, только концепция.

Добро пожаловать во вторую серию нашего повествования про xdebug. Установка xdebug и его базовые возможности были рассмотрены в первой серии. В данной статье мы рассмотрим трассировку программы.
Предыдущая серия цикла Introducing xdebug