• drag and drop pentru taskuri
• control din tastatura

Drag and drop posibil sa nu mearga pe Chrome 3 (taskul zboara pe toata pagina, dar e plasat corect in momentul in care e dropped), numai pe versiunea 4, in rest pe Safari si Firefox e ok. Posibil ca pe Chrome 3 sa mearga aiurea pentru ca e putin cam tricky sa te joci cu jQuery UI cu elemente generate dupa incarcarea unei pagini.

La controlul din taste, sagetile stanga si dreapta dau calendarul inainte sau inapoi, T il aduce la data curenta, enter functioneaza acum la adaugarea unui element, u deschide lista cu taskurile Upcoming, D taskurile terminate si L cele pe care nu le-ai mai rezolvat.

Test it up.

Asadar, IntuDo este o mini-aplicatie online ce iti permite sa faci o lista de taskuri si sa o organizezi pe zile. Nu este ceva foarte complex, ci o chestie foarte simpla ce iti permite sa iti organizezi mai bine timpul si, intr-un fel, sa faci ceea ce ti-ai propus pentru ziua respectiva.

Am continuat sa lucrez la IntuDO mai mult dintr-o joaca, tot ce a trebuit sa fac a fost sa termin de implementat login-ul prin intermediul RPX, astfel ca oricine are un cont de Yahoo!, Google, Facebook sau alte servicii ce se bazeaza pe OpenID se poate loga, fara a fi nevoit sa-si mai faca un nou cont si sa mai tina minte o noua parola.

De ce ar folosi cineva asa ceva?

1. e o aplicatie foarte simpla
2. nu trebuie sa iti faci cont, te poti loga folosind Google, Yahoo!, Facebook, Openid etc
3. exista studii care spun ca in momentul in care ai scris un lucru, inseamna ca ti-ai asumat un angajamet, de aici rezulta ca vazand lista ta de taskuri iti va fi mai usor sa le duci la bun sfarsit

Pe lista mea de to-do pentru IntuDo sunt urmatoarele:

• drag & drop la elemente pentru a le schimba data
• posibilitatea de a-ti sterge complet contul si toate datele
• posibilitatea de a adauga mai multe identitati pe acelasi cont (Google, Yahoo! etc)
• subliste

Test & organize

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.

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.

Diferenta dintre un site si un program, cel putin dupa mine, este destul de mare. In unele cazuri poti lucra la proiecte ce ajung sa fie folosite si vizitate de zeci de mii de useri. Daca e vorba de magazine online, siteuri ce proceseaza si pastreaza date importante despre userii lor, siguranta ar trebui sa vina intotdeauna pe primul loc.

Daca cititi alte bloguri romanesti mult mai cunoscute, probabil ati observat o tendinta a site-urilor de la noi sa aiba anumite lacune cand e vorba despre securitate. De unde vine aceasta problema? Adevarul e ca, de multe ori, programatorilor nu prea le pasa, iar pentru asta sunt 2 motive:

• nu au destula experienta si nu sunt obisnuiti cu proiecte serioase, ei se multumesc cu faptul ca au reusit sa faca ceva functional
• nu au destul timp, iar asta se intampla de cele mai multe ori cand esti sub presiune si trebuie sa indeplinesti niste deadline-uri imposibile, astfel ajungi sa renunti la unele ce nu se observa atat de usor

In cazul PHP-ului, una din regulile de baza pe care le inveti citind manualul este sa nu ai niciodata incredere in ceea ce iti trimite utilizatorul. Nu vreau aici sa jignesc pe nimeni, dar adevarul este ca de multe ori se intmpla ca o persoana sa faca o eroare neintentionata, eroare la care programatorul nu se asteapta, pentru ca, sa fim sinceri, de multe ori cand lucrezi la o aplicatie si nu ai la dispozitie niste persoane care sa testeze si/sau persoane care sa lucreze la “usability” (scuze, imi scapa cuvantul ) vei ajunge sa construiesti ceva extrem de simplu de folosit pentru tine, dar foarte complicat de folosit pentru o persoana neinitiata.

Cel mai simplu este sa incepi cu lucrurile de baza, iar documentatia oficiala a limbajului/tehnologiei pe care o folosesti e punctul cel mai bun de plecare. Intotdeauna de acolo vei putea invata si vei gasi informatii reale si pe care te vei putea baza.

Voi reveni in urmatoarele zile cu exemple mai concrete.

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.