Django

Am scris de mai multe ori aici că mă jucam de-a dezvoltatul unui framework pentru aplicații web, scris în PHP. Aveam o grămadă de idei (le mai am și acum) și am petrecut destul de multă vreme gândind (și scriind cod) pentru asta. Totuși, cu cât m-am gândit mai mult, cu atât am dat de mai multe probleme (interesante, ce-i drept, de rezolvat). Zilele astea, pentru că am fost mai liber, am început să mă uit puțin la framework-uri opensource disponibile.

Am dat un ochi la Symphony, dar nu m-a prea atras. E drept, puteam să sap mai adânc, dar am ales să mă joc puțin cu Django, în schimb. Django este un framework (foarte) cul scris în python, care implementează toate ideile mele pentru yPHP and more, și le implementează exact așa cum mi-am dorit eu (și n-am reușit încă) pentru yPHP. În plus, python e un limbaj în care e absolut fenomenal să scrii cod (bine, aici Dan ar strâmba din nas și ar zice ca e total ne-eficient blah blah blah  :P).

N-am reușit să merg foarte departe, m-am jucat un pic doar cu o parte din componentele framework-ului, dar pare super-interesant. Și, deși comunitatea developerilor pe django / python pentru web este minusculă pe lângă comunitatea PHP, calitatea documentației este admirabilă.

Două chestii pe care vreau să încerc să le implementez sunt o interfață web pentru un gateway sms (Peticel pentru prieteni) și un mic proiect care să aibă de-a face cu google / yahoo maps. Revin cu detalii ;)

my latest creation is … under way :)

M-am obișnuit să comunic pe mail. M-am obișnuit să știu că, chiar daca nu mi se răspunde instant la mail, mailul meu este citit semi-instant. M-am obișnuit cu oamenii care au o oarecare unealtă care pândește în vreun fel căsuța de mail pentru mesaje noi. Well, cand am venit acasă și am început să fac chestii cu exploratorii (care sunt la liceu), povestea asta s-o terminat instant :P.

Am tot amânat o ieșire, vrem să mergem la Șureanu și să trecem la Sarmizegetusa Regia. Și de miercuri am amânat-o pe luni, și acum pe săptămâna viitoare. Cea mai frustrantă chestie nu a fost că am tot mutat ieșirea (în mare din cauza vremii, deși este și un pic de nehotărâre în aer) ci faptul că de fiecare dată toată lumea era dezorganizată, și nicicum nu reușeam să ajung la toți, la timp, cu anunțurile.

Așa că azi când am ieșit să mă plimb accidental-intenționat în direcția fast-food-ului favorit, am avut așa un flash. Mi-am amintit că pe vremuri foloseam foarte intens telefonul și mesajele să ne anunțăm de una și de alta. E drept, atunci grupul era oarecum mai omogen, mai apropiat ca vârstă și ca „practici”, motiv pentru care nu m-am gândit la asta înainte. Ok, telefon, SMS, dar … să dau eu de la mine toate mesajele alea? Să stau să mă asigur că n-am uitat pe nimeni … suna cam muncitoresc.

Așa că (mai aveam până la fast-food) mi-am amintit de Gammu, și de faptul că are bind-uri pentru python. Ceea ce suna foarte bine. Mi-am mai amintit și că al meu Nokia 3110 Classic nu este distrus, doar că nu poate fi utilizat pe post de telefon mobil de zi cu zi. Poate foarte bine să îndeplinească funcția de gateway SMS.

Am făcut câteva configurări, am săpat puțin, și ta-daaaa, am reușit să trimit, de pe server-ul permanent de acasă, prin telefon, un SMS. Momentan este doar un executabil care primește parametrii în linie de comandă, dar pentru utilizarea la scară largă mă gândesc să fac un server care să gestioneze trimiterea de mesaje, și să comunice pe partea cealaltă cu aplicația mea, scrisă în ce-o fi ea scrisă. Poate, pe viitor, o să adaug și suport pentru citirea mesajelor primite înapoi, ca să poți da comenzi prin SMS.

Având în vedere abundența de tzeavă spartă cu care Orange împarte cartele cu număr în ultima vreme, partea de număr nu a fost o problemă. Singurul meu gând pentru dezvoltare viitoare este gestiunea creditului, în așa fel încât server-ul să aibă întotdeauna o estimare a creditului rămas și a perioadei lui de valabilitate, ca să nu te apuci să trimiți mesaje, și să nu ți le trimită decât pe unele sau chiar deloc. Cred că asta se poate rezolva prin mesaj la Cronos și interpretarea rezultatului, dar încă n-am reușit să citesc mesaje de pe SIM.

A mai încercat cineva să se joace de-a serverul de SMS-uri acasă? Puteți să-mi recomnadați un plan tarifar pentru Orange care să-mi cadă bine? ;)

Aaaaa, și am uitat problema cea mai mare! De acasa la fast-food am copt ideea asta. De la fast-food până la terasă (cam aceeași distanță) m-am tot gândit ce nume să-i pun, să sune bine, dar să le placă și la copii. Nu știu de ce, m-am gândit la Peticel, dar nu mi se pare potrivit. Aș vrea să fie un nume propriu, preferabil românesc, să nu fie ceva de genu SMSReminder sau ceva. Dau o bere oricui vine cu o idee fezabilă :P

meeting JavaScript

Tema 3 la Interfeţe Evoluate ne-a cerut să scriem, folosind Javascript pentru scripting, un webbased thingie care sa faca highlight pe cuvinte / fraze dintr-o pagina web, încărcată dinamic (eventual folosind Ajax). Ceva foarte simplu, menit să ne familiarizeze, presupun, cu Javascript.

Eu fug de Javascript încă de la începuturile experimentărilor mele web-astice, pentru ca ce am văzut atunci arăta foarte foarte aiurea pentru mine. E drept, cred, ce se spune despre Javascript, că e un limbaj Ok de scripting, dar care e folosit în cel mai hidos mod. Acum ceva vreme era folosit pentru nenorociri de-alea de animaţii de prost gust, ceasuri ascii care fug după mouse şi alte nenorociri care nu au ce căuta într-o intefaţă bună.

Acum vedem însă tot mai puţine utilizări negative (cel puţin din punct de vedere vizual) a Javascript, şi tot mai multe exemple pozitive. Nu ştiu exact istoria, şi sunt sigur că o călătorie scurtă pe wikipedia vă poată lămuri mai bine ca mine, dar eu cred că Javascript a început să devină widely accepted ca un limbaj de scripting serios odată cu trecerea la Web2.0, care, printre alte calităţi, se defineşte prin interfeţe web mult mai responsive. Dezvoltarea Javascript-ului ca limbaj a permis Web2.0 să existe, şi, la fel, nevoia de creştere a calităţii interfeţelor a dus la dezvoltarea limbajului. Cele mai populare trăznăi ce le folosim azi, Gmail, Y!Mail, Noul WordPress, dar şi vechiul, aproape tot ce e Google-ish, toate folosesc la greu Javascript.

De ce avem aşa super nevoie de Javascript? Well, înainte de web2.0 şi de toată nebunia cu superinterfeţele web, problema comunicării cât mai responsive cu clientul se putea rezolva în două moduri. Prima strategie era cea locală (client-side scripting): aveai un script care încărca totul în pagina curentă, în javascript, şi atunci puteai interacţiona cu utilizatorul (să validezi date, să îi dai nişte opţiuni diferite în funcţie de alegerile pe car ele face …) într-o manieră limitată la informaţiile care existau la încărcarea paginii. Şi cum să trimiţi toate posibilităţile înseamnă cantitate mare de date şi cantitate mare de date e un big no-no pentru interfeţe web, interacţiunea era limitată.

A doua strategie (server-side scripting) implica de cele mai multe ori reîncărcarea paginii şi procesarea opţiunilor cu server-ul. Necazul era că şi pe legăturile rapide (gen intraneturi) se observa reîncărcarea paginii, iar pe legăturile lente (sau no, normale) asta devenea o problemă serioasă.

Toate problemele astea au primit o soluţie unică, elegantă şi foarte foarte folosită azi de toate aplicaţiile web ce le folosim frecvent: AJAX. Asynchronous Javascript And XML. Deşi tehnologiile care fac AJAX posibil există de prin 95, W3C a propus un draft pentru chestia asta doar în 2006. Ideea e relativ simplă, AJAX se bazează pe un obiect Javascript  (da, JavaScript e şi OO :P) care face o cerere HTTP către un server şi înregistrează un handler (o funcţie) care se apelează în momentul când cererea întoarce ceva sau dă un timeout. Răspunsul cererii se presupune a fi un XML, deşi din ce am încercat eu se poate folosi şi HTML ca răspuns, dar nu sunt sigur de alte tipuri de date.

Avantajul cel mare e că toată bucătăria se întâmplă în culise, utilizatorul are o experienţă fluentă, care seamănă cu experienţele cu interfeţe ne-web. Există şi limitări. Deşi, teoretic, se pot cere fişiere oricât de mari, având în vedere că totul se întâmplă peste un mediu care are performanţe variabile indiferent de locaţie, se preferă ca răspunsurile să fie minime. O limitare de securitate care am observat-o (nu ştiu exact când a fost introdusă) este că cererile XMLttpRequest (obiectul de care vă ziceam) nu pot fi făcute decât către serverul de la care a fost încărcată pagina care execută scriptul.

Desigur, problema asta se poate rezolva urgent cu un urlfopen pe partea se server, şi asta e mirific la AJAX, posibilitatea de a trece peste limitările iniţiale impuse de modelul Web prin pasarea lor către partea celalată (client <-> server).

Anyway, pentru cine este interesat, tema mea 3 la IE este aici. Si, ca sa o testati, puteti incerca sa folositi pagina asta şi asta :)

Am devenit mult mai interesat după tema asta să investighez mai îndeaproape JavaScript şi, mai ales AJAX pentru yPHP (pentru început, un modul de formuri dinamice şi de verificare a formurilor pentru început :P). Vorbind de tehnologii, am înţeles că jQuery (ăla de aici, nu ăla care ţine de baze de date şi Java) e util. Are cineva vreo experienţă cu trăznaia asta? I will give it a try, and post here on the results :)

XML Schemas şi yPHP

De câteva săptămâni, am introdus în yPHP (în cazul în care nu ştiţi, yPHP e un fel de framework – web application kit la care lucrez) fişiere de configurare externă pentru module (momentan, se pot defini acţiunile valide şi alte câteva setări de bază, dar aş dori să extind chestia asta şi la alte tipuri de configurări – rapoarte, liste şi, în special, form-uri). Fişierele de configurare fac foarte foarte mult sens, mai ales pentru ideea în care o să dezvolt la un moment dat şi o interfaţă grafică pentru construit aplicaţii yPHP sau măcar un API pentru cine vrea să facă asta.

Miercuri, Vlad Posea ne-a prezentat, în cadrul laboratorului de IE, XML Schemas, ca o alternativă la DTD. Eu începusem să fac un plan să folosesc nişte DTD-uri pentru XML-urile de configurare pentru modulele yPHP, dar DTD mi se pare (şi este) limitat din mai multe puncte de vedere (nu poţi specifica concret care câmp tre să vină şi în ce ordine). În plus, este un alt tip de fişier. XML Schemas în schimb, sunt fişiere XML. Mai tare, la laborator am descoperit că Eclipse (cred că de la WTP – Web Tools Platform) are un super editor grafic de XSD, de poţi să legi chestiile mult mult mai repede (XML Schema se bazează pe definirea tipurilor de elemente – simple (gen string) sau complexe – care pot conţine şi alte elemente sau atribute).

So, două chestii câştigate miercuri în două ore de IE: cunoştiinţe despre XSD şi o super unealtă gata instalată la mine pe comp pentru a le manevra. Veşti bune pentru yPHP :)