Небольшие хитрости с Yii CGridView, или как избавиться от написания кода в строке для eval.

Всем нам не раз досаждала такая пакость, как необходимость писать большущие строки в представлении столбца в CGridView. А для чего? А чтобы не потерять переменные $data и (в меньшей степени) $row. Так вот, в нашу эпоху трайтов и анонимных функций (спасибо PHP 5.4+) можно больше не городить чего-то вроде:

array(
'name' => 'quantity',
'header' => 'Количество',
'type' => 'raw',
'value' => 'что-тосовершенноадское с $data->value $data->quantity etc',
),

А воспользоваться более элегантными вещами, через анонимную функцию и трайт, например.


//....

$controller = $this;

// ...

array(
'name' => 'quantity',
'header' => 'Количество',
'type' => 'raw',
'value' => function($data, $row) use ($controller) {
    return $controller->renderPartial('basketCols/__quantity', array('data' => $data), true);
},
),

Что происходит? А всё просто — мы можем для ячеек использовать свои собственные представления, из отдельных файлов, в которые спокойно передаем ту же $data, и там с ней работаем как с обычной переменной в шаблоне. При этом $data может являться, например, моделью, полученной для CGridView из CArrayDataProvider (или CActiveDataProvider). Если вам там надо просто сформировать какую-то дикую ссылку, то не надо даже извращения с $controller — просто юзайте статический вызов CController::createUrl(‘some paths’, array(‘param’ => ‘some param’)).

При этом внутри анонимной функции может быть сколь угодно сложный код, для которого не теряется читаемость, подсветка, и прочее, как это происходило бы в случае стандартной строки для eval. И более того, вы больше не будете вынуждены выискивать ошибку, которую вы допустили в процессе написания кода внутри строки.

 

Выкат проектов с помощью Apache ANT

Шалом тебе, дражайший читатель.

В этом посте речь пойдёт о вещах сугубо технических, и мало кому интересных. Однако, довольно насущных в сфере разработки всяческого программного обеспечения. Имеется ввиду автоматизированный «выкат» (ну, или «сборка») какого-либо проекта, путём написания для этого скриптов развёртки. Всё ещё хотите читать?))  Ну ладно, ладно.

Так вот, о чем это я. Систем выката, как известно, существует великое множество — например самой распространённой в *nix мире является make — по крайней мере если не брать красноглазиков из мира gentoo. Как вариант некоторые рассматривают cmake. Возможно довольно неплохие вещи, но скажем перенос их на другую платформу как правило означает переписывание всех скриптов заново. Да и синтаксис их написания практически один в один напоминает unix-shell, который я лично стараюсь использовать по минимуму. Ужасен он, ИМХО, что бы по этому не думали труЪ-адепты секты линуксоидов, хотя надо признать, что он предоставляет широкие возможности.

Так вот, есть более-менее нормальная такая альтернатива. Называется она Apache Ant, и в принципе с задачей она справиться вполне способна. Единственный её минус — очень мало информации на русском языке. Но для начала, давайте подумаем — зачем вообще может понадобиться делать лишнюю работу, и писать ещё какие-то билд-скрипты, ант устанавливать, и вообще, фигнёй страдать?

Читать далее Выкат проектов с помощью Apache ANT

jQuery в массы

Логотип jQuery
Логотип jQuery

Шалом тебе, дражайший читатель.

Вот сейчас залез на сайт translate.ru запиленный небезызвестной компанией PROMT — если кто не в курсе, это онлайн-переводчик. И обратил внимание, что там чуть ли не половина интерфейса сделана на jQuery: всплывающие окошки, например, виртуальная клавиатура, и так далее. Что и говорить, этот замечательный продукт за несколько последних лет изменил картину разработки AJAX-приложений. Раньше все интерфейсы как правило писались «с нуля». Фреймворки, конечно, были, но писать много всё равно приходилось. jQuery, слоган которой «Write less, do more» (пишите меньше, делайте больше) облегчил жизнь веб-программистам. Жаль, что есть ещё некоторые дремучие коллеги (от сотрудничества с которыми я кстати избавился уже довольно давно, к счастью), не приемлют фреймворки, и предпочитают делать всё по-старинке. Руками. С нуля. Это грустно, и напоминает изобретение велосипедов. В jQuery многие вещи делаются одной-двумя строчками, просто потому что это уже реализовано за вас. К примеру исчезающий и появляющийся слой делается примерно так:

$('#div_id').toggle('slow');

И это всё. Примерно такой же по объёму размер кода для отправки ajax-запроса на сервер (ну немного больше, хорошо). Я помню, на старой работе была громоздкая функция ajax_request(), которую написал как раз наш доблестный дремучий коллега. И использовать надо было именно её. Мотивация была смешная: «а зачем нам лишние 80 кб кода подгружаемого?!». При том, что размер страницы был в районе 500 кб — 1 мб, и генерация её на отладочных машинах занимала секунд 7 (кэша тоже не было). Как я уже говорил, я к счастью избавился от той работы, но контраст с текущей, где оптимизация и скорость разработки стоят на первом месте — это выглядит дикостью. Где я сейчас работаю, например, jQuery активно используется в новых проектах.

Не изобретайте велосипедов, дорогие коллеги — в 99% случаев вам не требуется заковыристая реализация этого двухколёсного средства передвижения. Живите в гармонии и балансе — между качеством, скоростью, и количеством вложенного труда. И на выходе вы получите замечательные продукты.

В заключение несколько ссылок по теме:

Собственно, сайт самой библиотеки jQuery.

И довольно качественный мануал, живущий в Израильском домене — я им постоянно пользуюсь сам.

Резка строк в UTF-8 в PHP

Время от времени в программизме для веб возникает задача обрезать строчку скажем на 1000 символов — чтобы было нечто типа «строка…» и «Читать далее» (как например сделано в этом блоге на слишком длинных заметках. Проблемы начинаются с резкой UTF-8 строк, потому что стандартная функция substr в этом отношении демотивирует — байта на каждый символ два, а она режет по одному… В результате может от какой-нибудь буквы «ё», остаться неприглядный однобайтовый служебный символ.

Если у вас есть расширение php_mbstring — нет проблем, там есть функция mb_substr, которая корректно обрабатывает юникод. А вот если нету (скажем, на высоконагруженных проектах интерпретатор PHP как правило максимально облегчён — без всяких лишних расширений) то уже сложнее. Однако, выход есть — не обязательно резать по буквам, можно резать по словам. Этот метод я случайно обнаружил в одном из рабочих проектов и просто поразился простоте и эффективности решения такой уже тривиальной задачи. Собственно, сабж:

$arr = explode(' ', $text);
$arr = array_slice($arr, 50);
$text = implode(' ', $arr[0]).'...';
unset($arr);

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

Das ist Schroedinbug

Господин Шрёдингер. Возможно убийца котов и трололольщик программиздов
Господин Шрёдингер. Возможно убийца котов и трололольщик программиздов

Второй раз за время своей практики программизма встречаюсь с такой хренью как гейзенбаг… Развесёлая пакость тут приключилась — чтобы отловить шрединбаг внедрили логгировщик, выкатили, а через некоторое время всё упало. Искал полдня. Нашли — логгировщик, призванный следить за нештатными ситуациями, валил весь комплекс)) Забавно. Кстати шрединбляг так и не нашли, ага… Как гласят работающие здесь подольше, оный проявляется нелинейно, непредсказуемо, а главное в течении последних двух лет точно. Прямо не баг, а призрак, летящий на крыльях полуночного онанизма — в зависимости от кучи параметров он может либо выстрелить, либо не выстрелить. И смыслов в этой фразе куда больше чем два. Причем задача решить проблему — переходит от программиста к программисту, от менеджера к менеджеру, да, уже два года — невольно вспоминается маяковский, с его «гариком»:

Я живу в Париже как денди
Женщин имею до ста
И мой хуй, как сюжет в легенде
Переходит из уст в уста.

Гарики, правда, владимир владимирович не писал, то больше к Губерману, однако же… Вообще конечно прикольно оно — чем больше мы наблюдаем за системой, тем меньше она показывает нам свои интимные подробности, ага. Как опять же рассказывают старожилы — когда в первый раз всё сломалось, понаставили логгировщиков, ввели анальный досмотр, и вообще, усложнили жизнь серверу. Результат не заставил себя долго ждать — в течении месяца, пока работала система логгирования, всё шло хорошо, и даже работало как надо. Скрипты показывали себя пай-мальчиками, и не устраивали вынос мозга. Однако всё волшебно изменилось, как только кому-то пришла в голову мысль забыть о багах. Что характерно, логгирование не убирали, однако в логах — пустота и треш. До сих пор ищут (ищем)…

Грустно это всё…

ipb_language — файл русского языка для IPB 2.3.6

Шалом тебе, дражайший читатель!

Обыскался я, по правде сказать, в интернетах этот файл — ipb_language.xml — используется он для русификации английской версии форума Invision Power Board (IPB) 2.3.6 — ссылки есть, а скачать без регистрации, или инако — не получается. В общем, помучившись как следует — сделал проще — скачал «нулёную» кем-то версию — в которой русский язык предустановлен, установил на денвер, экспортировал из админки русский язык в искомый файл, а российское говно — удалил (представьте себе — в нулёнке даже фронтенд не отображался как следует — вылетал из-за каких-то абсолютно левых глюков в языковом кэше). Ну а потом сделал в админке импорт языка, с установкой в параметрах General Configuration кодировку utf8 (именно так, без дефиса).

Читать далее ipb_language — файл русского языка для IPB 2.3.6

Оптимизация WordPress — 3. Простые движения.

И таки снова здравствуйте дражайший читатель.

Речь пойдёт всё о том же, о чем уже неоднократно писано в статьях по оптимизацию с W3 Total Cache и о результатах данной оптимизации. Как можно было заметить, прирост производительности с W3 Total Cache был отрицательным — блог стал работать медленнее. Да, либо плагин слишком сырой, либо просто слишком много возможностей, и, как результат, слишком долгое исполнение кода. Но нам, как пользователям, в общем-то плевать, верно? Нам хочется простой рецепт, который можно один раз сделать, и забыть о неприятностях.

Так вот, с некоторой натяжкой я такой рецепт таки нашёл. Это старый добрый WP Super Cache, в связке с WP Minify. Оба плагина позволяют установить их из панели, и затем использовать совместно, не заботясь о каком-либо обслуживании. Скажем, среднее время загрузки сайта по тестам составило 3 секунды, что уже более-менее приемлемо (а бывало доходило и до 7-8). Что делают эти плагины? WP Minify позволяет во-первых, объединить CSS и JS файлы в один большой и слегка «пожатый» удалением пробельных символов СSS и JS файл (по сути у вас становится всего два файла, один css, другой js). Браузеру всё равно, а размер становится иной раз меньше в разы. И количество запросов тоже уменьшается — к примеру до у меня было 14 (кажется) запросов на javascript & css ресурсы, а теперь только три, при этом два внешних — системы статистики, и один внутренний — на «родные» файлы. Затем, этот плагин также сжимает и HTML контент, что также уменьшает время загрузки. Опять же удалением пробельных символов.

Читать далее Оптимизация WordPress — 3. Простые движения.

О кэшировании в Web

День добрый, дражайший читатель.

Вообще, я не имею уж очень большого опыта в работе с высоконагруженными системами. Обычно проекты, которые мне доводилось делать, были рассчитаны на посещаемость в 20000 человек в сутки. Ну или около того. Однако, однако… Программисты народ странный. Мы иногда делаем нечто «на будущее». Ну вдруг потребуется. Но вначале немного теории. Как строится высоконагруженная система? Основной её компонент — это балансировщик нагрузки. Фактически он просто обеспечивает обработку запроса пользователя одним из нескольких back-end’ов. Например один балансирощик (и лично мне доводилось слышать, что в его роли может выступать например nginx), раскидывает запросы по нескольким PHP-сборщикам (или бросается смотреть в кэш — нет ли уже того, что требуется). Те, соответственно формируют контент, и отдают его обратно. Это очень упрощённо, прямо скажем. Потому что я всё-таки не администратор веб-серверов, и всех тонкостей не знаю.

Так вот, это я к тому, что кэширование — один из действенных способов снижения нагрузки. Зачем выполнять кучу кода для формирования HTML-контента, если такая работа уже была сделана ранее, и с тех пор ничего не поменялось? Правильно, незачем. Так не логичнее ли сохранить страницу в кэш, и отдавать её каждый раз быстро и без мучений? Логичнее, все так и делают. И вот тут есть выбор — где размещать кэш. Существует много вариантов, но если свести к основным, это либо жёсткий диск, либо оперативная память. Чувствуете разницу? Скорость обращения к жёсткому диску в разы ниже, чем к оперативке, но при этом кэширование на жёстком диске подходит практически для любого хостинга, в том числе и виртуального. Однако важно понимать, что высоконагруженные проекты никогда не размещаются на виртуальном хосте. Его мощностей и возможностей просто не хватит для обработки такого потока данных. Потому для просто посещаемых проектов это минимум VPS. А для проектов с высокой нагрузкой необходимо строить распределённую систему с балансировкой, отдельным сервером для БД, для кэшировщика, для контент-сборщиков и так далее. Это дорого, но как правило ресурс окупает подобные затраты.

Читать далее О кэшировании в Web

Внедрение OpenID на PHP

Логотип OpenID. Взято с Википедии.
Логотип OpenID. Взято с Википедии.

Таки здравствуй, дражайший читатель.

Вообще, не люблю я писать о работе (хотя статистика количества записей в рубрике соответствующей и ставит под сомнение данное утверждение). Но тут прямо не мог не написать. Все вы, коллеги-PHP-шники, разумеется слышали про такую адову приблуду, как OpenID. Если вкратце, то оная позволяет авторизовать пользователей на разных сайтах под одной учётной записью. Например у меня есть почтовый ящик Google, и с его помощью я могу быть авторизован на сайтах, поддерживающих такой вид авторизации. Т.е. мне не надо придумывать пароль/логин, для того, чтобы войти на сайт. При этом сам ресурс не узнаёт лишнего, он знает только то, что я — это я (ибо доверенный openid сервер это подтверждает). Так вот, вроде бы идея то, конечно, хорошая… Однако на пути внедрения оной становятся несколько проблем. Первая — отсутствие более или менее подробной информации по протоколу/стандарту на русском языке. Вторая — большой набор библиотек, позволяющих (теоретически) проводить безболезненное внедрение OpenID авторизации у себя на сайте. Третья — это наличие нескольких стандартов openid (хотя само по себе это не проблема). И четвёртая — это разная степень развитости этих библиотек, напрямую вытекающая из третьей. Есть ещё и пятая — библиотеки используют разные способы общения с серверами авторизации, самый распространённый — это curl-запросы, которые априори требуют наличия в установленном на сервере PHP расширения curl или компиляции, с опцией —with-curl. Вообще на нормальных хостингах он должен быть включен, однако… как показывает практика — не везде он есть. В общем, все дальнейшие рассуждения основываются на том, что curl таки есть, либо есть возможность его поставить. Просто найти библиотеку, которая бы его не использовала — на самом деле очень сложно.

Читать далее Внедрение OpenID на PHP

The Regex Coach: Отладка регулярных выражений PCRE

The Regex Coach
The Regex Coach

Таки здравствуй, дорогой читатель.

Вы ведь знаете, что такое регулярные выражения? Нет? Да ладно, отличный инструмент для обработки текста. Причем под текстом подразумевается что угодно — имена файлов, просто большой талмуд, URL-адреса… Что угодно. Впрочем, если вы пришли сюда по запросу отладка регулярных выражений, то вероятно понимаете, о чем речь. Если же нет, то загляните хотя бы вот сюда, и оцените их мощь. Увы, кроме мощи существует ещё и сложность — в написании, и что важнее — отладке регулярок. Скажем, простенькое регулярное выражение типа index\.php\?(.*?)=(.*?)&(.*?)=(.*?)&(.*?)=(.*?)$ — на взгляд новичка представляет собой дебри, в которых чёрт ногу сломит. А это всего лишь разборка строки типа http://www.domain.com/index.php?act=view&type=page&id=333 на переменные (ну, точнее сказать будет — на блоки), и использование их в своих целях.

Представьте теперь, что в выражение посложнее забралась ошибка (а они там появляются, они такие, да). Что делать? Очень хорошо, конечно, просмотреть процесс разборки в динамике, оценить какие участки текста затрагивают те или иные участки регулярного выражения. Но — популярные веб-ориентированные имитаторы-отладчики хотя и позволяют это сделать, но до описываемого приложения им всем далеко. Одна динамическая подсветка блоков текста чего стоит. Вообще, она предоставляет полный функционал по отладке регулярных выражений, здесь и динамическая подсветка разбираемого текста, и дерево разбора, и обозначение ошибок… Так что — это отличный инструмент для работы с PCRE выражениями. Увы, описывать его работу это занятие муторное и неблагодарное, да и описывать особо нечего — если знать язык регулярных выражений и понимать как они работают, работа с программой не будет в тягость — изучать в ней особо нечего — какой, в общем-то, и должна быть идеальная программа — сосредотачивать на решении целевой задачи, не отвлекая лишними возможностями.

Скачать это чудо можно здесь.