Vulpo One




PHP 5.6 — variadic func / splat operator

<?php

function func($a, $b, ...$params)
{
   var_dump($a, $b, $params);
}

func(1,2,3,4,5);
// int(1)
// int(2)
// array(3) {
//   [0]=>
//   int(3)
//  [1]=>
//  int(4)
//  [2]=>
//  int(5)
// }
// cool!

$a = [1,2,3,4,5];

func(...$a);
// int(1)
// int(2)
// array(3) {
//   [0]=>
//   int(3)
//  [1]=>
//  int(4)
//  [2]=>
//  int(5)
// }
// even cooler!

$a['qq'] = 'qq';

func(...$a);
// PHP Catchable fatal error:
// Cannot unpack array with string keys in /tmp/test.php on line 16
// okay :(

$b = [];
$b[1] = 1;
$b[4] = 4;
$b[2] = 2;
$b[5] = 5;
$b[3] = 3;

func(...$b);
// int(1)
// int(4)
// array(3) {
//   [0]=>
//   int(2)
//   [1]=>
//   int(5)
//   [2]=>
//   int(3)
// }
// WAT?

Comments


Prosody @ SunChaser.info

Переселил jabber для домена с монструозного ejabberd на легкий Prosody. Высвободил ~200 МБ оперативы на VPS-ке. В принципе, полет нормальный, только хранение истории на сервере теперь через новый стандарт, который ни один клиент не поддерживает :( Пришлось запилить по-быстрому веб-интерфейс.

Если кому нужна конвертилка истории из mod_archive_odbc ejabberd в mod_mam_sql Prosody — их есть у меня (холст, масло, сыр, PHP)

Comments


SPDY и TLS в Apache

SPDY — модная нынче замена протоколу HTTP от Google. Не просто костыль от “корпорации добра”, а поддерживаемый браузерами стандарт и кандидат на включение в HTTP/2.0

Фичи: во-первых, цель — чтобы все ресурсы страницы были отданы за 1 соединение (очень заметно, если на странице подключается много мелких файлов), во-вторых, простота настройки.

Установка в CentOS 6:

  1. качаете и устанавливаете mod-spdy-beta_current_x86_64.rpm (64 бита) или mod-spdy-beta_current_i386.rpm (32 бита)
  2. перезагружаете апачу

всё, у вас SPDY. В nginx тоже должно быть просто, но у меня Apache

Недостатки (а как же без них):

  1. Работает только через SSL (пока)
  2. несовместим с Apache mod_php

Тут в принципе всё решаемо. PHP перенастраивается на работу с FastCGI — и лучше сделать так как можно скорее, т.к. от mod_php много и других проблем, таких как чушь с правами на файлы и требование неоптимальной версии апача — Apache MPM Prefork

С SSL чуть хитрее — многие помнят (а у многих и до сих пор крутится соответствующая древность на серваках) те несладкие времена, когда для поднятия сервака на https:// требовалось каждому хосту раздать по IP-шнику. Так вот, эти времена прошли и можно без нервов сделать веб чуть безопаснее

Надо убедиться что

  1. ваш OpenSSL версии 0.9.8k и старше (и TLS в нем не выключен)
  2. апача собрана с этой версией OpenSSL
  3. установлен mod_ssl

Для CentOS 6 (не 5!) всё собрано соответственно, так что надо просто установить

Всё! У вас сервак с поддержкой SNI, которая позволяет обходить ограничения старых версий SSL

Рекомендуется еще в конфиг Apache добавть такую строку: SSLStrictSNIVHostCheck (on|off)

on закроет доступ старым браузерам, не умеющим работать с SNI (премногоуважаемый всеми IE6, Firefox младше 2.0, Safari младше 3.2.1, Opera младше 8.0, Google Chrome такое с рождения умел), off позволит им заходить, тем не менее, устрашая “неверными” сертификатами. Я подумал чутка и поставил on. Ибо нефиг

SPDY добывать здесь: code.google.com/p/mod-spdy
Инфа про SNI и TLS тут: wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Comments


Libravatar Replace

Написал свою версию плагина для Libravatar — Libravatar Replace. Точнее, пришлось форкнуть оригинал, т.к. автор упорно молчал на мои попытки связаться. Сначала я добавил все дефолты Либраватара в список, а потом понеслось

Фичи:

  • Плагин полностью заменяет Gravatar на Libravatar в WordPress, включая всё default images (лого только меняется соответствующе)
  • Services_Libravatar содержит мой патч, исправляющий работу с портами в SRV
  • Попытался сделать поддержку BuddyPress (там свой алгоритм генерации изображний-аватаров, причем писец какой запутанный) — вроде работает

Comments


Про утечку ресурсов в генераторах PHP

Очень интересный и полезный момент сегодня всплыл в комментариях на Хабре. В PHP 5.5, как известно, сделали поддержку функций-генераторов, по типу питоновских. Там раньше были итераторы, но с адовым синтаксисом (как всё в SPL), а теперь ввели оператор ‘yield’ и всё волшебным образом упростилось.

Например, можно написать такой генератор, читающий построчно файл:

<?php
function getLines($file) {
    f = fopen($file, 'r');
    while ($line = fgets($f)) {
        yield $line;
    }
    fclose($f);
}

yield’ означает «вернуть значение и продолжить с этого места при следующем вызове функции». Имея такой генератор, можно сделать вот такую печать файла:

<?php
foreach (getLines("file.txt") as $line) {
      echo $line;
}

Удобно? Очень удобно. Оператор ‘yield’ выдаст все строки файла, а потом, когда файл закончится, произойдёт обычный ‘return’ из функции, который закроет генератор (и закончит цикл).

Но как известно, если всё идёт хорошо, значит, вы чего-то не заметили. Немного изменим наш цикл:

<?php
foreach (getLines("file.txt") as $n => $line) {
    if ($n > 5) break;
    echo $line;
}

Предположим, нас интересуют только первые шесть строк файла, а дальше мы хотим прервать цикл оператором ‘break’. Имеем на то полное право. Но что в этом случае произойдёт внутри генератора? А ничего. Он останется стоять на последнем исполненном yield-е и никогда не дойдёт до строки ‘fclose($f)’. И наш файл останется незакрытым.

Мы получили утечку ресурса (открытого файла). Понятно, что внутри генератора могут быть открыты любые ресурсы и объекты, и их необходимо правильно и предсказуемо закрывать. Но как это сделать, если юзер может в любой момент сделать break? Обычная документация (http://www.php.net/manual/en/language.generators.overview.php) никаких намёков не даёт.

Так вот, оказывается (и за это спасибо юзеру weirdan с Хабра: https://habr.com/ru/post/189796/#comment_6594776), что читать в этом случае надо не документацию, а RFC по генераторам: https://wiki.php.net/rfc/generators#closing_a_generator. А в нём сказано, что при освобождении ссылки на генератор, у него внутри обязаны выполниться все блоки ‘finally’. И тогда мы получаем очень простой, красивый и безопасный код:

<?php
function getLines($file) {
    f = fopen($file, 'r');
    try {
        while ($line = fgets($f)) {
            yield $line;
        }
    } finally {
        fclose($f);
    }
}

В этом случае блок ‘finally’ выполнится и при нормальном выходе из цикла по генератору и при выходе по break-у. Ура.

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

ru-php.livejournal.com/1566325.html

Comments



Libravatar

Как бы ответ на мои молитвы и проклятия появился сервис Libravatar, альтернатива так подставившему меня сервису Gravatar.

На самый первый взгляд, те же яйца, только в профиль — если просто заменить www.gravatar.com на cdn.libravatar.org, взлетит. Это уже хорошо, т.к. Gravatar без гадких Automattic мне было бы достаточно, но нет, всё круче — можно поднять свой сервис и сделать его публично доступным! (Подходит, правда, не для конечных пользователей, а для владельцев доменов, т.к. дискавер идет через SRV-записи DNS) + Приятный бонус в аватарах не только по email, но и по URL (чтобы работало на libravatar.org они должны быть проверены через OpenID, на своем — не обязательно)

Казалось бы у нас теперь 3 несовместимых системы — Libravatar, Pavatar, Gravatar, но и тут есть бонус — Libravatar, если не найдет картинку у себя, покажет Gravatar, так что если вспомнить, что Pavatar популярности не сыскал, можно обойтись этой новой штукой.

Ну и, естественно, я уже накатал чекер — https://sunhome.snch.info/static/libravatars.html

Comments