Asadar, folosind Perl si numai expresii regulate am facut un script de cateva randuri care incearca sa reduca marimea unui fisier javascript. Scriptul recunosc ca nu e cel mai bun, in unele cazuri modifica si ceea ce nu trebuie, in special in interiorul unor stringuri (dar nu sunt chestii foarte grave ce pot afecta codul).

use strict;
use warnings;

my ($filename) = @ARGV;
my @trace;
print $filename;
$filename =~ /^(.+)\.js$/;

my $filename_min = $1.".min.js";
open(FM, "> $filename_min") or die "Could not open: $!";

while(<>) {
 chomp;
 s/^\s*//; s/\s*$//; s/\/\/(.+)//;
 if (/\/\*/) { push @trace, 1; s/\/\*(.*)//;}
 if ((@trace > 0)&&(/(.*)\*\//)) { s/(.*)\*\///; pop @trace;}
 else { if (@trace > 0) { s/(.*)//;} }
 s/(?<=[-\$\+\(\)=\:&\?\{\}\]\[\|;<>])\ (?=([\w\d]))//g;
 s/(?<=([\w\d]))\ (?=[-\$\+\(\)=\:&\?\{\}\]\[\|;!<>])//g;
 s/(?<=["'\$\-\+\(\),=\:!&\?\{\}\]\[\|;])\ (?=["'\$\-\+\(\),=\:!&\?\{\}\]\[\|;])//g;

 print FM $_;
}

close(FM) or die "Could not close: $!";

Nu sunt exper in Perl, asa ca e posibil sa nu fie cel mai frumos cod, dar isi face cat de cat treaba. Dar ce face mai exact? Citeste fisierul javascript de la linia de comanda, il deschide, face noul fisier la care ii adauga denumirea .min, si apoi preia rand cu rand continutul din fisierul original. Fiecare rand e curatat de spatiu inutil, comentarii si alte lucruri de acest gen, iar apoi scoate spatiile dintre caracterele - $ + ( ) = : & ? { } ] [ | ; < > si caracterele alfanumerice, precum si spatiile dintre caracterele " ' $ - + ( ) , = : ! & ? { } ] [ | ;.

Nu am facut nicio verficare, pentru ca s-ar presupune ca corect scris codul si nu e cazul. Daca cineva crede ca ii e folositor sciptul, foarte bine, daca poate sa il inbunatateasca si mai bine. Dar daca vreti sa curatati fisierele javascript pentru un proiect, mai bine folositi JSMIN.

PS: E misto sa faci un script fie folosind Perl, fie folosind direct JSMIN prin care automat micsorezi toate fisierele js ce le ai intr-un folder, le unesti si voila, nu mai trebuie sa faci asta manual plus ca mai bifezi un punct din lista de Best Practices de la Yahoo Developer Network.

Probabil pentru ca nu prea au fost folosite in trecut, cei de la Wordpress probabil au uitat de ele, astfel, cei ce folosesc caracterele corecte pentru s si t (cele cu virgula sub) pot avea unele probleme.

Am incercat sa fac un plugin, dar nu am reusit sa-l fac sa mearga si pentru slug-urile de la categorii si taguri, asadar postez aici o solute mult mai simpla:

• deschideti wp-includes/formatting.php
• cautati “/Euro sign” sau functia “remove accents” (in ultima versiune de Wordpress, randul 277)
• adaugati cele 2 linii de cod deasupra “/Euro sign”:

chr(200).chr(152) => 'S', chr(200).chr(153) => 's',
chr(200).chr(154) => 'T', chr(200).chr(155) => 't',

Acum nu ar mai trebui sa aveti probleme cu ș si ț.

Edit: Nu folositi aceasta metoda daca aveti deja posturi, categorii si taguri ce contin caracterele ș si ț (asta daca nu vreti sa le editati pe toate), o solutie: aici.

Este vorba de o solutie simpla si home-made de a face cache la anumite date in PHP. Cel mai simplu exemplu ar fi urmatorul: ai o pagina cu un articol, pagina respectiva se modifica destul de rar, dar e accesata destul de des. Ce rost ar avea sa preiei/procesezi din nou informatiile de fiecare data cand e accesata pagina, cand ai putea sa salvezi datele si sa le trimiti direct catre partea ce se ocupa cu afisarea lor. Sper sa nu gresesc, dar daca am vorbi despre o arhitectura Model-View-Controller in PHP, practic sari in mare parte peste Model.

Stiu ca exista solutii gata facute pentru cache, majoritatea framework-urilor au asa ceva, exista un pachet PEAR pentru cache, dar cred ca e mai fun sa incerci sa faci unele chestii de unul singur, poti invata multe lucruri noi si poti sa controlezi fiecare aspect a ceea ce vrei sa realizezi.

Revenind acum la subiectul principal. Deoarece am avut nevoie de o solutie simpla de a face cache la anumite pagini, am facut cu ceva timp in urma o clasa destul de simpla ce permite sa stochez informatiile pe care le afisez, fara a le mai mesteca inca o data.

(1. Vreau pagina x) -> (2.1. Macina datele primite -> 2.2 Returneaza datele) -> (3. Afiseaza continutul)

Schema de mai sus putem spune ca e ceea ce se intampla in mod normal. Punctul 2. este de obicei cel care consuma si foloseste cele mai multe resurse. Cred ca deja se poate vedea directia pe care vreau sa merg. De ce nu am incerca sa scoatem punctul 2.1? Nu are rost ca acelasi proces sa se repete de foarte multe ori, mai ales cand datele returnate sunt aceleasi. Ce facem mai departe? Luam datele “macinate”, le salvam, iar data viitoare cand vom mai avea nevoie de ele, le luam direct din cache, fara a mai repeta inca o data procesul cel mai greoi.

Solutia a fost destul de eficienta pentru mine. Nu am testat chiar atat de serios si nu am testat eficienta decat pe un computer de test, dar rezultatul a fost destul de satisfacator.

Primele doua valori din grafic nu sunt reprezentative, deoarece am testat la rece sistemul, nici varful acela de la seria fara cache. Cu toate acestea, este clar ca la prima accesare, in cazul de fata, momentul in care s-au salvat datele in cache, timul de procesare si afisare a paginii a fost mai ridicat, dar pe parcurs, facandu-se media, se poate vedea ca solutia a fost eficienta.

Clasa are 3 metode principale: constructorul, get si set, care sunt prezentate pe scurt mai jos.

In constructor, in cazul in care exista date de configurare (directorul, timeout si active), luam datele si le salvam, apoi se verifica daca putem scrie in directorul in care salvam fisierele, daca nu se poate, nu se poate.

public function __construct($config = array()) {
		if (count($config)) {
			foreach($config as $var => $value)
				if (in_array($var, $this->config))
					$this->$var = $value;
		}

		if (!is_writable($this->dir)) {
			throw new Exception('Cache directory not writable.');
			$this->active = false;
		}
	}

set() e folosita pentru a salva datele. Se verifica daca id-ul este ok, mai verificam directorul in care scriem, verificam si daca putem sa scriem fisierul si salvam datele. Nimic mai simplu.

public function set($id, $data) {
		if (!$this->active)
			return false;

		$this->data = $data;

		if (preg_match("/(^[a-zA-Z0-9_-]{3,64}$)/", $id)) {
			$cache_file = $this->dir.$id;
		} else {
			throw new Exception('Invalid cache ID');
			return false;
		}

		if (!is_dir($this->dir)) {
			throw new Exception('Cache directory not available');
			return false;
		}
		else {
			if (!$handle = fopen($cache_file, 'w')) {
				throw new Exception('Cannot open file');
				return false;
			}
			else {
				if (fwrite($handle, serialize($this->data))===false) {
					throw new Exception('Cannot write to file');
					return false;
				}
				fclose($handle);
			}
		}

		return true;
	}

get() e folosita pentru a prelua datele de cache. Facem din nou niste verificari, daca fisierul exista si e valid (din punct de vedere al timeout-ului), preluam datele si le returnam.

public function get($id) {
		if (!$this->active)
			return false;

		if (preg_match("/(^[a-zA-Z0-9_-]{3,64}$)/", $id)) {
			$cache_file=$this->dir.$id;
		} else {
			throw new Exception('Invalid cache ID');
			return false;
		}
		if (($this->active)&&(file_exists($cache_file))) {
			if ((time()-filemtime($cache_file))>($this->timeout*60)) {
				unlink($cache_file);
				return false;
			}

			$this->data = unserialize(@file_get_contents($cache_file));
			$this->hit++;
			return $this->data;
		}
	}

Am sa postez si un mic exemplu, care poate parea cam greoi, ca si cum ai omora o musca cu pusca, dar nu mi-a venit pe moment o idee de un exemplu mai complex.

function salut() {
	$mesaj = "Salut, uite ora la care m-au executat :". date("Y-m-d H:i:s");

	return $mesaj;
}

try {
	$cache = new Cache();

	if (!$mesaj = $cache->get("f-salut")) {
		$mesaj = salut();
		$cache->set("f-salut", $mesaj);
	}

	echo $mesaj;
} catch (Exception $e) {
    echo 'Ceva n-a mers: '. $e->getMessage();
}

Clasa, impreuna cu un exemplu, poate fi downloadata de aici: PHP Simple Cache. Un exemplu live poate fi gasit aici, dar e cu doua ore in urma pentru ca am uitat sa setez fusul orar . In exemplul respectiv se poate vedea data la care a fost geneerat fisierul de cache, data se actualizeaza la fiecare 15 minute, adica la durata de viata setata in acest moment pentru cache.

In cazul in care cineva are sugestii, critici sau orice fel de comentarii, le primesc pe toate cu placere.

Ce legatura are asta cu titlul postului si ceea ce va urma mai jos? Nimic mai simplu. Majoritatea site-urilor din ziua de azi folosesc o structura a linkurilor cat mai sugestiva, in mare parte din cauza considerentelor legate de SEO, astfel, un link catre un articol despre cultivarea bananelor in America de Sud poate sa se prezinte in felul urmator:

http://www.example.com/articol/cultivarea-bananelor-in-america-de-sud/

Avantajele principale sunt date de faptul ca linkul pare foarte curat si usor de inteles pentru oameni si poate sa te ajute in cazul motoarelor de cautare. Pe langa exemplul general pe care l-am dat mai sus, pot sa existe multe alte versiuni si posibilitati de a folosi aceasta tehnica, in unele cazuri este des intalnit si un id numeric al articolului, linkul devenind:

http://www.example.com/articol/cultivarea-bananelor-in-america-de-sud-127538/

De ce se intampla asta? In momentul in care trebuie sa preiei elementul din locul in care il ai stocat, ai nevoie de un identificator unic al acestuia. In cazul in care sunt folosite baze de date, totul e relativ simplu si te folosesti de sistemul prin care ai o cheie unica ce se autoincrementeaza la fiecare element nou. In cazul in care se foloseste doar un id de acest gen poti da de linkuri de genul:

http://www.example.com/articol/218793/

http://www.example.com/articol?96735

Linkurile sunt mai scurte, dar nu foarte sugestive pentru un om pentru ca nu are de unde sa stie despre ce e vorba in pagina respectiva. Aceasta metoda, chiar daca este cea mai simpla si cea mai usor de implementat, din punctul meu de vedere lasa de dorit.

Revenind la cel de-al doilea exemplu, care e un compromis relativ bun intre celelalte doua variante, aceste, daca nu este implementat corect, poate duce la unele situatii comice si neplacute pentru unele site-uri.

http://www.example.com/articol/cultivarea-bananelor-in-america-de-sud-127538/

Revenind la exemplul prezentat mai sus, de multe ori cand se foloseste atat titlul curatat al articolului, cat si un id, nu se mai verifica ce apare in titlu, care este pus acolo doar din motive de forma, nu si de fond, astfel, o pagina despre eventualul imprumut FMI acordat Romaniei poate sa dea impresia ca e despre pretul bananelor, dupa cum arata si exemplele de mai jos:

http://economie.hotnews.ro/stiri-finante_banci-5367467-pretul-bananelor-a-scazut-in-raport-cu-valoarea-leului.htm

http://www.evz.ro/articole/detalii-articol/837528/Criza-producatorilor-de-odorizante-wc/

http://www.gandul.info/actualitatea/basescu-urmareste-cu-interes-fluctuatiile-de-pe-piata-bananelor.html?3927;3812675

http://www.realitatea.net/sindicalistii-din-domeniul-bananifer-in-greva_445547.html

Pe langa faptul ca poti schimba acel parametru dupa cum doresti, site-urile returneaza in mod normal pagina corect, chiar daca acela nu mai este un link-ul normal al respectivei pagini. Nu stiu daca acest lucru poate avea un impact in cazul unui google bombing, dar nu este  normal sa ai un numar nelimitat de linkuri incorecte catre o singura pagina.

Solutia in cazul de fata este sa se faca o verificare atat a titlului cat si a id-ului. Cei de la GSP, de exemplu, fac acest lucru iar in cazul in care schimbi titlul din link, te redirectioneaza catre pagina normala.

Metoda cea mai eleganta este, insa, folosirea doar a titlului curatat al paginii respective. Acest lucru este putin mai greu de realizat deoarece trebuie parcursi urmatorii pasi:

1. inlocuirea/scoaterea caracterelor neprietenoase (diacritice, caractere speciale, spatiu etc)
2. generarea unui titlu unic pentru fiecare element in parte (acest lucru se poate rezolva relativ usor cu o expresie regulata si una sau doua verificari)

Beneficiile acestei metode sunt relative la prima vedere, dar cu timpul isi vor face simtita prezenta:

1. daca folosesti un sistem unitar de organizare, poti crea o structura foarte simpla si usor de citit a intregului site
2. persoanele interesate pot afla dinainte despre ce e vorba in respectiva pagina
3. in cazul browserelor, introducand un cuvant din titlu sau link in bara de adresa, poti cauta foarte simplu prin istoria paginilor vizitate, gasind mult mai repede o pagina interesanta vizitata in trecut

Pe final, un lucru destul de important este acela ca in momentul in care si o singura litera sau cifra din link este schimbata, linkul in sine schimbandu-se intr-un link ce duce catre o pagina inexistenta, este foarte bine ca pagina sa returneze un mesaj de eroare 404.

Am insistat pe aspectul unor linkuri curate si usor de citit pentru ca mi-a ramas in minte ceea ce a spus un profesor in facultate: cu timpul, masinile (in cazul de fata, computerele) trebuie sa inteleaga si sa invete sa comunice in limbajul natural, nu omul sa invete sa stapaneasca limbajul masina.

Cam asa e in ziua de azi cu noi, cei ce ne castigam existenta din PHP. Cred ca de multe ori scapi mai usor daca spui cuiva ca pur si simplu lucrezi in Word sau Excel decat sa recunosti ca ai o relatie mai apropiata cu PHP-ul. Citind bloguri ce tin de programare si sectiunea dedicata programarii de pe reddit, iti dai seama ca pentru foarte multa lume PHP nu e altceva decat o gluma sau un motiv de a face misto.

De ce nu ia lumea PHP-ul in serios?

In primul rand trebuie sa lamurim un lucru. PHP nu e chiar un limbaj de programare, ci e un limbaj de “scripting” care e foarte usor de invatat si de cele mai multe ori te ajuta sa faci foarte multe lucruri foarte usor si intr-un timp destul de scurt.

Tocmai de aici vine problema principala. Oricine poate scrie un script PHP, toata lumea ofera pachete de gazduire ieftine sau chiar gratuite ce contine PHP+MySQL. PHP este astfel un limbaj extrem de accesibil si atragator chiar si pentru cei ce nu au experienta cu programarea. Nu vreau sa spun ca e ceva in neregula cu simplitatea si accesibilitatea PHP-ului, dimpotriva, e chiar foarte bine ca a ajuns sa fie chiar atat de raspandit.

Partea proasta la PHP e ca nu e un limbaj prea organizat, si intr-un fel iti cere si te implora sa scrii cod complet dezorganizat (nu exista un standard in denumirea functiilor, ordinea parametrilor la unele functii din aceeasi categorie e diferita de la o functie la alta samd) in care imbini partea de logica sau procesare cu partea de prezentare iar in goana de a rezolva problemele cat mai repede nimeni nu se mai uita la fond, pentru ca tot ceea ce conteaza e sa ai o aplicatie ce functioneaza.

Ce e de facut?

Dupa cum spuneam si mai sus, pentru ca este un limbaj destul de usor de stapanit, nimeni nu mai incearca sa citeasca carti despre PHP si, de obicei, nimeni nu citeste documentatia oficiala. PHP are una dintrele cele mai bune documentatii pe care le-am vazut pana acum. Cred ca fiecare aspect al acestui limbaj e documentat si discutat pe site-ul oficial.

Citind documentatia, citind carti si articole vei reusi foarte usor sa evoluezi incetul cu incetul in a scrie cod din ce in ce mai bun. Daca ma gandesc bine, mie mi-e si groaza sa ma uit in trecut la ce scriam acum 3-4 ani. Si acum mai am foarte multe de invatat iar daca deschid un fisier la care am lucrat acum o luna, stau si imi zic: “problema asta asta putea fi rezolvata mult mai bine asa…”. In programare tot timpul cred ca este loc de mai bine si in fiecare zi poti sa inveti si sa te perfectionezi.

Concluzia

Chiar daca este vazut ca un Visual Basic al internetului, PHP-ul cred ca e doar putin neinteles si nefolosit corespunzator. In orice limbaj poti sa scrii cod bun si in orice limbaj poti sa scrii cod mai putin bun. Eu trebuie sa recunosc, dupa ce am lucrat in C si Java, PHP-ul a fost un pas inapoi, cel putin cand vine vorba de “curatenia” codului. Incetul cu incetul poti sa ajungi la un nivel destul de ridicat si in PHP, trebuie doar munca si pasiune. Si daca (acum urmeaza lista clasica a aparatorilor PHP) Yahoo, Wikipedia, Facebook, Flickr, Digg, Wordpress etc. au reusit sa faca niste aplicatii solide, scalabile, la un asemenea nivel, noi de ce nu am reusi acelasi lucru, la un nivel mult mai mic, bineinteles.

Linkuri

PHP Best Practices – un ghid foarte bun despre cum se poate trece peste unele dintre problemele de design ale PHP-ului

Documentatia oficiala – stiu, am mai pus o data linkul in acest post, dar aici chiar chiar veti gasi tot ce vreti sa stiti despre PHP, de la exemple foarte bune pana la functii si instructiuni foarte detaliate.

Concluzia: nu poti parsa feedurile generate de Wordpress 2.1.3 (posibil si alte versiuni 2.1.*) din PHP. Dupa ce am facut upgrade la un Wordpress pe care testam, totul a mers perfect.

Edit:

N-a mers nici cu Python, folosind urllib si minidom. E ciudat ca feedurile cu probleme in PHP cu fopen sau file sunt deschise in 10-15 secunde, dar daca folosesti un socket, trimiti un request  HTTP, iei pagina, totul e mai rapid (si pentru feeduirle fara probleme) singura problema fiind ca, cel putin eu nu reusesc, nu merge sa parsezi datele xml primite.

Problema mea a fost intotdeauna faptul ca daca incep sa lucrez la ceva, automat imi va sari gandul la inca 2 sau 3 probleme ce tin de respectivul proiect. Bineinteles ca ma voi apuca in acest caz sa dezvolt ideile si intr-un final ajung sa lucrez la 3 chestii fara sa termin la timp niciuna din ele.

Fiind la inceput de drum, m-am gandit ca as avea nevoie de un Project Manager pentr a-mi organiza munca cat mai bine. Chiar daca online se gasesc o multime de site-uri ce te ajuta sa-ti organizezi fisierele, timpul si intregul proiect, eu m-am gandit: ce-ar fi sa-mi fac un project manager. Dezastrul ra pe cale sa se intample, nici n-am inceput bine proiectul si deja aveam planuri de cu totul altceva, ceva ce mi-ar fi luat cel putin o luna.

Unul dintre lucrurile pe care le-am invatat in ultimul an, lucrand, a fost faptul ca de multe ori trebuie pur si simplu sa treci peste pornirile mult prea creative si sa te concentrezi pe ceea ce faci. Nu spun ca trebuie sa privesti doar inainte si sa nu te gandesti decat la destinatie, dar uneori putin autocontrol nu strica.

Ah, daca sunteti si voi in cautare de un manager online bun, incercati Assembla.

In cazul in care aveti lucruri mai serioase de facut si nu aveti bani de licenta PDFlib, va recomand o clasa foarte simpla si foarte usor de folosit: FPDF. Singura problema este ca nu stie sa lucreze cu ş,ţ,ă,î si â. Se poate rezolva important un set nou de fonturi, din pacate procesul e destul de greoi.

Miercuri e primul colocviu, la Programare Orientata pe Obiecte, C++ fiind limbajul studiat. Exista doar o singura problema, nimeni nu s-a deranjat sa ne predea, la laboratoare am stat si n-am facut nimic legat de programarea pe obiecte si acum trebuie sa dam un test sau sa facem un proiect. Experiente neplacute am avut cu proiectele inca de anul trecut, tot la POO, dar de data asta la Java. Eu m-am chinutit 3 luni sa fac proiectul care ne-a fost cerut (un compilator), totul a fost ok, mergea pentru toate cazurile posibile si m-am trezit ca toti am primit aceeasi nota, eu fiind singurul care am facut proiectul complet si la subiect. Semestrul asta n-am mai facut nimic, sper sa ma descurc in cele 2 zile ramase. Chiar nu vad de ce mi-as bate capul la un proiect serios pentru scoala, mai ales cand nimeni nu iti apreciaza munca.

Noul an a inceput si cu o mica dilema. Sa reincep sa lucrez ca programator la firma la care am lucrat si anul trecut, sau sa incerc sa-mi canalizez forta de munca spre FifaRomania si inca 2 proiecte personale. In primul caz e vorba de un castig destul de bun si sigur, dar timpul pe care il voi acorda proiectelor personale va scadea foarte mult. In cel de-al doilea caz e vorba de posibile castiguri mult mai bune dar si foarte nesigure, pe langa asta voi face ce-mi place, nu ca nu mi-ar placea sa lucrez, dar e un alt sentiment cand lucrezi pentru tine.

Bafta tuturor in noul an!

1. Metoda folosita de WordPress si de alte moduri si pluginuri pentru diferite forumuri. Aceasta consta in generarea fisierului feed-ului in momentul in care userul il acceseaza. Sa luam un exemplu: ai fisierul rss.php, in interiorul lui pui headerul “Content-type: text/xml;…” si generezi continutul. Problema la aceasta varianta e ca de fiecare data cand un user iti acceseaza feed-ul, trebuie sa faci o interogare, asta in cazul in care iei datele dintr-o baza de date. In cazul in care ai 100 de abonati, fiecare face in medie 5 refreshuri pe zi, asta inseamna 500 de interogari in plus. Stiu ca nu e prea mult si ca in ziua de azi nu prea conteaza, dar ceva parca tot nu suna bine. Singurul lucru bun, dupa mine, e faptul ca ai un control mai bun asupra feed-ului, fisierul fiind genrat dinamic, poti face o statistica a accesarilor (iar mie imi place statistica) samd
2. Metoda folosita de unele forumuri mai cunoscute. Ce se intampla aici? Sincer nu stiu exact pentru ca nu m-am documentat preea bine, eu pana acum am folosit doar prima metoda. Ce cred ca se intampla? Se creeaza “fizic” un fisier xml ce e updatat la un anumit interval de timp, sau si mai bine, e updatat doar in momentul in care au fost adaugate noi obiecte ce vor fi preluate de feed. Diferenta fata de prima metoda? In cazul in care faci 6 updateuri pe zi ai doar 6 interogari.

Concluzia? Nu am inca una, astept saptamana viitoare sa mi se mai elibereze programul, sa am timp sa optimizez ambele variante si apoi sa le pun in practica pe FifaRomania.

LE: Am gasit si metoda 3, e o combinatie dintre cele doua de mai sus. Folosesti un fisier de cache ce contine feed-ul propriu zis, fisier pe care il updatezi doar cand ai facut un update la site, iar in fisierul rss.php poti sa faci statistici frumoase si alte nebunii iar apoi cand ti-ai terminat treaba, dai drumul si la feed.