сряда, 12 май 2010 г.
SWF thumbnail
Днес открих начин и реших да го споделя. Тъп е, но върши работа с много, ама много криви писаници и идеята, че скрийншотовете ще се правят на windows машина.
За flv няма проблем- качвате си ffmpeg-dev, има php-ffmpeg в нета, дето работи с библиотеката и дава достъп до инфо, кадри и т.н. Не съм тествал 100%, но стъпките биха били с exec да се конвертира .flv до .avi, ако случайно не работи направо с .flv, и после да се действа от php. PECL е, та иска да не е на хостинг машина. .swf не работят с тоя начин.
Та... Ето и как става flv. Има проектче за четене на екран от IE през php. В phpclasses е първото, което излиза при търсене на screenshot. Теглите го. Слагате го на XP с WAMP примерно. Тук аз ползвам виртуална машина по Ubuntu. В администрацията на XPто давате Services и на Apache в log on позволявате "Allow this service to interact with desktop". Проектчето иска COM подръжка в php, но WAMP я има. Рестартирате Apache и може да правите screenshot от IE. Вече може да взимаме кадри от .SWF. Проблемът е, че повечето игри имат малко реклами, та... Ето един patch, който чака 30 секунди да се отиде на нормален екран:
В screenshot.class.php добавяме в класа горе
public $sleep=0;
Редактираме следната функция:
public function navigate( $url = 'about:blank' )
{
$url = ( $url ) ? $url : 'about:blank';
$this->IE->Navigate( ($url) ? $url : 'about:blank' );
$this->url = $url;
$time = time();
if ($this->sleep){
set_time_limit(100);
sleep($this->sleep);
}
while ( $this->IE->ReadyState != '4' and $time + 2 > time() )
{
$this->pump();
}
if ( $this->pump )
{
$this->pump( 1000 );
}
return true;
}
Тук мой е кодът за sleep.
Правим си shot.php, който ще генерира картинката.
require_once('screenshot.class.php');
class_exists('screenshot') or die('screenshot class does not exist.');
$screen = new screenshot(false, 768, 1024);
$screen->sleep= 30;
$screen->navigate('http://hot2.kefche.net/games/d67wtx.swf');
$screen->title('You can set custom titles too (and custom body if you want)');
$screen->position(0, 0);
$screen->screenshot();
$screen->output();
$screen->save('image.jpg');
$screen->quit();
unset($screen);
Вече имаме нещо, което в cron може да се вика с опашка и да прави картинки. Лесно се прави wrapper да записва картинките в thumb папка на основния сървър. Заради забавянето няма как да не се вика това чудо на 2-3 минути поне. Важното е, че поне е действащ начин.
Има и някакъв wrapper за Mozilla под Linux в phpclasses. Там пак ще трябва да се мисли изчакване. Не мога да го подкарам, защото нямам libxul под Ubuntuто. На клипче с демо вади shot, като в X стартира Firefox.
Намерих и трети вариант, дето с някаква сложнотия с 5-6 python пакета прави конвертиране на .swf в avi и после може да се ползва ffmpeg, но там ubuntu запецна на инсталацията на пакетите.
Най-вероятно ще ползвам нещо такова за система за upload на игри на games сайта. Ще видим... Сега няма време за това. Просто днес ми дойде да търся решение на проблем, който в google не намерих някой да е разрешил лесно или поне да го сподели. Беше си добра почивка за 3-4 часа от другите задачи.
Javascript компресия
Днес се сблъсках с проблема с компресиране на javascript за пореден път. Исках да сменя JSMin(http://www.crockford.com/javascript/jsmin.html) с нещо друго, защото е адски бавен. Първо тръгнах с опити с minify(http://code.google.com/p/minify/), но се оказа, че въпреки по-доброто свиване на кода дава грешки поради лошото си разчитане на:
- коментари с //
- нов ред използван вместо ; . Този случай е интересен и най-общо е свързан с деклариране на функция във функция или if - else.
Няма как да преправя целия prototype да има ; след край на такава вградена функция, та потърсих YUI compressor(http://developer.yahoo.com/yui/compressor/). Оказа се невероятно решение- 5-6 пъти е по-бърз от JSMin, оптимизира наистина максимално, не се появяват грешки. Проблемът е един- писан е на Java и иска да се инсталира, съответно не се подържа от хостинг машини, което мен не ме бърка реално поради домашния сървър. В моя случай си го инсталирах през Synaptic на Ubuntu за секунди. Вика се лесно:
- подава се с exec да минимизира кода. Аз лично не пускам обфускация.:
exec ('yui-compressor --type js --charset utf-8 -o [input_file] --nomunge [output_file]');
- подава се новия текст и се трие временния файл.
Съответно аз си пиша кеширано копие, за да не бавя всеки път подаването.
Та... Заключенията:
- JSMin е добър вариант за хостинг машини- бавен е и не оптимизира много, но не чупи кода
- Minify става за оптимизация на html и css перфектно, адски е бърз, за javascript засега се откажете от него. Даже inline кода в html се налага да се преправи, за да не гръмне, но там се пише малко код, така или иначе.
- YUI е най-доброто засега като скорост и резултат, иска самостоятелен сървър.
- коментари с //
- нов ред използван вместо ; . Този случай е интересен и най-общо е свързан с деклариране на функция във функция или if - else.
Няма как да преправя целия prototype да има ; след край на такава вградена функция, та потърсих YUI compressor(http://developer.yahoo.com/yui/compressor/). Оказа се невероятно решение- 5-6 пъти е по-бърз от JSMin, оптимизира наистина максимално, не се появяват грешки. Проблемът е един- писан е на Java и иска да се инсталира, съответно не се подържа от хостинг машини, което мен не ме бърка реално поради домашния сървър. В моя случай си го инсталирах през Synaptic на Ubuntu за секунди. Вика се лесно:
- подава се с exec да минимизира кода. Аз лично не пускам обфускация.:
exec ('yui-compressor --type js --charset utf-8 -o [input_file] --nomunge [output_file]');
- подава се новия текст и се трие временния файл.
Съответно аз си пиша кеширано копие, за да не бавя всеки път подаването.
Та... Заключенията:
- JSMin е добър вариант за хостинг машини- бавен е и не оптимизира много, но не чупи кода
- Minify става за оптимизация на html и css перфектно, адски е бърз, за javascript засега се откажете от него. Даже inline кода в html се налага да се преправи, за да не гръмне, но там се пише малко код, така или иначе.
- YUI е най-доброто засега като скорост и резултат, иска самостоятелен сървър.
вторник, 11 май 2010 г.
Правила на Google за оптимизация на сайтове
Вчера си инсталирах addon за Firefox за проверка на сайт по правилата на Google за оптимизация на скоростта на зареждане. Правилата са описани на Web Performance Best Practices.
Правилата са горе-долу същите като тези на Yahoo с техния YSlow, но са разширени. Има две противоречия с YSlow, които аз лично приемам за по-добри при Google:
- картинките да са на няколко домейна за паралелно четене от браузъра. YSlow приема това за проблем, тъй като много държи да има по-малко DNS заявки, а картинките, ако са 50-60, е добре да са на 3-4 домейна, та се минава максимума от 4 при YSlow.
- картинките да се задават с height и width. Това за YSlow е излишен html код, но реално е правилно да не се кара браузъра да гадае какво да изчертае, което би го забавило.
При Google се добавят и правила за изчистване на излишен css, проверява се той да е по-опростен с цел по-лесната генерация на дърво на css класовете. Тук си е мъчение за css кодера, но... Добавя се и правило за минифициране на html кода, каквото в YSlow липсва.
За тест оптимизирах Чочо и игрите и в момента и двата сайта са на 95 от 100 точки, което си е ок за мен, като включа, че:
- няма как да оптимизирам adsense и tyxo.bg
- имам излишен css, но той е основно правила за езици, които сега не са включени. Ще има бая да се пише, за да се прави css само с текущо зададените за активни езици.
- спрайтовете в сайта за игри, които се въртят до категориите, са 35 и честно ме мързи да ги гледам един по един за реални размери. При Чочо си играх.
Покрай тази оптимизация се наложи да сваля PHP5 Minify и леко да го променя. Просто не искам да работя с GET параметър и така да подавам файл, който да се минимизира, та съм сложил 2-3 допълнителни реда в библиотеката, както и съм разписал викане на функциите й от главния скрипт на сайтовете.
Оптимизацията на сайтове вярно ми е мания, но е важна. Винаги е добре да спестиш малко трафик(При голям сайт ти изяжда главата с такси за линията.), както и потребителите да имат чуството, че сайтът хвърчи. Не е добре сървърът да подава страница за секунда-две(Онлайн магазините с Zen и OSCommerce са типичен пример.), не е и добре да подадеш html за 0.00Х секунди и след това да се зарежда другото съдържание 10 секунди.
Правилата са горе-долу същите като тези на Yahoo с техния YSlow, но са разширени. Има две противоречия с YSlow, които аз лично приемам за по-добри при Google:
- картинките да са на няколко домейна за паралелно четене от браузъра. YSlow приема това за проблем, тъй като много държи да има по-малко DNS заявки, а картинките, ако са 50-60, е добре да са на 3-4 домейна, та се минава максимума от 4 при YSlow.
- картинките да се задават с height и width. Това за YSlow е излишен html код, но реално е правилно да не се кара браузъра да гадае какво да изчертае, което би го забавило.
При Google се добавят и правила за изчистване на излишен css, проверява се той да е по-опростен с цел по-лесната генерация на дърво на css класовете. Тук си е мъчение за css кодера, но... Добавя се и правило за минифициране на html кода, каквото в YSlow липсва.
За тест оптимизирах Чочо и игрите и в момента и двата сайта са на 95 от 100 точки, което си е ок за мен, като включа, че:
- няма как да оптимизирам adsense и tyxo.bg
- имам излишен css, но той е основно правила за езици, които сега не са включени. Ще има бая да се пише, за да се прави css само с текущо зададените за активни езици.
- спрайтовете в сайта за игри, които се въртят до категориите, са 35 и честно ме мързи да ги гледам един по един за реални размери. При Чочо си играх.
Покрай тази оптимизация се наложи да сваля PHP5 Minify и леко да го променя. Просто не искам да работя с GET параметър и така да подавам файл, който да се минимизира, та съм сложил 2-3 допълнителни реда в библиотеката, както и съм разписал викане на функциите й от главния скрипт на сайтовете.
Оптимизацията на сайтове вярно ми е мания, но е важна. Винаги е добре да спестиш малко трафик(При голям сайт ти изяжда главата с такси за линията.), както и потребителите да имат чуството, че сайтът хвърчи. Не е добре сървърът да подава страница за секунда-две(Онлайн магазините с Zen и OSCommerce са типичен пример.), не е и добре да подадеш html за 0.00Х секунди и след това да се зарежда другото съдържание 10 секунди.
понеделник, 10 май 2010 г.
Как да не си чупим сървъра с thumbnail-и
Ето и статийка за това как може да правим разни ефекти с картинки или thumbail-и без товарене на сървъра излишно. Усетил съм, че тази тактика помага за запазване на добри отношения с админите.
Обикновено заради оптимизация на скоростта на зареждане от браузър и съответния YSlow рейтинг, пращане на thumbnail-и, watermarking, разни ефекти по картинките и такива благинки ни се налага да слагаме в страниците си показване на картинка през скрипт. Това е много ефективно, но троши процесора. Решението е просто и е в две части:
1. Редактираме леко .htaccess
Options +FollowSymLinks
RewriteEngine On
#Без mod_rewrite не минава
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule .? - [S=40]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .? - [S=40]
#Предното при наличен файл не минава в rewrite и се подава направо наличния файл
RewriteRule ^pics/([a-z0-9]*)/(.*)$ /thumb.php?size=$1&fn=$2 [B,L]
#С това правило после ще викаме скрипта за resize
2. Правим малък скрипт за resize на php, който най-общо ще прави resize по параметър за търсена ширина.
$size= intval($_GET['size']);
if (file_exists($_GET['fn'])){
if (!is_dir('pics')){
mkdir('pics');
chmod('pics',0777);
}
if (!is_dir('pics/'.$_GET['size'])){
mkdir('pics/'.$_GET['size']);
chmod('pics/'.$_GET['size'],0777);
}
$p= dirname($_GET['fn']);
$p1= basename($_GET['fn']);
$arr= explode('/',$p);
$pp= '';
foreach ($arr as $value) {
$pp.= '/'.$value;
if (!is_dir('pics/'.$_GET['size'].'/'.$pp)){
mkdir('pics/'.$_GET['size'].'/'.$pp);
chmod('pics/'.$_GET['size'].'/'.$pp,0777);
}
}
$image = $_GET['fn'];
$im = new Imagick();
$im->pingImage($image);
$im->readImage( $image );
$height=$im->getImageHeight();
$width=$im->getImageWidth();
$h= round($height*($_GET['size']/$width));
$im->resizeImage($_GET['size'],$h,Imagick::FILTER_LANCZOS,1);
$im->writeImage( 'pics/'.$_GET['size'].'/'.$_GET['fn'] );
$im->destroy();
$fsize = filesize('pics/'.$_GET['size'].'/'.$_GET['fn']);
$file_path= 'pics/'.$_GET['size'].'/'.$_GET['fn'];
$fsize = filesize('pics/'.$_GET['size'].'/'.$_GET['fn']);
header("Content-Type: image/jpeg", true);
header("Content-Length: " . $fsize, true);
echo file_get_contents($file_path);
}
Скриптът взима за параметър пълен път до оригиналната картинка(от папката на скрипта нататък, де...), та си прави сам нужните папки.
Така... С помощта на mod_rewrite и imagick(GD също става) заменяме гадните два варианта:
<img src="/images/123/try.jpg" width="300"/> или <img src="/thumbs.php?width=300&file=images/123/try.jpg" /> с <img src="/pics/300/images/123/try.jpg" />. Сега ще си натоварим процесора само при първо показване, а няма да генерираме излишен трафик с пускане на изображение 1024х768, което да смалим в браузъра до 300 пиксела ширина. Елементарно е, но е невероятно силно оръжие за добрия web програмист.
Обикновено заради оптимизация на скоростта на зареждане от браузър и съответния YSlow рейтинг, пращане на thumbnail-и, watermarking, разни ефекти по картинките и такива благинки ни се налага да слагаме в страниците си показване на картинка през скрипт. Това е много ефективно, но троши процесора. Решението е просто и е в две части:
1. Редактираме леко .htaccess
Options +FollowSymLinks
RewriteEngine On
#Без mod_rewrite не минава
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule .? - [S=40]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .? - [S=40]
#Предното при наличен файл не минава в rewrite и се подава направо наличния файл
RewriteRule ^pics/([a-z0-9]*)/(.*)$ /thumb.php?size=$1&fn=$2 [B,L]
#С това правило после ще викаме скрипта за resize
2. Правим малък скрипт за resize на php, който най-общо ще прави resize по параметър за търсена ширина.
$size= intval($_GET['size']);
if (file_exists($_GET['fn'])){
if (!is_dir('pics')){
mkdir('pics');
chmod('pics',0777);
}
if (!is_dir('pics/'.$_GET['size'])){
mkdir('pics/'.$_GET['size']);
chmod('pics/'.$_GET['size'],0777);
}
$p= dirname($_GET['fn']);
$p1= basename($_GET['fn']);
$arr= explode('/',$p);
$pp= '';
foreach ($arr as $value) {
$pp.= '/'.$value;
if (!is_dir('pics/'.$_GET['size'].'/'.$pp)){
mkdir('pics/'.$_GET['size'].'/'.$pp);
chmod('pics/'.$_GET['size'].'/'.$pp,0777);
}
}
$image = $_GET['fn'];
$im = new Imagick();
$im->pingImage($image);
$im->readImage( $image );
$height=$im->getImageHeight();
$width=$im->getImageWidth();
$h= round($height*($_GET['size']/$width));
$im->resizeImage($_GET['size'],$h,Imagick::FILTER_LANCZOS,1);
$im->writeImage( 'pics/'.$_GET['size'].'/'.$_GET['fn'] );
$im->destroy();
$fsize = filesize('pics/'.$_GET['size'].'/'.$_GET['fn']);
$file_path= 'pics/'.$_GET['size'].'/'.$_GET['fn'];
$fsize = filesize('pics/'.$_GET['size'].'/'.$_GET['fn']);
header("Content-Type: image/jpeg", true);
header("Content-Length: " . $fsize, true);
echo file_get_contents($file_path);
}
Скриптът взима за параметър пълен път до оригиналната картинка(от папката на скрипта нататък, де...), та си прави сам нужните папки.
Така... С помощта на mod_rewrite и imagick(GD също става) заменяме гадните два варианта:
<img src="/images/123/try.jpg" width="300"/> или <img src="/thumbs.php?width=300&file=images/123/try.jpg" /> с <img src="/pics/300/images/123/try.jpg" />. Сега ще си натоварим процесора само при първо показване, а няма да генерираме излишен трафик с пускане на изображение 1024х768, което да смалим в браузъра до 300 пиксела ширина. Елементарно е, но е невероятно силно оръжие за добрия web програмист.
Сайт за игри
След сайта на chochoichocho.com реших да тествам новия CMS колко бързо мога с него да направя сайт от 0, та по Гергьовден си дадох следната задача- "Имаш CMS и колекция от игри, направи за ден сайт за flash игри.". Резултатът е games.dreamer79.eu . Не е нещо особено, но все пак за ден дизайн, prototype модулче за въртене на слайдшоу за top и нови игри, рязане на 20-30 картинки за sprite-ове, лек редизайн на темата от chochoichocho.com не се правят лесно.
Та... Ето го резултата:
Няма нужда пак да изреждам всичко за CMS, YSlow и т.н. Само администрация реално няма свястна, защото ми стига тази на позволени категории и езици от Чочо. Игрите си се взимат всеки час автоматично, та подръжка скоро това чудо на дизайнерската ми мисъл няма да види.
games.dreamer79.eu - сайт за игри за един ден.
Та... Ето го резултата:
Няма нужда пак да изреждам всичко за CMS, YSlow и т.н. Само администрация реално няма свястна, защото ми стига тази на позволени категории и езици от Чочо. Игрите си се взимат всеки час автоматично, та подръжка скоро това чудо на дизайнерската ми мисъл няма да види.
games.dreamer79.eu - сайт за игри за един ден.
Сайт на Чочо и Чочо
Това е реално четвъртият ми дизайн изобщо. За мен си е гордост- за първи път си харесвам резултата. Сайтът е достъпен на Чочо и Чочо party art services .
Дизайнът наподобява видяното в разни детски списания. Изцяло е измислен от мен. Използването на imagick позволява наистина интересни форми въпреки динамичното съдържание. Леко може да съм прекалил с различните форми, но все пак е сайт с таргет деца. Така имам огромно поле да си покажа какво мога. ;)
Ето и малко екрани от самия сайт:
Администрацията е вградена в сайта с неговия си дизайн. Реших, че така ще е бая по-удобно. Ето как изглежда самата тя:
Всички тези картинки изискват невероятно много обработка по принцип. За да е всичко по-бързо, използвах малък .htaccess трик- при налично копие на обработена картинка не се вика скрипт за генериране, а се подава вече готовата. Тази мания за щадене на процесора си остана от времето ми в host.bg и namerimi.com и propse.com. Още ми се чудят защо съм такъв маниак за оптимизиране за малки клиенти...
CMS е писан от 0. Реших, че искам да направя нещо на чисто, а и се поупражнявах да е по-usable всичко. Въпреки огромното съдържание- с игрите са над 18000 страници, всичко е тествано некеширано да излиза за 0.1 секунди максимум на лаптопа ми и сървъра за сайта(една двуядрена щайга на 2Mhz в ъгъла на хола ми, на която съм решил да качвам малките сайтчета, та сега там са 3), т.е. далеч от мощна хостинг машина. Кеширането е старото ми от namerimi и propse(Ах, тези проекти. Трябва да ги възродя някой ден...), като се стига до генериране на страници за 0.008-0.009 секунди въпреки промяната на части от тях. ;)
Казах на каква щайга е всичко. Домашната ми линия е 2Mb, постоянно се точи нещо, та... Дойдохме си на думата защо загубих половин ден да пиша псевдо CDN, който подава картинките през акаунта ми в host.bg. Все пак търсим СКОРОСТ. YSlow рейтингът малко страда от adsense. Без него е 98 от 100, с външните скриптове пада до малко над 70. Няма как. Как да не се похвали човек? Сложил съм специално за целта надпис за времето на зареждане най-долу.
Ами, това е за тоя сайт май. Още SEO няма как да му тествам. За всеки случай, за седмица и нещо работа толкова с нов CMS, CDN, обработка на 1000 картинки и т.н. И аз имам нужда от време за писане в блогове. ;)
Дизайнът наподобява видяното в разни детски списания. Изцяло е измислен от мен. Използването на imagick позволява наистина интересни форми въпреки динамичното съдържание. Леко може да съм прекалил с различните форми, но все пак е сайт с таргет деца. Така имам огромно поле да си покажа какво мога. ;)
Ето и малко екрани от самия сайт:
Администрацията е вградена в сайта с неговия си дизайн. Реших, че така ще е бая по-удобно. Ето как изглежда самата тя:
Всички тези картинки изискват невероятно много обработка по принцип. За да е всичко по-бързо, използвах малък .htaccess трик- при налично копие на обработена картинка не се вика скрипт за генериране, а се подава вече готовата. Тази мания за щадене на процесора си остана от времето ми в host.bg и namerimi.com и propse.com. Още ми се чудят защо съм такъв маниак за оптимизиране за малки клиенти...
CMS е писан от 0. Реших, че искам да направя нещо на чисто, а и се поупражнявах да е по-usable всичко. Въпреки огромното съдържание- с игрите са над 18000 страници, всичко е тествано некеширано да излиза за 0.1 секунди максимум на лаптопа ми и сървъра за сайта(една двуядрена щайга на 2Mhz в ъгъла на хола ми, на която съм решил да качвам малките сайтчета, та сега там са 3), т.е. далеч от мощна хостинг машина. Кеширането е старото ми от namerimi и propse(Ах, тези проекти. Трябва да ги възродя някой ден...), като се стига до генериране на страници за 0.008-0.009 секунди въпреки промяната на части от тях. ;)
Казах на каква щайга е всичко. Домашната ми линия е 2Mb, постоянно се точи нещо, та... Дойдохме си на думата защо загубих половин ден да пиша псевдо CDN, който подава картинките през акаунта ми в host.bg. Все пак търсим СКОРОСТ. YSlow рейтингът малко страда от adsense. Без него е 98 от 100, с външните скриптове пада до малко над 70. Няма как. Как да не се похвали човек? Сложил съм специално за целта надпис за времето на зареждане най-долу.
Ами, това е за тоя сайт май. Още SEO няма как да му тествам. За всеки случай, за седмица и нещо работа толкова с нов CMS, CDN, обработка на 1000 картинки и т.н. И аз имам нужда от време за писане в блогове. ;)
Начало
В този блог ще публикувам готовите си сайтове. Все още нямам време за портфолиото на моя си сайт, та...
Тук ще публикувам и някои идеи за web програмирането. В момента ме сърби да понапиша малко за оптимизация на скоростта на сайт чрез псево-CMS. Ще видим дали ще ми остане време. Днес съм на режим свободно.
Тук ще публикувам и някои идеи за web програмирането. В момента ме сърби да понапиша малко за оптимизация на скоростта на сайт чрез псево-CMS. Ще видим дали ще ми остане време. Днес съм на режим свободно.
Абонамент за:
Публикации (Atom)