В вашем доме будет отключён JavaScript
Ну, не JavaScript, а Java, не отключен, а запрещен к скачиванию, и не в вашем доме, а в домах клиентов ФГУП РСВО
src: habr.com
Ну, не JavaScript, а Java, не отключен, а запрещен к скачиванию, и не в вашем доме, а в домах клиентов ФГУП РСВО
src: habr.com
Мой вордпрессовый плагин Libravatar Replace обошел по скачиваниям плагин Libravatar *dance*
Пока мне не спится, набросал страницу для конвертации вордпрессовских Readme.txt в гитхабовский Markdown
В общем-то вся логика уже есть в интернетах, надо было только собрать всё воедино
<?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?
Переселил jabber для домена с монструозного ejabberd на легкий Prosody. Высвободил ~200 МБ оперативы на VPS-ке. В принципе, полет нормальный, только хранение истории на сервере теперь через новый стандарт, который ни один клиент не поддерживает :( Пришлось запилить по-быстрому веб-интерфейс.
Если кому нужна конвертилка истории из mod_archive_odbc ejabberd в mod_mam_sql Prosody — их есть у меня (холст, масло, сыр, PHP)
SPDY — модная нынче замена протоколу HTTP от Google. Не просто костыль от “корпорации добра”, а поддерживаемый браузерами стандарт и кандидат на включение в HTTP/2.0
Фичи: во-первых, цель — чтобы все ресурсы страницы были отданы за 1 соединение (очень заметно, если на странице подключается много мелких файлов), во-вторых, простота настройки.
Установка в CentOS 6:
всё, у вас SPDY. В nginx тоже должно быть просто, но у меня Apache
Недостатки (а как же без них):
Тут в принципе всё решаемо. PHP перенастраивается на работу с FastCGI — и лучше сделать так как можно скорее, т.к. от mod_php много и других проблем, таких как чушь с правами на файлы и требование неоптимальной версии апача — Apache MPM Prefork
С SSL чуть хитрее — многие помнят (а у многих и до сих пор крутится соответствующая древность на серваках) те несладкие времена, когда для поднятия сервака на https:// требовалось каждому хосту раздать по IP-шнику. Так вот, эти времена прошли и можно без нервов сделать веб чуть безопаснее
Надо убедиться что
Для 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. Ибо нефиг
Написал свою версию плагина для Libravatar — Libravatar Replace. Точнее, пришлось форкнуть оригинал, т.к. автор упорно молчал на мои попытки связаться. Сначала я добавил все дефолты Либраватара в список, а потом понеслось
Фичи:
Очень интересный и полезный момент сегодня всплыл в комментариях на Хабре. В 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 — имейте это в виду. Потому что, кажется, больше нигде про это узнать невозможно — ни в одной из читанных мною статей по генераторам не было ни слова об утечке ресурсов.
Сервис-заглушка для системы Libravatar. Позволяет использовать одну картинку формата png для домена. Думаю, большинству этого вполне хватит :)
Стырить как всегда можно из моего репо для мелочей — bitbucket.org/sunchaser/miscellaneous
Как бы ответ на мои молитвы и проклятия появился сервис 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