Надоело мне, что этот мой второй аккаунт простаивает, буду писать сюда всё, что касается моей рабочей деятельности, IT, компов и прочего технарства. Короче говоря, это буду "Я в работе". Хочется уже общаться плотнее с технарями, чтобы самому поактивнее развиваться и, возможно, найти партнёров для ускорения развития моего детища, сайта "Ваш журнал путешествий".
Приглашаю в сообщество сайта на ЖЖшной площадке mytravelog_org.

Мой основной акк zmeygor посвящён всему остальному в моей жизни - путешествиям, фотографии, жизненной философии и мировоззрению и прочему.

Гуглю тут ради интереса дорвейную выдачу "buy cheap tramadol" и акуеваю.

На ПЕРВОМ месте простейший одностраничный сайт (NS Last Updated On:07-Jun-2009) с небольшим текстом в 2-3 абзаца, свёрстанном, судя по стилям mso* вообще в ворде, БЕЗ беклинков по Яху, БЕЗ всяких "закладок/директорий/каталогов" - вообще всё пусто (1-2 полудохлые ссылки из задниц не в счёт)!!! Либо они там только-только впулили все-интернетовскую проспамку, беклинки которых Яха ещё не нашла, либо ещё что-хз что (типа JS ссылок, которые Яха не палит), но это блин нет слов...
Каааааак они это сделали?
Нет, они определённо что-то знают про гугл такое, чего не знают все остальные 2.5 МИЛЛИОНА страниц...
Да.......................

у которых на всё один ответ - покупайте у нас VPS.
Подробно в моём основном блоге http://zmeygor.livejournal.com/38258.html

Ндя, дела невесёлые...

ReCaptcha
Несколько дней назад таки раскопал, почему у меня в форме регистрации журнала путешествий некоторые юзеры с IE6-7 получают ошибку "operation aborted" - потому что криворукие программеры из ReCaptcha для создания своего виджета начинают изменение DOM документа ещё до завершения его загрузки (т.е. делают всё тупо в момент загрузки скрипта). Ишак такого "надругательства" не терпит и у него случается экзистенциальный кризис. При этом (люблю я этих ребят), парни из Microsoft говорят, что это такая фича, а вовсе не баг. Хорошо, хоть в восьмёрке поправили... Но сейчас от этого не легче. Ладно, фигня, переделал создание рекапчи на AJAX API и всё стало нормально.

Написал багрепорт с описанием баги в багтрекер Zend_Framework (потому что пользуюсь ихней Zend_Service_Recaptcha для создания начальной разметки). Всё описал, всё сказал, что надо сделать, чтобы исправить. Сперва багтрекера для recaptcha не нашёл и бросил ссылку в ихнюю googlegroups, потом нашёл и багтрекер. Оказалось, что баг известен уже 4 месяца, но в рекапче, не смотря на вопли кустомеров, никто на его исправление и не чешется. Даже статус бага с new не изменили, что очень странно ибо проблема есть и довольно серьёзная - достаточно посмотреть гугл по ключевым словам recaptcha "operation aborted". Бросил им ссылку на багрепорт ещё вчера, но чот до сих пор никто не почесался. Собственно, это навевает на нехорошие размышления, что либо они там совсем зажрались, либо проект (полу)дохл (что очень странно, ибо его юзают в забугорье крайне активно). В любом случае, такой подход совершенно не радует и, не исключено, что скоро придётся искать альтернативу...

Ладно, идём дальше.
Занялся добавлением возможности задавать маршрут путешествия с помощью Google Directions, т.е. когда ты гуглу даёшь координаты точек, а он их сам соединяет линией по автодорогам. Сделал... Начинаю смотреть результаты и.... прикольно.... Очень прикольно, потому что, например, круговой маршрут Финляндия - Норвегия - Дания - Польша - Прибалтика - Финляндия, сцуко, содержит 40 000 точек, и при использовании того метода сериализации, которым я пользуюсь сейчас (не самый эффективный, но простой) это даёт строку длиной 800 килобайт!!! Бл@@@@ааа!!! И даже если я поправлю кодирование, больше 10% я не добьюсь, а тут что 800кб, что 700 - один хрен.

Ну ладно, думаю, хрен с вами. Вспомнил, что в Dojo есть где-то реализация алгоритмов сжатия. Ну, думаю, "вот что спасёт отца русской демократии!". Нашёл LZW, зашибись! запускаю из консоли фаербага.... 10 секунд, 30 секунд, минута... Фаерфокс завис и зохавал себе ещё полгига памяти. Минут через 10 отвис, но результата так и не дал. То ли я чо не понял, как ихним компрессором пользоваться, то ли одно из двух. В любому случае, ну нафиг такие темы...

Короче, попал я с этими Directions по самое не балуйся. Теперь переделывать всю логику с ними (чтобы их асинхронно с сервера подгружать), убирать их из базы в файловую систему и ещё, по ходу, делать Polyline reduction, ибо 40 тыщ точек и 800кб это полный пездетц... А ведь обещал одному человеку, что закончу эту тему к концу уже той недели... да.....................................................

Брательник тут поделился адресочком:
Если ввести в адресную строку браузера zaebalo.com, то, что удивительно, магическим образом попадаешь на microsoft.com.

Я лично к Microsoft отношусь очень хорошо. Нет, даже Очень, с большой буквы. Ибо как минимум, чтобы создать и на достойном уровне поддерживать таких монстров, как Windows, - надо обладать очень ярким талантом и выдающимися способностями. А подобных монстров у них просто завались. А чтобы создать такого монстра, как сама Microsoft, надо быть выдающимся организатором. Впрочем, ладно, о Microsoft я уже и раньше писал, да и не о них сейчас речь...

Речь вот о чём. Трудящиеся передовики тамбовского совхоза "Светлый путь" меня тут просят передать уличному магу Дэвиду Блейну или хотя бы авторам это сайта свою огромную личную просьбу - перенастроить редирект на сайты президента, правительства, думы...

Вот что нашёл интересного про работу с картинками:
1) Developer's Image Library "DevIL" http://openil.sourceforge.net/ - кроссплатформенная библиотека для работы с изображениями на С.

Developer's Image Library (DevIL) is a programmer's library to develop applications with very powerful image loading capabilities, yet is easy for a developer to learn and use. Ultimate control of images is left to the developer, so unnecessary conversions, etc. are not performed. DevIL utilizes a simple, yet powerful, syntax. DevIL can load, save, convert, manipulate, filter and display a wide variety of image formats.

Мечта поэта, одним словом. Только название стрёмное :)

2) а проще всего без всякого гемора:
exec( "mogrify -geometry " . $defaultImgWidth . " " . "/dir/" . $imgName . " &" );
;)
Единственный минус - файл должен быть локальным (фигня), не каждый хостер может иметь эту софтину (ImageMagick) установленной, и производительность не ясна (впрочем, она вряд ли что сильно ухудшит). Но в целом - вполне себе вариант, поскольку судя по всему это ImageMagick - a must have tool для любой более-менее нормальной хост-площадки и многие CMS забиваются на его использование.

PHP 5.2.5:

Нашёл тестовые снимки мыльниц Canon PowerShot S70 и Canon PowerShot A400 (утверждалось, что они рушат php) и проверил работу скрипта - работает нормально, без проблем. Видать, таки, поправили.

Запихал в EXIF нули в поля с именами мыльниц и строковыми датами, проверил - нормально. Молодцы.

Переписал FFD9 в конце JPG на нули, проверил - выдаёт нотис и штатный falsе. Тоже правильный результат.

Подпихнул просто большую картинку (6Мб) с мем_лимитом 18М - пых, сука, сдох без всяких попыток к сопротивлению. Fatal error и хоть головой об стенку бейся. Вот о чём эти загребаны-разработчики пыха думали, когда вместо того, чтобы выпустить нотис и вернуть FALSE они сделали fatal error, который судя по всем попыткам (try-catch, set_exception_handler, set_error_handler, ob_start('fata_err_handler')) нифига ничем не ловится?! Мудаки безголовые. И ленивые, бо багу уже несколько лет, а исправить его скорее всего можно одной-двумя строчками. Десять лет расстрела с конфискацией...

В принципе, полученных результатов уже достаточно, чтобы сделать необходимый скрипт. Но "чо-то мне сыкотно" с такой ненадёжной хренью иметь дело. Тот тут баги, то там баги... Старая гнилая соломенная шляпа какая-то, а не серверный ЯП. Рискну потрать ещё немного времени и поискать алгоритмы ресайза на С/С++, чтобы вынести всю обработку картинок в отдельную бинарную программу и больше не парить мозх себе этой ботвой. Получится - гут, не получится, - сделаю всё на пыхе. В конце концов, по идее, больших картинок попадаться не должно...

Хочется долго и затейливо ругаться матом.

Надо решить задачу: в РНР уменьшить произвольную картинку с произвольного URL до заданного размера и сохранить в определённую папку.

Вроде бы всё очевидно и просто - есть набор функций, которые работают с картинками, ими и пользоваться. Но как всегда бывает с open-source если бы было всё так просто, это не было бы никому интересно. Поэтому если не читать только описания функций, а почитать ещё и коменты к ним, то окажется, что:

- imagecreatefromjpeg(), которая создаёт представление картинки для обработки может сбоить с определённым типом валидных jpg, например, с картинками, сделанными на старых Nokia. Поэтому требуется определённая предпроверка картинки, чтобы всё не рухнуло нахрен.

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

- бинарные данные в EXIF, которые в валидном jpeg там могу оказаться по ряду причин, могут обрушить функции обработки, поэтому прежде, чем скармливать картинку скрипту надо от EXIF избавляться. Для этого предлагается вызывать внешнюю программулину через exec(). Замерил скорость её работы - на боевом хостинге в лучшем случае четверть секунды работает на 6 меговом JPG. &$^%$. Нет, мне надо только одну картину обработать за один редкий запрос, но какого х^%#?


Ну и как это называть? Ненавижу этих уебанов, писавших GD. Тяп-ляп сляпали что-то и пох на остальное. Типа мы крутую штуку сделали, мы крутые! А вы, уроды-пользователи, гребитесь теперь как хотите!

Руки им оторвать, в задницу вставить и сказать, шо так и былО. Всё равно никто разницы не заметит.


Короче, судя по всему прямая дорога мне в расширение той внешней программулины - чо осталось то? Ресайз только прикрутить и всё...

Ищу быстрые алгоритмы ресайза картинок на С...

Опубликовал тут в ру-похапе предыдущий пост про кавычки, за что был вежливо и общественно попинаем. И поделом мне на самом деле, ибо, сцуко, оптимизировать надо лишь то, что реально жрёт ресурсы, а не сферических коней в вакууме, ибо в противном случае это не более, чем бездарное проёбывание времени на интеллектуальный онанизм.

Двести, блять, тысяч повторов... Сцуко, я - гений! Только где в реальном мире столько склеек найти, да чтобы для 10 переменных?!
Бля... Перфекционизм - зло, и зло лютое.

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

Хе-хе, вот это уже кое-что новенькое.

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

Я решил проверить, насколько быстрее, чтобы решить, стоит ли этим заморачиваться в операции типовой склейке строки из частей. Написал тест и результаты меня несколько удивили :) Двойные кавычки при склейке 10 переменных в строку работают заметно быстрее (примерно на 20-30%).

Вот код:

$aqwertyuiop='1234567';
$bqwertyuiop_134='qwer';
$cqwertyuiop='uyoiiuorutyr try wre';
$dqwertyuiop='csv dsfg fdg f';
$eqwertyuiop_dfsd='fsg fdsgdfsgsfdg';
$fqwertyuiop='12fgsd345df sd67';
$gqwertyuiop='12345 sfgsdfg fdg67';
$hqwertyuiop='12345fg sdffd67';
$ttr=200000;


$ts = microtime(true);
for($k=0; $k<$ttr; ++$k){
	$res = "This $aqwertyuiop is $bqwertyuiop_134 the $cqwertyuiop result $dqwertyuiop number $k of
 $ttr pass, $eqwertyuiop_dfsd running $fqwertyuiop with $gqwertyuiop single $hqwertyuiop quotes";
}
$dqtime = microtime(true)-$ts;
echo 'Double qoutes performance '.$dqtime.' sec<br/>';


$ts = microtime(true);
for($k=0; $k<$ttr; ++$k){
	$res = 'This '.$aqwertyuiop.' is '.$bqwertyuiop_134.' the '.$cqwertyuiop.' result '.$dqwertyuiop.' number '.$k.' of '.
		$ttr.' pass, '.$eqwertyuiop_dfsd.' running '.$fqwertyuiop.' with '.$gqwertyuiop.' single '.$hqwertyuiop.' quotes';
}
$sqtime = microtime(true)-$ts;
echo 'Single qoutes performance '.$sqtime.' sec<br/>';



$max = max(array($dqtime,$sqtime));
$min = min(array($sqtime,$dqtime));

echo 'delta is '.(($max-$min)*100/$min).' percents.<br/>'.($min == $sqtime ? 'Single' : 'DOUBLE!').' quotes is faster!';

От перенастановки местами результаты не меняются.

В принципе, в такой постановке теста, когда выполняется склейка строк, результат оказывается, если хорошо подумать ожидаем, но всегда ли мы хорошо думаем над типовыми и простейшими вещами?
Я вот, увы, над этим не задумывался, посему у меня много кода склейки строк в варианте "single quotes" выше...

UPD: при 1 переменной одинарные всё же немного быстрее, при 2 примерно одинаково, при трёх и более двойные стабильно в среднем быстрее.

Выводы озвучивать, думаю, не требуется.