Иногда на сервере происходят сошибки типа "mysql server has gone away". Ошибка весьма досадная тем, что возникает она не всегда а только иногда. При этом, путем эмпирических действий удалось выяснить, что такое сообщение вызывается если PHP скрипт какое то время чем то сильно был занят и при этом не обращается к базе данных. Когда после некоторго периода бездействия скрипт, наконец хочет что-либо записать в базу данных то обнаруживается, что ссылка на соединение с базой данных уже мертва и все последующие запросы вылетают с ошибкой "mysql server has gone away". Понятно, что соединение с базой данных рвется по некоему таймауту, но вот по какому и как его увеличить?

Оказалось, что дело в переменной wait_timeout которая живет в /etc/my.conf. В моем случае она оказалась установленной в 30 секунд, поэтому, если во время выполнения скрипта между запросами оказывается промежуток более тридцати секунд - соединение рвется и больше не восстанавливается.

Изменить это значение можно либо поправив my.conf,  либо после установления соединения выполнив "SET wait_timeout=1000".

Заметил, что моя векторная библиотечка не хочет работать в восьмом эксплорере. При этом в Интернете вообще мало примеров работы VML которые бы оставались работоспособными в этом замечательном браузере. Даже на сайте Microsoft примеры VML которые прекрасно работали в шестой и седьмой версии напрочь отказываются работать в восьмерке.

При этом, вроде бы, иногда, что-то как-то работает в режиме совместимости, но не всегда, и только при определенных условиях типа наличия или отсутствия DOCTYPE и даже версии Service Pack.

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

И вот когда я уже почти собрался переделать код на вывод VML в отдельном iframe который бы работал только в режиме совместимости, я нашел код который работает всегда и всезде во всех режимах - это оказался все тот же raphael. Дмитрий Барановский нашел способ обуздать IE8 - весьма неочевидным и почти магическим способом он заставил это всё работать как надо.

Обновлил свой пример для работы c VML.

Набрёл на интересную бублиотечку для создания простых трехмерных визуализаций с использованием VML. Как следстивие использовазония VML работает это только в Internet Explorer. Интересно, можно ли малой кровью сделать для неё SVG реализацию чтобы она стала полностью кроссбраузерной?

После того, как фрактал в примере получился ну архи ме-е-е-е-е-дленным, решил немного исправить ситуацию. Все дело в том, что данную программку я написал как демо для объекта z.Canvas из z.Tools а z.Canvas - это на самом деле хелпер, который рисует графические примитивы при при помощи SVG и VML в зависимости от того, что доступно в текущем браезере. Идея была сделать именно холст, на котором можно было бы рисовать и в Internet Explorer и во всех остальных браузерах, ведь IE, как известно, до девятой версии не поддерживает SVG. Как следствие, каждый примитив на этом "холсте" будет занимать память, и если нарисовать фрактал из прямоугольников на холсте 300 на 300 пикселей, то компьютеру придется выделить память для девяносто тысяч маленьких объектов, само по себе это не сильно много, но всё равно, значительно тормозит весь процесс.

Переделать это дело на "настоящий" HTML5 canvas было делом нескольких минут, вот она, версия на Canvas, работает значительно быстрее и уже не жрет большого количества памяти.

Уже выложив, придумал, как ещё немного ускорить процесс рисования - сейчас, каждая точка рисуется в отдельном потоке через setTimeOut а это тоже страшно медленно - если делать без setTimeout процесс "подвиснет" пока не завершится рассчет фрактала, но можно сделать, чтобы рисовалась не точка но целая линия - это ускорит весь процесс без "зависания" процесса рисования.

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

Понадобилось посчитать дистанцию между двумя точками заданными в GPS координатах. В PHP реализация такой фунции выглядит следующим образом:

function calcMiles ($Lat1, $Lon1, $Lat2, $Lon2){
    return 3958.75 * acos(  sin($Lat1/57.2958) * sin($Lat2/57.2958) + cos($Lat1/57.2958) * cos($Lat2/57.2958) * cos($Lon2/57.2958 - $Lon1/57.2958));
}

Ответ получается в милях, для перевода в метры, полученное значение нужно ещё умножить на 1609.344.

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

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

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

Большое спасибо Александру Понамарёву за классный диалог выбора файлов, без него у меня бы ушло гораздо больше времени.

Ссылка на apk файл.

Я уже писал, что нужно сделать, чтобы заменить в коде Posix регулярные выражения, которые в PHP 5.3 стали deprecated, на Perl совместимые. Оказывается Rerl совместимые регулярные выражения поддерживают литералы используемые в Posix такие как [[:allnum:]], [[:space:]] и т.д. В одном месте чужёго кода заметил это, и вот дошли руки проверить на практике: конструкция вида preg_match('/[[:space:]]/','df d') работает идентично конструкции вида preg_match('/\s/','df d') т.е. совсем не нужно при замене ereg на preg_match заменять еще и литералы, достаточно добавить слева и справа слеши "/". Кстати кроме слешей можно использовать любой другой символ, например "#" это полезно когда в регулярном выражении уже есть слеши - чтобы их не экранировать и не ухудшать читаемость кода.

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

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

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

Вот исходный код скрипта.

Результат работы скрипта представлен в таблице ниже:

В тестовом скрипте, я сравнил обычные PHP функции, статические методы класса, обычные методы и методы синглетона.

Результаты тестирования показали, что вызов методов синглетона, примерно в два - четыре раза медленнее, чем вызов обычных методов, что, в принципе, меня порадовало — я ожидал, что будет хуже.

При этом выяснилось несколько дополнительных вещей: cтатические вызовы функций объявленных без модификатора "static" примерно в два раза медленнее, чем с ним, cтатические методы немного медленнее, чем динамические.

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

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

Предыстория такая - работаю над проектом, над которым потрудились индийские программисты. Сам проект сделан на движке Symphony - добротный такой движок, вполне приятный. В качестве библиотеки работы с базой данных используется Creole - тоже довольно приятная штука. В качестве ORM используется Propel — штука громоздкая, но тем не менее тоже весьма мощная и простая. Вообще Symphony показался мне весьма неплохим движком, весьма простым и удобным. Наверно, потому, что он почти один в один копирует Ruby on Rails - те же хелперы, тот же yml в конфигах, такой же подход к MVC - в общем очень похоже.

Так вот, доблестные индийские программисты, вместо того, чтобы использовать оснастку из Symphony навставляли везде mysql_connect и mysql_query. И все бы ничего, но mysql_connect у них вставляется ВЕЗДЕ перед mysql_query — в одном скрипте может быть создано несколько десятков соединений, а каждый mysql_query дополняется проверкой "or die(mysql_error())", поэтому любая ошибка в sql ведет к скоропостижной кончине всего скрипта.

Чтобы хоть как то исправить это безобразие я сначала удалил все mysql_connect. Затем, все mysql_query поиском и заменой заменил на собственную функцию, использующую оснастку creole, поместил её в глобально видимый класс myTools::query():

static function query($sql){
         $connection = Propel::getConnection();
         $r = $connection->executeQuery($sql);
         return $r->getResource();
}

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

Что это — глюк самого PHP или глюк Simphony я так и не понял, пришлось немного модифицировать класс MySQLConnection и добавить туда метод возвращающий MySQL ресурс непосредственно, минуя всякие PHP обёртки, но осадочек все же остался...