WebXpo 2009 – моите впечатления
Остана ми малко време да пиша и за WebXpo 2009. Впечатленията ми от събитието са добри. Като за първа година имаше не малко посетители. Отидох там с приятелката ми на 5-ти към 13:00 часа. Стояме до към 15:30, защото се заприказвахме много с колегите от Abidos Design. Даже се водих към техния екип и присъствах на вечеринката в хотел „Райа“ след изложението. За което много им благодаря.
Най-голямо впечатление ми направиха колегите от SuperHosting. Поговорихме малко с г-н. Русанов. Успях да си изпрося тениска и ваучер за 80% отстъпка при закупуване на нов хостинг. Познайте кой си плати за 10 години напред нов акаунт при тях ;) Далаверата е наистина голяма, да не говорим, че заедно с HostBulgaria, са най-добрите хостинг компании в България, според мен. А нужда от хостинг винаги има.
Добри впечатления и от хостинг компания FColor. Поговорихме малко с господин Аврамов. Обсъдихме новата им афилиейт програма и контролния им панел, с който, да си призная, ми е малко трудно да свикна. Иначе от скоро използвам и техните хостинг услуги и впечатленията ми са добри.
Най-добро представяне на изложението WebXpo 2009 според мен направи Георги от Inspire Studio. Той ми е колега от университета. Беше се запасил с прожектор, много добре изработени стандартни рекламни материали и даже два вида значки с логото на компанията. Много оригинално наистина. Беше се постарал.
Очаквах да видя Огнян Младенов и представянето на SEO M, които трябваше по списък да са там. Изглежда Оги си е удължил почивката на морето. Нямаше как да мина на 6-ти да проверя дали има нещо различно, защото имах една среща и трябваше да се прибирам към Стара Загора.
Като цяло изложението беше добро. Ако има догодина, ще си помисля дори да участвам. Поздравления към Ованес за организацията.
Нов код за Referring Links? – търся съвет
Последният месец, моят инструмент за препращащи връзки Referring Links загуби голяма част от потребителите си. Причината е в хостинга – HostBulgaria изглежда имат огромни проблеми със сървъра DAO. Не само че инструментът започва да не отчита правилно, но се получава нещо друго, много по-неприятно – започва да бави зареждането на страниците на потребителите.
Разбирам всеки, който го е махнал. Дори мен самия ме дразни всичко това, но проблемът просто не зависи от мен. Знам какво бихте ме посъветвали – да сменя хостинга. Според мен това не е решение, защото сървърът рано или късно ще се оправи. Но трябва да намеря решение за случаите, когато сървъра го няма.
Много мислих, какви ли не гимнастики правих, но просто JavaScript е така проектиран, че трудно да се реагира на подобни проблеми. Затова мисля да прибегна към нещо, което силно се надявах да не правя – да променя кода за потребителите. Засега още го обмислям, но май натам вървят нещата. Естествено, старият код ще си работи.
Засега съм измислил това:
<script type="text/javascript">
var links = 7;
var banned = "example.com,someword";
var language = "bg";
document.write(unescape("%3Cscript src='http://referringlinks.com/script.js' type='text/javascript'%3E%3C/script%3E"));
</script>
Искам съвет от хората, които повечко разбират от програмиране – това правилно решение ли е? Обяснявам: След приемането на необходимите за скрипта параметри, чрез функцията write генерираме ново извикване на скрипт на следващо ниво. Когато сайта се зарежда, той изисква първо ниво.
То винаги се зарежда, защото не зависи от външния сайт (сайта на скрипта). Така следващото ниво се зарежда след зареждането на сайта или по-точно не зависи от зареждането на сайта и не го бави. На този блог в момента върви този експериментален код и дава доста добри резултати. Скрипта си хваща стиловете и си отчита.
Кодът си остава валиден спрямо W3C, JavaScript конзолата не дава никакви грешки. Ако сървърът липсва, просто нищо не се появява, като отново грешки не се генерират, нито се забава зареждането на сайта. Както казах, това е най-големият и досаден проблем в старата версия на кода.
Много сложно го обясних май, но той целият скрипт е една голяма сложнотия. Постоянно се появяват нови проблеми и предизвикателства. Мечтая си да го изкарам от Beta, но няма да е в следващите 3 месеца. Въпреки всичко съм оптимист за бъдещето на инструмента. Смятам, че ще го довърша все някога :)
Забележете, че има параметър за български език (bg). Скоро не само widget-а, но и сайта ще има и българска версия.
Referring Links.com – Добавено кеширане
Referring Links скриптът взе доста да товари хостинга, затова се принудих да добавя кеширане на изходните резултати. Задачата изобщо не беше лесна, защото кеширането не е стандартно, а трябваше да се кешират JavaScript файлове. Просто ситуацията не е много обичайна.
Както и да е – справих се някак си, въпреки че съм нов в PHP и главата ми още е омотана с някои други видове езици и стандарти. Базата данни на скрипта надмина 140,000 записа в най-голямата си таблица. Там се съхраняват IP-адресите на всички реферали през последните 30 дни.
Според мен проблемът в натоварването е именно заявката, която извлича и групира резултатите. По репортите от host bulgaria не може много да се разбере къде точно е проблемът, защото срещу SQL ми пише натоварване 0.0, а при мен друго, освен сложната заявка, не товари.
Сега всеки сайт си има JavaScript файл с рефералните му сайтове и посещенията от тях. Този файл се обновява веднъж на ден и се вика само той. Базата данни също се чисти веднъж да ден от стари данни. Това са реферали преди 30 и повече дни. Така системата прави заявки само при отчитане на нов реферал.
Тези заявки само добавят информация и са бързи. При подобни кеширания, обаче, има един момент в сигурността, който много често се отминава. Кашираният файл обикновено се отваря с PHP функцията fopen(). Налага ни се програма от вида: $handle = fopen(„path/to{$_GET['filename']}.html“, „r“);
Ако променливата ‘filename’ е замърсена, един нарушител може да обходи файловата система с вкарване на низове от рода: „../../../../another/path/to/file%00„. Днес не се бях сетил за това, а е много опасно. В последствие подсигурих с регулярен израз валидността на входните данни при подобен вид отваряния на файлове.
Сега остава да се оглеждам за бъгове след последните промени. До сега скриптът не е спирал да работи, въпреки коренните си промени, вече на няколко пъти и натоварването. Дано и за в бъдеще не се случват проблеми, които да наложат спирането му. Днес ограничих заявките към базата с около 100,000 на ден :)
