След като осъзнах, че имам нужда от поне 500 GB диск, на който да правя архив на по-важните си файлове, снимки и видео, започнах да търся какви дискове се предлагат. Отначало смятах да взема компактен външен диск, който да се захранва през USB порта. Предимството е, че лесно се пренася и нямаш нужда от допълнително захранване. Недостатък е, че бързо изхабява батерията на лаптопа. Най-евтините дискове с капацитет 500 GB бяха на цена от 170 лв нагоре в момента, в който пиша тази статия.

След това реших, че за архивиране на данни, не ми е нужна чак такава мобилност и започнах да търся нормален 3,5“ твърд диск, който да може да се постави във външна кутия за диск и със собствено захранване. Оказа се, че тези кутии се намират трудно и цената им е незаслужено висока. И така почти случайно открих, че има и още един вариант, който е с около 50-60 лв по-евтин.

Адаптер от SATA към USB

При използване на адаптер от SATA към USB, можеш да включиш обикновен твърд диск към USB порта без да го инсталираш в кутията на компютъра. Предимството е, че можеш сравнително лесно да включваш диска от един компютър на друг. В един момент, когато си позапълнил диска с данни и нямаш нужда да го разнасяш, можеш да си го инсталираш в кутията на компютъра. Единствения недостатък на адаптера е, че имаш няколко кабела в повече извън компютъра. С един кабел подобен на зарядно включваш диска към захранване 220 V, а с друг кабел, което е самия адаптер включваш диска към USB порта на компютъра. На първата снимка се вижда преходника от USB към SATA, всички кабели на снимката съм към комплекта и пристигат в кутията. Захранването отдясно е за диска заедно с късия четирижилен кабел с бял и черен накрайник. Останалите две части – черния и червения кабел са самия адаптер.

Скоростта на трансфер при прехвърляне на данни е над 12 MB в секунда при USB 2.0. Ако компютъра е стар и има само USB 1.1. порт, тогава скоростта е най-много 1.2 MB в секунда, но това е достатъчна скорост да пускаш филми с DVD качество директно от диска включен в USB порта. Към адаптера може да се включват и по-стари IDE дискове, но не съм го тествал още.

След като избрах този вариант започнах да правя проучване от кой онлайн магазин да си купя хард диск 500 GB и преходник от SATA към USB. Загубих час-два, докато накрая се спрях на два онлайн магазина, които предлагаха най-добра цена и най-добри условия по доставка, гаранция и обслужване.

От Euromall.bg избрах да купя следния 500 GB твърд диск SATA интерфейс.

Цена с доставка 99 лв. Гаранция 3 години. Поръчах го и платих при доставката. Евромол са сравнително нов онлайн магазин, който бързо се развива. Не бях пазарувал досега от тях, но съм доволен от цената и обслужването.

Адаптер (преходник) купих от друг онлайн магазин. Не бях купувал досега от там, но понеже цената не беше висока реших да тествам този магазин и дори предплатих с карта през epay.bg. Цена с доставка 26,26 лв.

Така за около 125 лв имам външен диск 500 GB, който работи чудесно. Много е тих и не загрява. Поставил съм го на бюрото отгоре. Кабелите съм ги скрил отзад зад бюрото, изглежда подобно на втората снимка. На третата снимка се вижда пълния комплект с включени всички кабели.

Голям плюс на избрания вариант е, че ти дава всички удобства на мобилен диск и освен това ти позволява, след като диска е почти пълен да го инсталираш в компютъра и да достъпваш данните с доста по-висока скорост.

Най-после се чувствам доста по-сигурен за данните си.

Форматиране на нов твърд диск SATA под Линукс

(Ако твоята операционна система не е линукс базирана не е нужно да четеш нататък.)

Дискът е със SATA интерфейс, свързан към USB 1.1 порт, чрез адаптер. Операционната система е Fedora, но на почти всички линукси дистрибуции командите са тези. В моя случай имах само USB 1.1 и затова форматирането отне доста време.

Това което се въвежда от теб от клавиатурата е в зелено, това, което изписва компютъра е в синьо, моите коментари са в черно.

Основните команди са само три: fdisk – промяна на дяловете на диска, mkfs – форматиране и fsck – проверка за грешки, като се подават подходящите параметри.

Първо напиши

$ dmesg

и в края на изведената информация ще видиш нещо като:

…

sd 26:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
sd 26:0:0:0: [sdb] Write Protect is off
sd 26:0:0:0: [sdb] Mode Sense: 28 00 00 00
sd 26:0:0:0: [sdb] Assuming drive cache: write through

най-важната информация е sdb – това е името на диска, при теб може някоя от буквите да се различава. Ако това е така ще трябва да промениш буквите и в следващите команди.

$ sudo fdisk /dev/sdb

[sudo] password for user:

въвеждаш паролата за текущия потребител user

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x88c0fb67.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won’t be recoverable.

The number of cylinders for this disk is set to 60801.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0×0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x88c0fb67

Device Boot      Start         End      Blocks   Id  System

Ако размерът на диска не съответства, значи си объркал името на диска и трябва да прекратиш с команда q.

Command (m for help): n
Partition number (1-8): 1

на следващите две стъпки просто натисни клавиша [Enter]

First cylinder (0-60801):
Last cylinder or +size or +sizeM or +sizeK (0-60801, default 60801):
Using default value 60801

Command (m for help): p

Disk /dev/sdb (Sun disk label): 255 heads, 63 sectors, 60801 cylinders
Units = cylinders of 16065 * 512 bytes

Device Flag    Start       End    Blocks   Id  System
/dev/sdb1             0     60801 488384032+  83  Linux native

Ползвам цялото свободно място, защото ще ползвам диска само за данни.

До този момент всичко се случва само в паметта и ако прекъснеш с команда q нищо няма да се промени. При следващата команда w промените се записват на диска.

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Следващата команда отнема много време. Над 2 часа за 500 GB диск при USB 1.1.

$ sudo mkfs -t ext3 /dev/sdb
mke2fs 1.41.4 (27-Jan-2009)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
30531584 inodes, 122096646 blocks
6104832 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
3727 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000

Writing inode tables: done
Creating journal (32768 blocks): done

На следващата стъпка натисни клавиша [Enter] и пак трябва да почакаш около минута.

Writing superblocks and filesystem accounting information:
done

This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Следващата команда също е много бавна за големи дискове.

$ sudo fsck -f -y /dev/sdb
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
Pass 1: Checking inodes, blocks, and sizes

Тази стъпка отнема много време – над два часа и половина за 500 GB диск при USB 1.1.

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

Тук чакаш още няколко минути.
/dev/sdb: 11/30531584 files (0.0% non-contiguous), 1966935/122096646 blocks

Готово. Може да тестваш с:

$ sudo mkdir /media/db

$ sudo mount /dev/sdb /media/db

$ df -h

трябва да ти покаже ред подобен на

/dev/sdb              459G  199M  435G   1% /media/db

Честито! Имаш още 500 GB място

За мен СПАМ е всяко едно неочаквано имейл съобщение, дори запитване дали може да ми пратят непоискано съобщение

Напоследък върлува следния досаден СПАМ със заглавие: „Въпрос от Бизнес Каталог България“ и текст:

Уважаеми Дами и Господа,
Бихме желали да поискаме разрешение да ви изпратим непоискано търговско съобщение.
Темата му е „Каталог Медия и Реклама 2010″
Ако искате да го прочетете, можете да посетите този линк …
Ако не желаете да получавате повече полезна информация от нас, можете да запишете Вашият мейл тук …
С уважение,
Бизнес Каталог България
02 421 40 44
www.cаtаlogbg.biz

office@cаtаlogbg.biz

office@bаzi-dаnni.com

Това съобщение се получава по няколко пъти в една пощенска кутия. На пръв поглед това е съвсем културно съобщение, но искам да ти обърна внимание, че подобна опция при която се записваш, че не желаеш да получаваш имейли е много опасна! Това е сигурен начин да покажеш, че този имейл не само е валиден, а се преглежда редовно от човек. След като натрупат солидна база данни с примерно 20 000 имейла, тази компания може да реши тайно да продаде тази база с имейл адреси и тогава наистина ще започнеш да получаваш много съобщения. Подобен сценарий се случва всеки ден по света. Трябва добре да познаваш фирмата, която стои отсреща и да и имаш доверие. Например Google.

Ако искаш да спреш да получаваш подобни имейли във всичките мейл акаунти на твоя сайт и ако използваш хостинг с cPanel, може да направиш това, като блокираш този изпращач да не може да ти изпраща повече имейли. Това се прави лесно.

Блокиране на СПАМ през cPanel

Влез в cPanel контролния панел на твоя хостинг, в секцията Mail избери “Account Level Filtering”. Натисни бутона [Create a new Filter]. В първото поле Filter Name: въведи някакво име, което да те подсеща за какво е филтъра, например bazidanni. В полето под „Rules“ в първия падащ списък остави избрано From, а във втория избери contains и в полето отдолу въведи bazi-danni.com. В падащия списък под Actions остави избрано Discard Message. Натисни бутона [Activate] и ще имаш филтър, който ще унищожава всички имейл съобщения, които съдържат в хедъра си From низа bazi-danni.com. От този момент няма да получаваш повече писма, от пощенски кутии, които завършват на @bazi-danni.com.

По подобен начин може да зададеш друг филтър, като например вместо From избереш Subject и като текст въведеш Viagra. По този начин ще бъдат изтривани автоматично писма с оферти за виагра.

Темата е доста обширна и тук е даден само бърз пример

Обикновено проблемите с бавни SQL заявки се дължат на грешно проектирана база данни, липса или грешно използване на индекси и най-често неправилно написани SQL заявки.

Статията разглежда няколко примера от практиката, които дават идеи за нов начин на писане на оптимизирани SQL заявки, при който не се прехвърлят много данни, за да се увеличи бързодействието.

Мониторинг на SQL заявки

На първо място препоръчвам на всеки използващ mySQL да ползва лог на бавните заявки. Активира се лесно и записва всяка заявка, която отнеме за изпълнението си повече от предварително зададено време (обикновено 10 сек.). Все пак не може да решиш проблем, ако не знаеш, че съществува
Използвай EXPLAIN пред SELECT за информация относно заявката – кой индекс се използва, колко реда се преглеждат и др.
За мониторинг в реално време препоръчвам mytop – приложение написано на Perl, което показва всички активни заявки и колко време отнемат.

Няколко бързи съвета за начинаещи

1. Ползвай колона id с атрибути PRIMARY и auto_increment за всяка таблица, дори да ти се струва, че никога няма да ти трябва.
2. Избягвай винаги „SELECT * FROM …“ вместо това пиши „SELECT col1, col2, col3… FROM …“ – изброявай нужните колони вместо да вземаш всички данни.
3. Никога не ползвай „SELECT (*) FROM …“, а пиши „SELECT (id) FROM …“, където id е колона с уникални стойности.
4. При създаването на таблицата създай индекси по всяка една колона, по която в бъдеще се очаква да сортираш данните или да извличаш данни като търсиш по стойност в тази колона.
5. Почти винаги т.4 е недостатъчна – трудно е да създадеш всички необходими индекси предварително. При написването на всяка нова заявка проверявай какви са колоните, по които се търси и провери дали има индекси по тях – ако няма ги създай веднага!
6. Ползвай сложни индекси. Ако имаш заявка, в която се търси по повече от една колона например съдържа „… WHERE user_id = 8 AND date > ’2010-01-01′ „, в този случай ако имаш отделни индекси по user_id и по date ще бъде автоматично избран и ползван само единия. Ако много често се изпълнява такава заявка (или си я открил в лога с бавни заявки) ти трябва сложен индекс по двете колони. Очаквай отделна статия по въпроса за комбинираните индекси.
7. Нормализиране на таблици. Тук няма да влизам в детайли, а само ще спомена, че ако в някоя колона имаш данни, които изглеждат като: „4,5,13,45,345″ – няколко стойности разделени със запетая, това почти винаги е знак за грешно проектирана база данни.
8. Когато свързваш две таблици трябва типа на колоните, по които се свързва да съвпада точно, например ако едната е от тип INT(8), а другата е от тип INT(11) може да се очакват проблеми.

Аксиома на gan за оптимизация на SQL

Стреми се да пишеш SQL заявките си така, все едно уеб сървъра и SQL сървъра са на различни машини – пренесените данни между двата трябва да са минимални!

Откриване на позицията на ред след сортиране на таблица

Нека да предположим, че имаме сайт за игра и има таблица за класиране UserTop с колони username и points, в която за всеки потребител се записва, колко точки е спечелил общо от всички игри. Колоната username съдържа уникални стойности. Пример за SQL таблица UserTop:

След приключване на всяка игра по потребителско име се намира реда за играча и точките му се увеличават с тези от последната игра. Нека да кажем, че в момента е логнат потребител ganbox и искаме да покажем на играча на коя позиция е в класацията. Затова трябва да сортираме таблицата по колона points в намаляващ ред и да видим на коя позиция се намира ganbox. Един начинаещ програмист ще направи следното:

Грешно решение:

Тук има няколко грешки:
1. Взема се цялото съдържание на таблица UserTop – може да бъде огромно количество данни.
2. На всяка итерация на цикъла for се оценява големината на масива $results.
3. След като е намерена и записана позицията в pos, цикъла не се прекъсва, а продължава да се върти безсмислено.
Не можете да си представите, колко много хора пишат по този небрежен начин. Затова много сайтове за игри работят отчайващо бавно при използване от много хора.

Следва малко по-добро, но все още неправилно решение.
Друго грешно решение:

Подобренията се виждат:
1. Избират се само данните от колона username – все още връща всички редове и данните са прекалено много.
2. Оценката на големината на масива е изнесена извън цикъла.
3. След откриване на позицията цикъла спира.
По точки 2. и 3. сме ОК, но т. 1 е голям проблем. Представи си, че уеб сървъра и SQL сървъра са на отделни машини – всички данни от колона username трябва да минат по мрежата, ако таблицата съдържа много редове и се ползва от много хора, това ще доведе до значително забавяне. Така стигаме до идеята, че тази задача трябва да се оптимизира, като обработката се изнесе към SQL сървъра.

Почти правилно решение:

Първо се изпълнява заявката в скобите, която връща точките на текущия играч (низа ‘ganbox’ трябва да се замести с потребителското име на логнатия играч). След това се вземат всички редове, които имат повече точки (включително тези които имат равен брой точки с играча) и се преброяват. Връща се едно единствено число – прекрасно!
Има един малък проблем. Ако има играчи с брой точки равен на броя точки на текущия адрес, позицията няма да е вярна. Затова:

Правилно решение:

Знакът е > защото в класация сортираме от по-голямо към по-малко.

.

Ако ти е станало интересно продължавай да четеш, ще усложним задачите с примери от практиката.
Нека освен таблица UserTop, която е класация имаме UserLog, в която в края на всяка игра се прави запис, като се записва време на приключване на играта и кой потребител колко точки е спечелил през последната игра:

Задачата е да подредим потребителите в класацията UserTop така, че ако няколко души имат равен брой точки по-напред да излиза този, който е играл по-скоро. В примера vox и ganbox имат еднакъв брой 250 точки, но vox трябва да излиза по-напред, защото е играл последен.

Сортиране на данни по два критерия в различни таблици

Заявката, която ще изведе играчите сортирани първо по брой точки, а тези с еднакъв брой по времето на последната активност:

Дотук добре. Сега освен страницата с тази класация искаме да показваме последните 10 действия – последните 10 играчи, които са играли. Там разбира се може да има повторения. Заявката е елементарна, но ни подготвя за следващата задача.

Забеляза ли, че не ползвам „SELECT * FROM“, а избирам тези които ми трябват (не го забравяй!).

Добре стигнахме до интересното. Следват два примера от практиката.

Откриване на класирането на играч в края на игра

Искаме в края на всяка игра освен да добавим запис в UserLog и да увеличим точките на играча в UserTop, да намерим новата позиция на играча в класацията и общия брой на точките му, за да може да му съобщим тези данни.

Правилно решение:

Вижда се, че ganbox е на 3-то място с 250 точки, а vox на второ пак с 250, но е играл по-скоро.
Заявката отново е супер оптимизирана според аксиомата на gan така, че да върне само нужните данни.
Използва вътрешна SQL променлива @num, която първоначално се нулира. След това се изпълнява вътрешната заявка, която написана отделно:

ще върне всички играчи в класацията с добавена колона с име pos, в която е позицията на всеки играч. По този начин външната заявка има задачата само да филтрира данните за играча, който ни интересува.

Откриване на запис отпаднал от последните 10 действия

Искаме още в края на всяка игра, да намерим кой играч е отпаднал на 11-място в лога (т.е. името му не се вижда вече в последните 10) и само ако името му го няма в първите 10 резултата да предприемем действие – например да го поканим да играе отново.

Как да решим тази задача? Можем лесно да вземем играча на позиция 11, както и да изведем всички от първите 10 позиции, но как да проверим дали този от 11-та се съдържа в първите 10?
Единия подход е с една заявка да вземем играча X от 11 позиция. След това с втора заявка да вземем потребителските имена на всички от първите 10, да ги заредим в PHP масив и да потърсим X в масива. Както вече се досети този подход не ми харесва, защото за 10 не е страшно, но ако са 100, а ако са 1000? Трябва ни отново оптимизирано решение с минимално прехвърляне на данни.

Правилно решение:

Тази заявка ще върне резултат:

Наистина ако сортираш UserLog от примера по време в обратен ред, someuser е на 11 позиция. Също така се среща на 6-та позиция и затова cnt е 1, като cnt показва не само дали се среща, но и колко пъти се среща в позициите от 1 до 10. По този начин предприемаш действие само ако cnt=0.

Това бяха само някои идеи за нов стил на писане на SQL заявки с цел оптимизиране на бързодействието. За пълнота ще спомена, че в много случаи отлични резултати могат да се постигнат при използване на кеширане на SQL заявки. Самото кеширане на заявки се програмира лесно. Трудното е да се определи в кой момент да се ползва кеш. Темата ще бъде разгледана в друга статия.

Всички SQL заявки са тествани и работят. Ще се радвам на коментари по темата.

И двата скрипта генерират аналогични бутони, които са най-адекватни към момента.

В новата трета версия са добавени бутони за Google Buzz, cenbg.com и uhaaa.net.

JavaScript плъгин за споделяне на линкове

Енкодинг UTF-8

Постави в твоя сайт HTML кода:

Енкодинг CP1251

Ако твоя сайт е с кодиране на текста cp1251, тогава използвай следната версия на скрипта:

Работещ пример има в сайта Речник на думите в българския език

WordPress плъгин за бутони за социални мрежи

Новата версия може да изтеглиш от връзката ganbox.com_sociable

Работеща версия има в този блог и бутоните се виждат в края на статията.

1. Ако вече ползваш стара версия на Sociable, за да инсталираш тази версия първо изключи стария плъгин.

2. Изтрий папката на старата версия от директория /wp-content/plugins на твоя сървър.

3. Разархивирай zip файла и качи папката sociable в /wp-content/plugins

4. Включи плъгина от списъка с Разширения в админ панела.

5. Влез в Настройки / Sociable и натисни бутона [Стандартни настройки подходящи за български сайтове].

Ако досега никога не си ползвал Sociable, за да го направиш изпълни само т.3 и т.4. Използването на този плъгин може да ти донесе линкове към вътрешни страници на твоя сайт и ще има добър SEO ефект.

Наскоро работих по сайта Речник на думите в българския език. В този сайт при търсене по някоя дума в дясната колона се зарежда блок с подобни думи. Подобните думи са такива, които се получават от търсената дума с добавяне, премахване или подмяна на една или две букви. За откриването на такива думи се използва алгоритъм с висока степен на сложност, който е бавен, защото претърсва цялата таблица с думи. Таблицата беше с размер около 100 000 реда и нарастваше и в резултат на това зареждането на страницата се бавеше до към 30 секунди – прекалено дълго време за уеб страница. Задачата ми беше да измисля начин за оптимизиране на бързодействието на сайта.

Решение

Първото, което направих е да опитам да оптимизирам SQL заявката. Ползваният алгоритъм не подлежи на оптимизация, затова се наложи да прибягна до някои дребни хитрости. Например търсене на подобни думи в ограничен набор от думи с дължина +/-2 спрямо дължината на търсената дума. Създадох някои допълнителни индекси на SQL таблиците и успях да съкратя средното време на около 8 секунди. Да чакаш цялата страница 8 секунди също е прекалено досадно и затова направих блока с подобни думи да се зарежда с Ajax. По този начин страницата се показваше веднага и само блока се бавеше, което беше напълно допустимо. Вече си мислех, че съм приключил, когато дойде писмо от хостинг доставчика, че се ползва прекалено бавна заявка, която бави другите сайтове на този споделен хостинг и настояваха да се оптимизира. Така стигнах до идеята, че данните за подобните думи трябва да се зареждат от отдалечен сървър. За да стане възможно това, трябва отдалеченият сървър да има същата таблица с думи в базата си данни. Направих автоматичен скрипт, който периодично да копира таблиците от единия сървър на другия. По този начин освен всичко друго се получи и още един архив на данните. След това оставаше да направя Ajax да се обръща към новия сървър. Тук отново има проблем: от съображения за сигурност Ajax не може да се обръща към домейн различен от този, на който се изпълнява. За да заобиколя това ограничение аз използвам следната програмистка техника: Ajax се обръща към скрипта similarClient.php разположен локално на сървъра на rechnik.info, който прави заявка към скрипт с име words.php на отдалечения сървър. Там се търси за подобни думи в копието на базата данни и намерения резултат се изпраща към similarClient.php, който го връща като резултат към Ajax. Към цялата система се добавя и кеширане на заявките, локално върху отдалечения сървър – този подход спестява дисково пространство на хостинга за сметка на увеличен трафик. При първото търсене в речника по дадена дума резултата се бави няколко секунди, но при всяко следващо търсене по тази дума, резултата се взема от кеш и става почти моментално. Всичко това може да изглежда малко сложно, но можеш да видиш колко добре действа в сайта на Речника.

Сигурност

Скриптът разположен на отдалечения сървър, който получава дума и връща списък с подобни думи е уеб скрипт и се извиква през HTTP. Това означава, че всеки който знае URL адреса и какви параметри приема, може лесно да използва това за свои цели и да прави заявки към сървъра. Използвайки горния метод, аз скривам URL адреса и това повишава сигурността многократно. Въпреки това е възможно връзката да бъде подслушана или логовете на сървъра да станат достъпни публично. Това ще разкрие URL адреса и някой може да се възползва. Затова един съвет: никога не разчитай само на сложен и таен URL адрес на скрипт!

Аз използвам допълнителни механизми за защита: отдалеченият сървър приема заявки само от IP адреса на rechnik.info. Това увеличава сигурността, но за съжаление не е напълно достатъчно, защото е възможно да пристигнат заявки с фалшифициран IP адрес. Следващиата стъпка е добавяне на кодиран параметър в GET заявката. По този начин URL адреса на заявката прилича на следния:

http://remote.domain.com/words.php?a=дума&code=a4b25d814f32b2c852c3d71d3

Низа подаван в променливата „code“, е кодирана от скрипта similarClient.php и само скрипта words.php знае как да го разкодира и да разбере дали е валиден. Резултат се връща, само ако стойността е валидна, в противен случай опита се записва и се съобщава на админ. За да може някой да хакне това, трябва да има FTP достъп до някой от двата php файла.Следващата стъпка е ползване на HTTPS вместо HTTP, но тук вече навлизаме в сферата на банковия софтуер

Сигурен съм, че много хора ще се запитат: „За какво е всичко това? Какво толкова защитаваш?“.

Нека да кажем, че се упражнявам Не обичам да оставям нещата на случайността и не правя компромиси със сигурността. Винаги изпипвам нещата и се подсигурявам двойно. Препоръчвам ти да се научиш да работиш по този начин.

SEO

Описаната система си има и недостатъци. От SEO гледна точка връзките в блока Подобни думи са невидими за търсачките. За да може сайта да се индексира добре е нужен или Google sitemap, или допълнителен блок с връзки като този със „Случайни думи“. Още по-добра работа би свършил блок със „Съседни думи“, в който за дадена страница връзките винаги да са едни и същи.