Daily Archives: 27 September 2007

Web development the nomad way

While we’re talking about web development… If one tries not to write PHP, what alternatives would you recommend? I’m addressing this to people who are developing with web-frameworks. I’m aware of Django, Pylons, Jinja and Mako, I know about Rails. But in general on the shared hosting plans one finds no support for mod_python or mod_ruby, but just for mod_php and CGI. Not that these are new things, not that they are hard to implement, it’s just because the sysadmins are some lazy bastards. Don’t get mad on me if you’re a sysadmin — I know this because I was a sysadmin myself. En masse people use PHP and CGI, i.e. that’s enough. Who are they to be spoiled with Python and Ruby…

But that’s not a serious attitude. The other obstacle is that many of the python or ruby frameworks need shell access and availability of some commands to get installed and managed. The convenience in writing PHP is that the code may be taken, compressed in an archive and put on another server where it will be almost certain it will just work. Yes, there is for instance CakePHP, but it’s… PHP and I want a little rest from it. :)

I kind of like Jinja and Mako and I try out some little things based on them at home and I have worked on smaller projects with Rails. But I can’t say that a Rails project is something that one could just “deliver” at any hosting. It’s the same with python-based systems, if it’s not worse. So is there a way for me to use some template system or a more complex framework with python or ruby and to have such “portability”? Which of these “environments” is most “nomad”? And which one you would recommend?

What are you writing on? I’m not asking about writing from scratch or for customising a general CMS — these things are clear. If you give me some arguments with your recommendations, you’ll just rock ;)

Уеб-разработка по чергарски

Между другото, като стана дума за уеб-разработка… Ако човек опитва да не пише на PHP, какви алтернативи бихте препоръчали? Обръщам се към хората, които са разработвали с web-frameworks. Зная за Django, Pylons, Jinja и Mako, зная и за Rails. Но масово споделените хостинги не предоставят mod_python или mod_ruby, а единствено mod_php и CGI. Не за друго, не защото е трудно или пък защото е нещо ново, а просто защото сисадмините са мързеливи копелета. Да не ми наскачат сега админите — знам го, и аз съм бил админ. Масово хората ползват PHP и CGI, ерго това им стига. Как тъй ще ги глезим с Python и Ruby…

Ама това е върло несериозно. Другата пречка пък е, че много от frameworks на пайтън и руби изискват достъп до команден ред и наличие на някакъв набор от съответни програми за изпълнение. А това, което е най-удобно при PHP-писането е, че кодът може да се вземе, да се сплеска в един архив, да се занесе на друг сървър и ще е почти сигурно, че ще си тръгне и там. Има например CakePHP, но пък е… на PHP, а аз искам малко почивка от него. :)

Имам някакъв афинитет към Jinja и Mako и си пробвам разни малки нещица вкъщи с тях, работил съм по малки проекти и с Rails. Но не мога да кажа, че например проект на Rails е нещо, което може да се “занесе” в хостинг ей-така. При питонските системи си е същото, ако не и по-зле. Та има ли начин да пиша с някаква система за шаблони или по-цялостен фреймуърк на python или ruby и да имам такава “преносимост”? Коя такава “среда” е най-номадска, най-чергарска? И коя препоръчвате?

Вие на какво пишете? Не питам за писане начисто, не питам и за къстомизиране на готов CMS — тия неща са ясни. Ако пък и аргументирате предпочитанията си и препоръките, цена няма да имате ;)

WordPress и стандартните URI

Някои писаха вече, че излезе WP версия 2.3. Има доста нови неща, но това, което най-вече забелязват хората са вградените поддръжка на етикети (най-накрая, браво, браво, да не повярва човек, че най-накрая вече има етикети в основната инсталация) и автоматична проверка за обновления. Като казвам “най-накрая” за етикетите, имам предвид, че масово хората продължаваха да работят с категории, а не с комбинация от категории и етикети или само с етикети, защото чисто и просто инсталирането на приставка е нещо външно, нещо “приставено”. И доста често се избягва. Имам наум и друго — етикетите, колкото и удобни да са в някои случаи, все пак създават трудност в бложенето. Аз използвам етикети още откакто движех сайта си с Blosxom, но тогава комбинирането на етикети и категории правеше някак по-удобно писането и по-приятно описването на текстовете. Етикетите могат да отдалечат текстовете, да ги направят по-студени и по-надълбоко скрити. Особено ако се ползват без строга мярка.

Работата с етикети ме занимава от доста време, ще оставя темата за друг път. Има много неща, които могат да се кажат за ползването на етикети и други “модерни уеб2.0-неща” със и без причина. Малко наслуки мога да предположа, че навикът за ползване на категории при писане в WP ще свърши добра услуга на ползващите платформата. Понякога четенето по категории не може да се сравни с ровенето и в най-добре поддържаните етикети.

Това, което на мен ми прави впечатление в WP 2.3 обаче не са етикетите или пък проверките за обновления. В Друпал етикетите са нещо естествено присъщо, защото представляват просто един от видовете категории, а проверките за обновления също са включени в Drupal 6. По-интересното в WP 2.3 е, че най-накрая разработчиците са обърнали поглед към нормализирането на адресите. Досега адресите в една инсталация на WP бяха пълна каша.

Чисто чудо е, че някои смятат WP за блог-система, идваща с добре оптимизирани адреси. Чувал съм хората да казват даже, че “гугъл обича уърдпрес”, макар да е ясно, че нещата с търсачките не стават баш така. Много хора не обръщат внимание на това какъв им е адресът и как се формират URI при разлистване на сайта. Според спецификацията си URI се състои от име на сървъра, порт и път до ресурса. За порта е ясно, изписването на подразбиращия се 80-ти се пропуска от програмите. Името на сървъра също има малко вариации, изключая масовото залепяне на “www” отпред, което нито дава някаква информация, нито определя протокола, а само служи на някаква неразбрана от мен висша естетика. И остава последната част, която винаги може да бъде проблемна — пътят до ресурса.

В старите инсталации на WP едно и също съдържание може да се намери на огромен брой адреси. Първо е налице дублиране на съдържание в домейна и в поддомейна “www”. Много малко хора се сещат да поставят пренасочване към адреса, който искат да ползват. Ако ще се ползва даденият домейн, просто трябва в .htaccess-файла да се запише нещо от вида на:


<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
  RewriteRule ^(.*)$ http://example\.com/$1 [R=301,L]
</IfModule>

Ако пък някой много държи да ползва “www”, логиката е обратна. Не помня да съм виждал пренасочване от “www” към основния домейн при WP-блогове. Със сигурност има и такива сайтове, просто не ми е направило впечатление. Достъпни са и от двата домейна, без пренасочване. Не казвам че е нещо чак лошо, но дублиране на съдържанието никога не се толерира от индексиращите машини и едно от първите “правила” (ако има такива) при работата по структурата на сайта при SEO-диагностиката е именно откриване на дублирано съдържание и намиране на начин за премахването му.

WP не ползва .htaccess в основната си инсталация и най-вероятно пренасочванията се правят с изпращане на HTTP-заглавки от PHP. В новата версия 2.3 твърдят, че ако има пренасочване от .htaccess, то трябва да е в синхрон с настроеното в админ-панела на WP, иначе ще се пренасочва в кръг.

Другият проблем на WP бяха пътищата. Безброй различни пътища до едно и също съдържание — основната страница се дублира от /index.php, /index.php/, /?paged=1, /page/1/. Когато се отнася до отделна статия и особено когато са включени кратки адреси на базата на заглавието, тогава комбинациите май надхвърлят десет. Обратните свързвания (trackbacks) и емисиите (rss2, atom) също могат да са налични на различни адреси. И на всичкото това отгоре — почти всеки адрес е достъпен както със, така и без наклонена черта накрая. И цялото това многообразие може да се “стоварва” на търсачките с приставката за генериране карта на сайта. Смея да твърдя, че ако WP нямаше критичната маса потребители в цял свят, това поведение нямаше да се толерира изобщо от търсачките.

Тези дублирания на съдържание могат да се избегнат отново с добре обмислени общи пренасочвания в .htaccess. Идеята е не просто съдържанието да е достъпно от всеки такъв адрес, а да се намира всъщност само на един адрес и всички останали форми на адреса, различните конвенции за образуването му, да водят до това съдържание през пренасочване. С връщане на код за състояние “301”, “постоянно пренасочване”, “permanent redirect”. То казва на търсачките и настолните програми, че съдържанието не е тук, а на еди-кой си адрес. И точка. Браузърите пренаписват URI в адресното поле и обновяват отметките си, а търсачките прочистват индекса си и концентрират рейтинга върху адреса на пренасочване. Така трябва да бъде ;)

Всичко това изглежда е оправено в WP 2.3 с т.нар. “Pretty URLs“. Сред сайтовете по които работя и които поддържам има само един WordPress, който скоро ще обновя да 2.3. Ще се радвам, ако наистина в новата версия адресите са измислени читаво и не се дублира съдържание.

Честита версия 2.3 на всички, които се радват на WordPress и на предизвикателствата и възможностите, които дава свободният софтуер! :)