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
Webservices – Tema3 LPD
LPD (Limbaje de Programare Distribuită) este o materie de an V în facultatea noastră, pe care eu mi-am ales-o ca materie opţională, în mare pentru că am citit în descriere despre chestii gen Servlets şi Java Server Pages şi despre Webservices. În mare, o materie al cărei conţinut (din cuprins) părea cel puţin deosebit. Pentru mine, totuşi, materia asta nu s-a potrivit nicicum. Profesorul de la curs (Florin Pop) mi s-a părut aşa, plin de entuziasm pentru curs, dar cursul a suferit de plasarea în orar vinerea de la 8, aşa că entuziasmul meu nu a putut să fie la fel de mare. Din păcate, teaching assistant-ul cu care am facut laboratorul, un tip al cărui nume nu o să-l postez aici, era perfect pe dinafară. Laboratorul era nepregătit, el era nepregătit, nu aveau locuri suficiente pentru toată lumea. Am participat de câteva ori, şi am renunţat, chiar artistic, aş putea spune.
A treia mare problema a mea cu materia asta, şi unica pe care o chiar regret, a fost că deadline-urile pentru teme s-au potrivit exact peste date când eu aveam alte necazuri (în principiu, UP) şi nu am reuşit să mă ocup de ele cum ar fi trebuit. Se pare însă că o să am ocazia să revin asupra acestei probleme, în sesiunea din aprilie.
Anyway, era vorba despre Tema 3. Tema 2 la LPD s-a ocupat (printre altele) de utilizarea RMI pentru implementarea comunicării între diferitele entităţi. Tema 3 ne-a cerut implementarea unui serviciu web care să ofere unor clienţi posibilitatea să verifice rute de avioane şi să rezerve / cumpere bilete de avion (şi în plus, ceva prostii de administrare, non-interesting). Se cerea ca tema să fie implementată peste Apache Tomcat (5.5) şi Apache Axis (1.4).
Practic, un webservice pune la dispoziţia unor clienţi nişte metode pe care aceştia le pot apela folosind mesaje. Metodele disponibile se pot afla interogând endpoint-ul serviciului, iar mesajele care se pasează sunt în format XML (ceea ce, faţă de RMI, are imensul avantaj că acum participanţii într-o conversaţie pot fi scrişi în orice limbaj). AXIS este un webapp pentru Tomcat, care permite creearea on-the-fly a serviciilor web (automatizează procesul de deployment şi de publicare a serviciului). Practic, tot ce rămâne de făcut programatorului este să scrie o clasă java care implementează metodele pe care vrem ca serviciul să le pună la dispoziţie, şi Axis se ocupă de restul paşilor.
Paranteză: Well, evident, chestia asta sună all-to-familiar: API-urile puse la dispoziţie de aplicaţiile web suna a webservice-uri (Google API, YDN, flickr, twitter, infamul hi5, facebook ...). Well, sună a webservice pentru că asta sunt, de fapt. Diferenţa este că majoritatea API-urilor implementează un protocol de comunicaţie numit REST (RESTfull), pe când webservice-urile "serioase" - java + corporate, spre exemplu, folosesc SOAP.
Înafară de partea de webservice, tema 3 presupune gestionarea în fundal a unei baze de date MySQL cu informaţii despre zboruri. Câteva chestii de notat aici, conexiunile cu baze de date în Java sunt ceva mai rigide decât cu ce eram obişnuit în php, probabil şi din cauză ca Java e considerat un limbaj pentru aplicaţii mai "serioase" (deşi mie mi se pare o prostie ...). Partea de conexiune prin JDBC (Java DataBase Connectivity) este relativ simplă (4 linii :P), dar trebuie să ai un J-Connector de la MySQL (gratis). Totuşi, tema noastră ne cerea să facem uz şi de JDNI (care este o schemă de (re)găsire a chestiilor într-un Directory), pentru partea de serviciu.
Am aplicat ce am învăţat în dezvoltarea yPHP despre baze de date, despre maparea lor pe instanţe de clase, pe păstrarea sincronizării cu baza de date. Şi, am luat din experienţa temei 3 şi idei pe care vreau să le aplic (sau le-am aplicat deja, în parte) în yPHP, în special partea în care poţi avea mai multe surse de date, nu doar o bază de date MySQL, şi implementări de drivere pentru fiecare fel de DataSource.
Mi-e mult prea complicat să fac un deployment să vă arăt exact exact serviciul meu web în acţiune. Ce e important de ştiut (şi ce notez aici) sunt paşii care trebuie urmaţi pentru a putea face deployment-ul unui serviciu web cu Axis (paşii de mai jos nu sunt descoperirea mea, ci a Giei, căreia îi rămân dator pentru ajutorul ăsta care ni l-a dat pentru tema asta). Am modificat putin ca şi formă, dar nu ca şi conţinut:
Instalare server / deployment web service Java cu Axis
1. dezarhivare pachete axis / apache tomcat
2. copiati folderul axis din axis-VERSIUNE/webapps/ in apache-tomcat/webapps
3. setati varibilele de mediu ca in linkul : http://ws.apache.org/axis/java/install.html#Step6DeployingYourWebServiceApoi, ca sa faceţi deployment la un serviciu web folosind jws: clasa .java cu implementarea se redenumeşte Clasa.jws si o copiati in directorul apache-tomcat-5.5.27webappsaxis. Ca sa testati daca e ok, folosiţi url-ul : http://localhost:8080/axis/Clasa.jws Ar trebui să răspundă că acolo locuieşte un serviciu web
Notă: daca folositi clase facute de voi in clasa Clasa.jws trebuie sa copiati fisierele binare in apache-tomcat-5.5.27webappsaxisWEB-INFclasses , altfel o sa dea eroare.
Conexiune cu baza de date MySQL prin JDNI
În apache-tomcat-5.5.27confCatalinalocalhost salvati un fisier axis.xml care sa aiba conţinutul:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/axis" debug="5 reloadable="true" crossContext="true">
<Resource name="jdbc/NUME_JNDI" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="USER_DB" password="PASS_DB" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/NUME_BD?autoReconect=true"/>
</Context>În fişierul apache-tomcat-5.5.27webappsaxisWEB-INFweb.xml trebuie adăugat la sfârşit, înainte de închiderea lui <web-app> :
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/NUME_JDNI</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>Şi apoi vă conectaţi la baza de date, în Clasa.jws , astfel:
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
DataSource ds = (DataSource) envCtx.lookup("jdbc/NUME_JDNI");
dbConnection = ds.getConnection();
Înafară de JDBC, JDNI şi Webservices eu am învăţat multe lucruri utile despre ANT (colegii mei învăţaseră deja de la Tema 2). Pe scurt Ant e un build tool, al cărui script de build se scrie în XML. Practic, un fel de make (cu makefile-ul) aferent, doar ca mai flexibil şi mai uşor de utilizat. În ANT, unitatea de execuţie este target-ul. Un target poate conţine mai multe task-uri, în funcţie de task-urile respective, şi poate depinde de alte target-uri.
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 :)
UP11 site rollin’ on yPHP
I-am dat drumul. Adică am trimis invitaţia, am pus sus site-ul şi informaţiile existenţiale, lucrurile se mişcă pe partea de logistică, lucrurile se mişcă pe partea de program, n-aş îndrăzni să zic că ne merge super dar avem loc de mişcare.
Site-ul îl puteţi vedea la http://www.unitatesiprietenie.ro/, şi este bazat pe yPHP. Tot setup-ul a durat una sau două ore, în condiţiile în care am gasit bug-uri prin structura yPHP ŞI am avut evident probleme cu encoding-ul. Mă înnebunesc problemele cu encoding-ul în ultima vreme, nu suport să nu fie textul cu diacritice şi întotdeauna fie baza de date fie PHP-ulş vrea să mess with me pe chestia asta.
Spre exemplu, pentru wiki-ul primitiv folosit de yPHP acum, imi trebuia un titlu unic pentru pagină, pe care îl gaseam, după moda Wiki (nu ştiu dacă mai ţine moda asta, da o fost aşa acum ceva vreme), cu toate cuvintele cu prima literă mare şi alăturate. Spre exemplu pagina "ONCR Festival cercetaşi" s-ar traduce în "OncrFestivalCercetaşi".
Evident, o problemă aparent simplă. Doar că dacă faci ucfirst() pe un string care e encodat cu utf-8, rezultatul e un string pe encoding standard (nu ştiu exact care standard îi - poate cp1251, doar că nu ştie de caractere româneşti). Super, deci
ucfirst($string)
devine
mb_strtoupper(mb_substr($string, 0, 1, "utf-8")).mb_substr($string, 1, strlen($string) - 1, "utf-8").
That is in no way cool. Unde mai pui că suportul pentru mb_string în PHP e absolut opţional şi host-ul meu (care sunt români) nu îl are instalat. Deci no joy.
Acum câteva zile, tot probleme de encoding. De data asta, pe conexiunea MySQL. Atenţie pentru cine mai dă de probleme de genul ăsta. Dacă MySQL vă salvează diacriticele ca ? (semne de întrebare), sunt câteva chestii care le puteţi verifica.
1. MySQL are o drăcie care se numeşte collation, care e un atribut care se poate aplica până la nivel de coloană, şi ţine de encodingul folosit în coloanele respective. Atenţie, şi tabelul are proprietatea collation şi contează. Problema mea de ieri se întâmpla în contextul în care toate câmpurile tabelului erau pe utf8_general_ci, dar tabelul, care era proastpăt importat, era setat pe default-ul latin_sweedish_ci, care nu se înţelege deloc cu diacriticele.
2. Asiguraţi-vă că discuţia între server şi clientul vostru se face prin utf8. Sunt mai multe chestii în manualul MySQL despre cum se poate seta asta. Pentru că evident n-am avut chiar vreme (site-ul UP11 era trecut de deadline de muuult) să RTFM, am scanat prin el şi am găsit câteva linii relevante:
SET NAMES 'charset_name' SET CHARACTER SETcharset_name
Evident, nu trebuie să uitaţi să definiti character-encoding-ul în HTML-ul rezultat şi să trimiteţi headerul HTTP cu character encodingul setat corect (desi browserele de doamne-ajută fac ele detecţie).
yPHP – idei
yPHP (care vine de la yetiPHP :P) este cum numesc eu tot ce am învăţat de când am scos nasul în lumea PHP, concretizat în cod. Primele mele aplicaţii în PHP au fost scrise cu ajutorul Dreamweaver de la Macromedia, prin începutul liceului, şi, învăţând din codul autogenerat, am început să scriu şi eu chestiile mele.
Evident, pe vremea aia începusem să învăţ ceva programare la liceu, şi am mai învăţat să folosesc funcţii and stuff, da dacă stau acuma să mă gândesc în urmă, nu cred ca mi-a plăcut vreodata ideea asta cu PHP şi HTML şi CSS şi toate într-o mare ciorba. Aşa că undeva prin anul 2 - 3 (că în anul 1, 2 n-o prea fost rost de învăţat chestii cool), începând să învăţ despre OO pe la şcoală, am început să investighez posibilitatea de a folosi OO în PHP.
A durat ceva, şi am mai inventat câte ceva noi învăţat the hard way, dar până acum câteva zile yPHP nu a fost mai mult decât o modalitate cât mai standard de a scrie codul pentru aplicaţii folosind MVC (model, view, controller).
Scriu postul ăsta pentru că, în timp ce lucram la una alta mi-a venit o idee mai trăznită. Cum ar fi să ai o aplicaţie grafică în care să defineşti relaţiile între entităţile sistemului tău, ce acţiuni poate face şi cine şi când, şi apoi de la setările tale, fie să se genereze nişte clase direct, fie să se genereze nişte fişiere de configurare pentru o ... maşină virtuală PHP care să îţi execute chestiile.
Cu cât mă gândesc mai mult la asta cu atât mi se pare mai utilă, deşi nu ştiu cât de mult poate fi scalat aşa ceva. M-am uitat la framework-urile existente pentru PHP, şi iniţial am crezut ca reinventez roata. Dar acum nu mai sunt convins. Cred că ar ieşi ceva interesant pentru IMM-uri şi, mai ales, ONG-uri.
Întrebarea e, cred, cât de departe se poate merge cu descrierea acţiunilor. Cum poţi să faci cât mai simplu şi mai vizual definirea unor funcţii custom, eventual să fie cumva independete de limbaj, fără să ajungi, cum sunt băieţii de la Typo3, să scrii un limbaj noi, şi totuşi fără să pierzi din flexibilitate. Idei?