оптимизация вывода

Ни кода не забываем зачищать за собой открытые дескрипторы или удалять временные файлы.
Это касается вывода на экран, с помощью незатейливой функции flash() после echo можно прилично повысить TTFB.

SplString для ключей массива

Я тут подумал, что для сохранения массива с ключами в виде чисел как строк (чтоб массив был хешем), можно использовать класс SplString (http://php.net/splstring). А то ж php так и наровит представить строку как число.

['5'] => ...
['49'] => ...
...

On road to php5.5

Идем в ногу со временем.

http://www.slideshare.net/jpauli/on-road-to-php55

Осторожность при получить headers

В php есть замечательная функция:

get_headers — Возвращает все заголовки из ответа сервера на HTTP-запрос.

Но к сожалению, она не всегда приносит правильные заголовки, особенно я заметил это когда пытался получить Content-Type, где ожидая получить 'image', получил text/html.
Как бы не хотелось избежать вызова CURL-а, но все же подстраховаться надо обязательно.

Yii, extensions simpletree with FOREIGN KEY

Lang: php

Framework: Yii

Extensions: SimpleTree (http://www.yiiframework.com/extension/simpletree/)

Если в таблице использовать Вне́шний ключ (англ. foreign key), то данные не отображаются, или отображаются не все. Это происходит из-за того, что плагин не обрабатывает null в поле parent_id. А 0 мы поставить не можем из-за внешнего ключа.

Решение такое, заменяем строку:

> 207 foreach ($Model->findAllByAttributes(array($_REQUEST['modelPropertyParentId']=>$_REQUEST['id'])) AS $k => $Model)

На следующий код:

$criteria = new CDbCriteria();
$criteria->addCondition($_REQUEST['modelPropertyParentId']." = ".$_REQUEST['id']);
if (!$_REQUEST['id']) {
      $criteria->addCondition($_REQUEST['modelPropertyParentId']." IS NULL", 'OR');
}
foreach ($Model->findAll($criteria) AS $k => $Model) 

И можно смело дальше использовать плагин.

PS. Если кто найдет email автора плагина - JayRoe, скажите ему об этой недоработке.

Memcached and tags

Сегодня произошла очень странная вещь.
Сижу, обдумываю проект, встраиваю memcashed в проект и думаю, как бы мне оптимизировать придыдущую версию этой реализации. Это все с учетом того, что я работаю с движком Yii.
В предыдущей версии я сохранял данные возвращенные из базы в моделях..., а сейчас думаю, а какого фига я тут корячусь.
Есть же возможность кешировать запросы средствами движка практически без моего участия. Сделал, работает, порадовался. Остается одна небольшая проблема, как сделать так, чтобы оперативно удалять устаревшие кеши при обновлении таблиц.
Сижу думаю.
А использую я ActiveRecord.
Надо поставить какие-то параметры, которые будут сообщать модели, что его таблица изменилась и нужно все перекешировать заного при запросе. Параметры эти запихнуть в тот же кеш. И осталось каким-то фигом при сохрании кеша эти параметры менять обратно. В общем система не эфективна...
Оказалось, что я не так уж и далек от решения, оказавшегося уже кем-то придуманым, кстати, чему не удивляюсь.
А нужно было всеголишь иметь не параметры для каждого запроса, а один, и определять изменения по нему не булевой операцией, а простым наращиванием! Просто как все гениальное.
А нашел я это тут http://www.opennet.ru/base/dev/memcached_tips.txt.html.
Теперь осталось придумать как запихнуть этот тег в кеш при записи в кеш и все будет пучком.
...
После полудня разбирательства в этой фигне, сообразил такую штуку. Фигачим класс:

class CTagCacheDependency extends CCacheDependency
{
public $tag;
        public $cache;
public function __construct($tag=null, $cache=null)
{
$this->tag=$tag;
$this->cache=($cache)?$cache:Yii::app()->cache;
}
       
protected function generateDependentData()
{
if($this->tag!==null)
                {
                        $t = $this->cache->get($this->tag);
                        if ($t === false) {
                                $t = time();
                                $this->cache->set($this->tag, $t);
                        }
                        return $t;
                }
}
}

L. 1

Используем его таким макаром в модели:

$this->cache(60, new CTagCacheDependency(get_class($this)));

L. 2

И не забываем после каждого изменения в базе (afterDelete, afterSave) делать это:

Yii::app()->cache->set(get_class($this), time(), 0);

L.3

Теперь у нас есть тег на кажду модель (таблицу) которая при любом обновлении будет кешироваться заного благодаря измененному тегу, распространяющемуся на кажду модель(таблицу).

Поясню немного.
L. 1 - это класс так называемой Зависимости кеша. В нем мы выбираем тег, если его нету, создаем новый и записываем его обратно в кеш.
В L. 2 мы устанавливаем эту зависимость для каждого кеша который будет выбираться и проверяться с данной зависимостью.
L. 3 - нужно для того, чтоб сказать нашей модели (через тег), что ее данные в таблице были обновлены.

Новая запись в таблице через Yii

PHP
Движок Yii 1.1.9
Работа с базой через CActiveRecord

Если захотите сохранить новую запись методом save(), воспользовавшись конструкцией Model::model(), ничего не получиться. Почему-то движек считает, что запись уже есть и $this->getIsNewRecord() возвращает false при использовании insert().
Интересно еще то, что save() вам вернет true и ошибок ни каких не выдаст, типа сохранил. А в таблице пусто.


Возвращаемся к старой доброй и надежной new Model().

Читаю очень умную книжку - "Чистый код" Роберт Мартин (Robert C. Martin "Clean Code") 2010г.
Пока до половины только прочел...

В предисловии к книге автор допускает, что с его мнениями можно не согласиться. Вот я и не соглашаюсь по одному из них.
На странице 90 (в книжном варианте, иначе 91) автор пишет, про избыточность обязательных комментариев Javadoc (про это там еще где-то написано). И я ни сколько не сомневаюсь в уме этого товарища.
Только он забывает, что по этим комментариям потом можно будет собрать отличное руководство по проекту, в том числе и по классам. О коде-то он позаботился, а что с проектом делать потом, когда все комменты почистить? Люди упрощают создание мануала, понимаешь, а он тут раз и нафиг все.

К тому же, современные IDE позволяют отлично скрывать все комментарии, даже при загрузке файла, так что комменты, написанные в стиле Javadoc ни коем образом не помешают.

А в php IDE еще и читает эти комментарии и с помощью них восполняет отсутствие строгой типизации в php. К примеру, напишите такое:

/**
* @return UserObject
*/
public function getSomeUsers(){
$userObject = new UserObject();
...
return $userObject;
}
И когда вы будите использовать что-то возвращенное этой функцией, IDE поймет, что вы пользуетесь объектом UserObject!



Ну даже и без этого, все равно можно не согласиться с избыточностью  комментариев.
Вот переменная: duration - Продолжительность воспроизведения в минутах. А как узнать без комментариев в минутах или в часах эта самая продолжительность?
Кстати, если называть durationInMinutes, то это еще тот бред, а если в часах понадобиться, переназывать переменную и свойство класса? так это ж рехнуться можно будет...




PS: кстати у него в коде там ошибка, или не у него, там где он его брал в общем.

Недавно узнал от товарища одну особенность у IDE Eclipse и проверил ее в NetBeans. При написании коментария к функциям синтаксисом PHPDocumentor(etc...), примерно так:

/**
* @return CommonObject
*/

Если функция неявно возвращает объект, то IDE увидя такой тег, будет считать, что функция возвращает объект класса CommonObject и соответственно сделает правильное подсвечивание кода.

Баг в php

http://www.xakep.ru/post/56566/

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

лучше один вызов, чем два

Не забываем, что:

$var = function();
if(!$var){
    $var = newFunction();
}
echo $var;

работает быстрее чем:

if(function()){
    $var = function();
}else{
    $var = newFunction();
}
echo $var;

Второй способ к тому же вообще не правильный.

кавычки

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

Основной довод не использования двойных кавычек это, конечно, скорость.

Открыли сессию?

Как часто многие php-сты открывая сессию(session_start()), а если и не один раз то вообще ужас, могут однажды увидеть такое:
"cannot send session cache limiter headers already sent"
 А потом еще и искать, что за нафиг случился...

Одно из решений:

if (!session_id()) session_start();

И больше ни когда не придется видеть ту жуткую надпись.

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

random или псевдо-случайные числа.

Речь пойдет о стандартной функции в php.

rand() -  Generate a random integer.

Однажды ночью обнаружилась  принеприятнейшая ситуация. Тестим мы сервак на высоконагруженность, бомбя его большим количеством соединения за короткий промежуток времени. И тут в одном месте видим потерю соединений в 70-80% случаях. Немного прифигев. т.к. к базе обращений очень мало, циклов больших по проекту не ожидалось..., начали искать...
Долго искали в разных местах...
А была, казалось бы, безобидная функция... Из массива случайно выбиралось значение, потом выбиралось следующее случайное, но с проверкой, чтоб они не совпадали... получалась рекурсия...
И, видимо, при частых обращениях у rand() наступал кондратий, возвращая одинаковые значения, от чего наша рекурсия стремилась к бесконечности. Стоило убрать проверку равенства случайных чисел и все заработало без проблем.

И так:

Никогда не сравнивайте случайные значения.

Ищите либо другой способ реализации функционала, либо удостовертесь, чтоб такая проверка не попадала под большие нагрузки.

Кстати, это же касается и функции random() в MySQL и PostgreSQL.
При очень высокой частоте соединений, такой запрос:

select * from table random() limit 2;

может положить сервак.

Есть подозрение, что это касается и других языков программирования.