marți, 30 decembrie 2008

Time-tracking

Nici un proiect web 2.0 nu va avea succes daca nu va fi gata la timp, si nu va fi executat intr-un mod organizat. Cititi articolul lui Razvan de pe site ca sa va puneti in tema cu solutia pe care o foloseste el. Si credeti-ma, la el functioneaza :)

Te simti aparat de un "captcha"?

Captcha este imaginea enervanta de pe site-uri, scrisa stramb de nu o puteti descifra si voi, menita sa impiedice calculatoarele sa-si creeze automat conturi pe site-urile respective. Pentru ca daca au reusit acest lucru, veti fi mai devreme sau mai tarziu tinta unui spamming intens, sau al unui DOS / DDOS attack.

Vazand pe site-ul unor colegi binevoitori asa ceva: http://interfeteweb.schibucuresti.ro/news.php, mi-am adus aminte ca am citit pe Slashdot ca nu ar fi chiar complicat sa recunosti multe clase de captcha, ba mai mult s-au gasit niste rusi care sa recunoasca pe cel de la Gmail cu eficienta de 20%. Astfel, ei au reusit sa economiseasca foarte multi bani, deoarece plateau niste negrisori sa citeasca Captcha cu 1 cent / bucata.

Ca sa va ingroziti si mai tare, iata 2 dintre site-urile pe subiect care mi-au placut:
Pe scurt, se pare ca captcha-ul colegilor mei ar fi chiar foarte simplu de recunoscut automat. Cu prima ocazie, o sa incerc si eu de curiozitate. Desi captcha este o idee extraordinara, din pacate de multe ori ea este doborata de o executie slaba / amatoriceasca:

"Like any security system, design flaws in a system implementation can prevent the theoretical security from being realized. Many CAPTCHA implementations, especially those which have not been designed and reviewed by experts in the fields of security, are prone to common attacks."

luni, 29 decembrie 2008

Heatmap - cat de "fierbinte" e site-ul tau?

Mi-am adus astazi aminte de o idee geniala pe care am vazut-o cu cateva luni in urma: heatmaps. Pe scurt, se inregistreaza folosind JavaScript unde se da fiecare click pe pagina si astfel se pot evidentia grafic zonele unde se face click mai des (sau unde sta mouse-ul mai des). Fiindca atunci cand user-ul face click, se si uita unde (hopefully..), zonele cele mai "fierbinti" sunt candidatii ideali pentru:
  • a plasa continutul pe care vreti sa-l promovati
  • a identifica elementele grafice care au cel mai mare succes
Una din solutiile online apreciate este: www.crazyegg.com. Dispun atat de servicii platite cat si de un serviciu free, care permite monitorizarea a 4 pagini si a unui maxim de 6000 de afisari / luna. Suficient pentru noi. In interfata Google Analytics puteti vedea ceva in aceeasi idee, "Site Overlay", ca un entry in meniul "Content".

Instalarea CrazyEgg este foarte simpla, dupa inregistrarea la ei pe site si setup-ul de acolo, se include un script in template-ul siteului, tot la sfarsit, in zona unde ati pus si Google Analytics.

Pana data viitoare, cand va voi arata primele rezultate ale heatmap-ului, va doresc "La multi vizitatori"!

Cum sa-ti afli pozitia pe google?

Am investit 30 de minute azi dimineata pentru a gasi un program / site care sa-mi calculeze automat pozitia pe google. Peste jumatate nu functionau, iar din cele care functionau, nu dadeau rezultate bune. Sfatul meu este sa luati calea cea mai sigura:

http://www.google.ro/search?hl=ro&q=interfete+web&btnG=Căutare+Google&meta=&num=100

Adaugand sectiunea bold la sfarsit, il fortati pe nenea Google sa afiseze rezultatele cate 100 pe pagina. Good old FireFox va poate asista apoi cu keyword search (Ctrl-F). In caz ca nu apareti pe prima pagina (cum e si cazul nostru:) ) , insistati pe paginile urmatoare.

sâmbătă, 27 decembrie 2008

De ce n-are ursul coada?

... sau de ce nu merge sa-ti maresti PageRank-ul daca postezi un link pe Wikipedia catre site-ul tau.

Mai deunazi va povesteam despre colegii mei inventivi care s-au gandit sa posteze pe Wikipedia un link catre site-ul lor. PageRank a fost gandit ca fiind direct corelat cu probabilitatea ca un user sa ajunga pe site-ul respectiv, navigand din link in link, dar pe o scara logaritmica. Deci ar fi trebuit sa creasca.

Totusi, cei de la Google s-au gandit inaintea noastra ca ar putea sa se intample asa ceva, si au introdus atributul "rel=nofollow" pentru link-uri. Pe scurt, acesta spune crawler-ului care se afla pe pagina curenta sa nu urmeze link-ul respectiv, sau daca il urmeaza, sa nu modifice ranking-ul paginii catre care e link-ul.

Si cum nu o data au patit-o cei de la Wikipedia, orice link editabil de un utilizator de pe site-ul lor are automat nofollow setat. Puteti alege o pagina de pe Wikipedia la intamplare, sa dati view source, si sa va convingeti si singuri.

Happy SEO-ing!

miercuri, 24 decembrie 2008

Debug-area unei aplicatii Java in timp ce ruleaza

Zilele astea m-am lovit de urmatoarea problema: o aplicatie Java se blocheaza (aparent) fara motiv. Pentru ca nu am acces la codul sursa al aplicatiei, am procedat in felul urmator (treaba se desfasoara pe un sistem *nix):
  • am aflat PID-ul JVM-ului in care e rulata aplicatia (daca ea se numeste "Test", un ps ax | grep Test e suficient)
  • am facut un core dump pentru procesul respectiv: gcore pid_no (va rezulta un fisier numit core.pid_no). Acesta contine spatiul de adresa al JVM-ului (pe romaneste, toata memoria pe care o accesa JVM-ul in timp ce rula, inclusiv executabilul sau incarcat in memorie)
  • am apelat which java pentru a determina calea catre JVM-ul default (sa speram ca va aflati in cazul simplu in care ati compilat cu javac-ul corespunzator JVM-ului default)
  • acum totul e simplu: jstack path_to_jvm core.pid_no. Acesta ne va intoarce cate un stack trace pentru fiecare thread care ruleaza, impreuna cu informatia de debug asociata; drept bonus, are si deadlock detector asociat
Happy debugging!

luni, 22 decembrie 2008

Aplicatii web in Java (3) - Struts 1.x + Tiles

Daca dupa articolul trecut nu v-am convins sa optati pentru facilitatile MVC ale Spring, puteti sa folositi solutia consacrata (are niste dezavantaje, dar odata ce v-ati obisnuit cu el se poate lucra rapid): Struts.

Struts are un controller care parseaza URL-urile si apeleaza clase Java (numite "actiuni") pentru a crea si popula un model care va fi dat mai departe la layer-ul de view (realizat de obicei cu JSP). O actiune poate sa decida randarea paginii sau redirectionarea (interna) catre un alt URL (care va avea asociata o actiune).

Daca insa doriti sa faceti un "mashup", sau sa creati module reutilizabile responsabile pentru randarea unor bucati de pagina, veti constata limitarea Struts. Intr-un site scalabil, fiecare bucata de pagina este randata de un serviciu web separat, si deci care poate fi relocat pe un alt server (sau grup de servere), iar Struts nu suporta aceasta paradigma.

Aici intervine Tiles, un plug-in de Struts care lucreaza cu layout-uri. Un layout specifica pozitiile in care trebuiesc inserate "tile"-urile din care este format si este descris in limbaj JSP. Reprezentarea cea mai generala a unui tile este un URL, care poate reda la randul sau un alt layout, si asa mai departe.

Cum afla o "actiune" care sunt parametrii request-ului HTTP facut de utilizator? Aceasta este una din cele mai simpatice facilitati ale Struts-ului, numita auto-populare: intr-o asociere URL-actiune se mentioneaza si o clasa Java numita Form (ActionForm), care este un bean ai carui membri sunt setati automat de catre Struts inainte de a apela actiunea. Actiunea va primi ca parametru un Form auto-populat si validat. Validarea se face de asemenea inainte de apelarea actiunii, iar rutinele sunt configurate separat fata de actiuni. Avantajele acesti abordari:
  • se separa clar validarea datelor de crearea modelului
  • actiunea poate presupune ca lucreaza cu date valide
In curand vom incepe sa postam si tutoriale pas cu pas despre crearea unei aplicatii web, si atunci aceste explicatii abstracte vor fi cu adevarat folositoare.

SEO - dirty, clean, cool

In episodul de astazi o sa va povestesc despre tehnicile SEO folosite de toti concurentii pentru valoroasele puncte la I.E. Eu le-as imparti in 3 categorii:
  • dirty: fac orice numai ca sa iau 5 sutimi la IE
  • clean: sunt baiat cuminte si respect regulile de bun simt, dar n-am nici o idee geniala
  • cool: am o idee meseriasa, si toata lumea intra pe site din cauza ei

Dirty (sunt convins ca mai sunt si altele, doar de astea am auzit eu):
  • se pune ca homepage la calculatoarele din laborator pagina
  • se editeaza pe wikipedia link-uri catre site
  • se inscrie site-ul in 9999 directoare web, la gramada, si homepage-ul va arata oribil (temporar, pana cu o zi inainte de prezentarea proiectului :P)
  • se pun teme rezolvate si se incurajeaza colegii sa le copieze de pe site - la un laborator o colega a insistat sa iau rezolvarea laboratorului de pe site-ul lor; dar, baiat incapatanat cum ma stiti, am refuzat
  • se folosesc tehnici de tipul link-farm
  • se pun pe Yahoo Messenger status-uri de tipul "Sexxx!!" cu link catre site-ul propriu (o colega are tot timpul acest status :P)

Clean:
  • Google sitemap: se face submit la un xml catre google care sa ii descrie acestuia structura site-ului, importanta fiecarei pagini si viteza cu care se schimba fiecare pagina. Pentru ca folosim Joomla, am ales Joomap.
  • Google analytics: observ cuvinte cheie des folosite pentru a regasi site-ul meu si incerc sa optimizez pentru ele (din pacate pentru noi, acele cuvinte n-o sa fie niciodata mult doritele "Interfete web" :P)
  • Google AdSense: activez AdSense si in mod obligatoriu crawler-ul imi va vizita mult mai des pagina, pentru ca acum Google are interesul sa determine care sunt cele mai potrivite reclame de afisat
  • Fac site-ul sa foloseasca google-friendly links: chiar daca folosesc o tehnologie dinamica de prezentare (gen PHP), parametrii nu se pot separa doar folosind ? si &, ci si alte caractere, spre exemplu "-": http://mysite.com/index.php-key1=value1-key2=value2. Aici Joomla ne ajuta cu o optiune care poate fi activata din Global Settings, si genereaza automat link-uri friendly.
  • Inscriu site-ul in mai multe search engine-uri, nu numai in Google
Cool:
  • Fac misto de site-urile altora, si o fac intr-atat de bine incat lumea incepe sa-mi citeasca blog-ul. E o idee foarte faina, doar ca la un moment dat s-a degradat calitatea criticilor.
  • Atunci cand colegii isi bat capul cu o problema mai deosebita, le dau un raspuns scurt si un link catre site, unde se gaseste solutia completa (de preferat totusi sa nu fie rezolvarea unei teme..)
  • Fac un site bazat pe o idee interesanta: mi-au ramas in minte 2, unul in mod text (!!!) si unul care avea ca logo "interfete sexy" - desi continutul nu avea nici o legatura cu titulatura

Aplicatii web in Java (2) - Spring Framework

Revenim cu episodul 2 al serialului "Java demistificat":

De aceasta data, ne vom concentra asupra framework-ului Spring. Relatia sa cu componentele unei aplicatii J2EE este asemanatoare cu cea dintre placa de baza si componentele de pe ea. El ne ofera platforma pentru a dezvolta corect si repede servicii care sa reprezinte functionalitatea aplicatiei noastre. Principalele sale functionalitati sunt:
  • container-ul cu Inversion of Control: container in care se inregistreaza obiecte Java, care implementeaza o interfata, sub un nume unic dupa care vor putea fi regasite ulterior. Container-ul suporta si operatia de regasire a unui obiect, intorcandu-ne un obiect care se comporta identic cu obiectul inregistrat (apelurile de metode din interfata au aceleasi efecte vizibile de catre utilizator). Rezultatul este diferit de obiectul initial in cazul in care se doreste interceptarea metodelor acestuia, cu diverse scopuri (AOP fiind unul dintre ele). Care este totusi avantajul fata de un container obisnuit, sau de un simplu HashMap? Dependentele intre obiecte se specifica declarativ in fisiere de configurare, programatorul nu trebuie sa se concentreze sa propage o referinta la un obiect O1 catre obiectul O2, container-ul facand acest lucru automat.
  • framework AOP: framework care permite interceptarea apelurilor de metode catre obiectele inregistrate in container si aplicarea unor "advice-uri" inainte sau dupa apelul metodei. Un advice poate fi o simpla log-are, sau poate chiar decide ca apelul de metoda sa nu aiba loc. Numele metodelor interceptate pot fi specificate folosind expresii regulate, astfel incat denumirea consistenta a metodelor le asigura 'on the fly' proprietati interesante. Principala utilizare a AOP-ului consta in executia unei metode care citeste/scrie in baza de date in cadrul unei tranzactii, fara a specifica acest lucru programatic. Aceasta duce si la evitarea tranzactiilor nested, o evidenta si periculoasa bataie de cap.
  • framework MVC: desi suporta plugin-uri care fac acelasi lucru (cel mai cunoscut fiind Struts), Spring ne ofera o implementare home-made de MVC. Principiul de functionare al MVC-ului este urmatorul: input-ul unei aplicatii uzuale J2EE este un request HTTP, care este preluat de catre un controller principal al aplicatiei (provided by Spring), care-l ruteaza catre un controller specializat (implementat de programator). Controller-ul specializat construieste un model (o structura de date), posibil prin consultarea starii aplicatiei (deci baza de date) si o intoarce catre controller-ul principal, acesta delegand afisarea modelului catre una din tehnologiile disponibile, in functie de context. O metoda cunoscuta de noi si studiata la L.P.D. este JSP, dar nu este singura. Pentru o mai buna intelegere, recomand vizualizarea pozei de la urmatorul link: http://static.springframework.org/spring/docs/2.5.x/reference/images/mvc.png
  • framework de acces la baza de date: desi de multe ori este mai simplu sa folosim JDBC, care ne permite sa trimitem direct query-uri SQL scrise de noi catre baza de date si sa examinam rezultatele, acesta are o sumedenie de dezavantaje. In primul rand, eficienta cade cu totul in sarcina programatorului, ceea ce creste costurile de dezvoltare a produsului (fiind nevoie de programatori mai capabili). In al doilea rand, se scrie foarte mult cod de rutina pentru a traduce rezultatul query-urilor, prezentat sub forma tabelara in forma orientat-obiect. Ambele probleme sunt rezolvate de un framework de persistenta. Rolul acestuia este urmatorul: ii dam informatii despre structura bazei de date si sfaturi despre cum sa optimizeze accesul la ea, declarativ, si el preia ambele responsabilitati mentionate mai sus: genereaza query-uri SQL pentru a prelua rezultatele de care avem nevoie (sau pentru a le inregistra, dupa caz), si transforma aceste rezultate tabelare in obiecte gata de folosit mai departe.
Desi Spring contine mult mai multe componente, acestea mi s-au parut mie mai folositoare in practica. In prezent a ajuns la versiunea 3.0 si mai multe detalii pot fi regasite la: http://www.springsource.org/

miercuri, 3 decembrie 2008

UPB vs. ASE

Eternul si fascinantul "flame war" este tratat de o colega intr-un post:
http://mist-iweb.blogspot.com/2008/10/choose-life-choose-ase-not.html
As adauga ca si completare ca in general nu poti sa le ai pe toate: timp liber mult, relaxare, dobandirea multor cunostiinte, antrenarea neuronilor. Ziua are doar 24 de ore :) Si nu e neaparat rau sa refuzi sa alegi varianta usoara.

marți, 2 decembrie 2008

Aplicatii web in Java (1)

Site-uri web in java .. complicat? Cumplit? Provocare?

Simti ca te pierzi in multitudinea de fisiere de configurare XML si in sutele de acronime de tipul JSP, JSTL, RMI, JAX-RPC? :) Nu-i nici o problema, ai nimerit unde trebuia. In 2 timpi si trei miscari iti explicam conceptele de baza pentru a putea intelege mai usor ce ai de facut.

Ingrediente:
* o bucata JBoss, ne-maruntita
* trei bucati framework-uri, asortate: Spring, Struts si Hibernate
* niscaiva cunostiinte despre XML si Java, dupa gust si posibilitati

In continuare, vom descrie fiecare din ingrediente:

JBoss: "application server", asculta conexiuni TCP/IP (by default pe portul 80), si in functie de calea request-urilor, mapeaza aceste request-uri catre "aplicatii" Java, care vor prelucra mai departe request-ul HTTP, livrand in final o pagina cu continut HTML (de obicei) catre clientul HTTP care a facut cererea.

O astfel de aplicatie este o aplicatie normala Java. Nu are chiar metoda Main(String[] args), dar are un fisier web.xml numit "deployment descriptor", care descrie o serie de "filtre" si "servlets", precum si alte configurari, care stabileste care metode din codul Java vor fi apelate atunci cand request-ul contine anumite pattern-uri.

Spring: framework "bun la toate", ale carui principale "arme impotriva concurentei sunt":
- container-ul cu Inversion of Control - mentine niste obiecte (le putem asemana daca vreti cu niste variabile globale in contextul unei aplicatii web) instantiate in memorie si are grija ca anumiti membri ai lor sa fie setati automat, asa cum este specificat in niste fisiere de configurare (XML, bineinteles:) )
- suporta framework-uri de persistenta: bune la casa omului, cand motorul curent de baze de date nu-ti mai satisface nevoile; in caz de "nevoie", se migreaza datele de la un engine de baze de date la altul, se modifica configurarile framework-ului de persistenta (can be a pain in the ass sometimes..) si voila, nu a trebuit modificata aplicatia cu nimic
- suporta "Aspect Oriented Programming": interceptarea unor apeluri de functii si rularea unor "advice-uri" la momente cheie din viata apelurilor respective. Folosind "advice-uri" putem specifica declarativ ca vrem ca anumite metode care modifica baza de date sa fie tranzactionale, de exemplu, sau ca vrem sa faca numai citiri (si la prima scriere sa se genereze o eroare)
- suporta MVC, atat sub forma de plugin, cat si prin propriul framework, Spring MVC

Struts: workflows, web-pages, MVC, input-forms, validation
Toate aceste cuvinte cheie definesc succint pe bunul nostru prieten Struts. Si el foloseste fisiere de configurare XML, pentru ca nu a vrut sa fie oaia neagra a familiei J2EE. Si suporta si plugin-uri, si de toate, numai ca sa va aduca voua pe ecrane paginile voastre favorite. Struts face practic afisarea si nu face altceva decat sa mapeze anumite path-uri la servleti JSP, care pot fi precedati de "actiuni" care "populeaza" "form-uri" si forwardeaza mai departe la alte "actiuni". Nu va speriati, nu e chiar atat de rau pe cat pare.. pana cand dati de internationalizare :)

Hibernate: unul dintre cele mai folosite framework-uri de persistenta. Incearca sa abstractizeze accesul la baza de date prin mai multe metode:
- defineste un limbaj HQL, asemanator cu SQL, care apoi este translatat in dialectul nativ al bazei de date folosita
- defineste (folosind XML, evident:) ) mapping-uri intre obiecte Java ("POJO" - Plain Old Java Objects) si randuri in baza de date
- ne ofera API-uri de interogare a bazei de date, care acum este privita ca si continand obiecte (cel mai cunoscut este Criteria API)
- ofera o arhitectura de cache avansata, pluggable, cu suport pentru cache distribuit, absolut necesar daca vreti ca site-ul web sa nu ruleze numai pe un singur server

In episodul urmator, va vom povesti despre JBoss, si cum sa imblanzim aceasta "bestie".

Ce optiuni avem pentru realizarea unui site web?

Acesta este primul post dintr-o serie menita sa informeze tanarul public despre diversitatea optiunilor de care dispune pentru realizarea unui site web :) Noi nu promovam mituri de genul "tehnologia X e cea mai buna" si discutii interminabile in contradictoriu pe teme asemanatoare.

Care sunt cele mai bune tehnologii pentru realizarea unui site web? Paaaai.. raspunsul la aceasta intrebarea este: depinde. Ca in orice problema inginereasca, trebuie sa ne alegem uneltele in functie de necesitati.

Primul lucru, trebuie sa ne hotaram daca site-ul va avea continut dinamic sau nu. Daca nu, trebuie doar sa ne alegem un editor preferat de HTML static si CSS si sa ne apucam de treaba :) Putem sa inseram si niste JavaScript pentru a adauga sare si piper in interfata grafica, eventual sa ne folosim de AJAX pentru a obtine niste efecte si mai spectaculoase.

Dar odata ajunsi sa ne punem problema unui site web cu continut dinamic, avem cateva decizii foarte dificile de luat. Nu trebuie sa ne gandim de la inceput la ceva foarte complicat, care suporta zeci de mii de utilizatori concomitent, dar trebuie sa avem in vedere si aceasta posibila (desi improbabila:) ) evolutie.

Astfel, inainte sa ne apucam de codat, trebuie sa ne alegem:
  • Motorul de baze de date care sa deserveasca site-ul
  • Limbajul cu ajutorul caruia generam continutul HTML dinamic
  • Framework-ul MVC pentru limbajul ales
  • Framework-ul de persistenta (trebuie sa ne propunem de la inceput sa fim independenti de motorul de baze de date folosit, altfel vom avea mari dureri de cap dupa)
  • Un tool de bug-tracking
  • Un tool de project-management
Aceste articole isi propun sa completeze continutul cursului de Interfete Evoluate, pentru a oferi o imagine completa asupra pasilor de urmat pentru realizarea unui site in mod profesionist.

duminică, 23 noiembrie 2008

Concurrent Task Tree - Part 1

Tema numarul 2 la frumoasa materie "Interfete evolutate" ne propune sa modelam interfata site-ului blogger.com folosind un programel ce poate fi download-at de la adresa http://giove.cnuce.cnr.it/ctte.html.
Cum eu nu am folosit niciodata o interfata de blogging am inceput sa ma joc putin cu acest blog pentru a vedea ce se poate face pe un blog.
Am sa revin cu detalii despre ceea ce voi reusi sa fac.
(acesta este primul meu post pe un blog; n-a fost chiar atat de greu :))

vineri, 7 noiembrie 2008

Adobe : Proiecte de diploma

La cursul de SPRC, a fost prezentata oferta de proiecte de diploma de la Adobe. S-au impartit tricouri, cani si mingiute de la Adobe celor care raspundeau la o intrebare (cu ocazia aceasta am aflat ca Yahoo inseamna toparlan, el fiind un acronim de la "Yet Another Hierarchical Officious Oracle", si ca Adobe inseamna casa de chirpici).
Proiectele de diploma au fost descrise in felul urmator (O descriere oficiala gasiti pe http://edu.myadobe.ro/?page_id=21) :

1. Automated testing for AIR/Flex applications (AMP team)
Acest proiect se pare ca a aparut din incapacitatea dezvoltatorilor de a adapta metoda de testare automata existenta la AIR/Flex. Sarcina studentului ar fi sa studieze aceasta metoda de testare, sa afle care este motivul pentru care crapa si sa se propuna o varianta functionala (va fi nevoie si de un prototip).
S-a insistat putin pe ideea ca cea mai mare parte a timpului va fi petrecuta reflectandu-se la idee (eu ma gandeam ca va fi debugarea platformei lor) si nu codand efectiv. Este indicat sa stiti putin JavaScript si ActionScript.

2 Online create site wizard (Dreamweaver team)
Echipa de dreamweaver doreste sa dezvolte template-urile din dreamweaver pentru a fi mai flexibile. Din pacate nu am inteles foarte bine ce va presupune acest proiect, dar s-a insistat pe ideea ca este destul de usor sa se realizeze.

3 Photoshop Express and other Adobe online applications integration (Dreamweaver team)
Peste acest proiect s-a trecut foarte repede, ideea fiind sa se poata downloada/uploada imagini in aplicatiile Adobe.

4 Mining Adobe Community Help Logs to Provide Business Intelligence (Web Infrastructure team)
Din dorinta de a asculta de cererile utilizatorilor, se doreste sa se implementeze o solutie de cautare prin logurile de help ale comunitatii Adobe, si sa se afle care sunt problemele intalnite cel mai des la produsele Adobe pentru a le fixa.
In cazul in care inventati o metoda nou de prelucare a informatiilor, sau scoateti informatii noi din loguri aceasta metoda va fi patentata si veti fi rasplatiti cu 10.000$.

5 JBoss JMX administration and monitoring console (Platform EE team)
Parerea celor de la Adobe este ca serverul JBoss este dificil de folosit datorita interfetei greoaie, prin urmare se doreste sa se foloseasca JMX pentru a se construi o interfata prietenoasa in Flex.

Pentru a aplica la aceste proiecte trimite-ti un CV pe adresa educatie@adobe.com si domnului profesor Cristea cu tema pe care doriti sa o abordati. Un sfat al celor de la Adobe este sa le trimiteti si un proiect interesant, sau un link catre un site pe care l-ati realizat. Un criteriu foarte important va fi entuziasmul cu care veti aborda proiectul.
Termenul limita de trimitere a CV-urilor pare sa fie 15 noiembrie, urmand a fi interviuri pana pe 2 decembrie cand se vor stabili finalistii (http://edu.myadobe.ro/?p=227)

marți, 4 noiembrie 2008

Flickr API, si cum ne va ajuta el sa promovam UPB

Desi este disponibil in mai multe "flavors", am optat pentru accesul la API-ul Flickr prin intermediul XML-RPC. Pentru folosirea acestuia este nevoie de un application key, care este dat user-ului in momentul in care isi inregistreaza aplicatia.

O scurta documentatie pentru fiecare API call se gaseste la: http://www.flickr.com/services/api/. Posibilitatile sunt nenumarate, enumar doar cateva:
  • parcurgerea listei de contacts
  • manipularea imaginilor (adaugare, stergere, tagging)
  • comment management
  • interfatare cu geo-tagging
Pentru aplicatii in Java, exista libraria flickrj care va scuteste de multe batai de cap, oferind niste interfete Java care sunt un wrapper pentru apelurile XML-RPC.

Ne propunem sa folosim acest API pentru promovarea educatiei superioare prin uploadarea de poze si tagging-ul lor automat pe Flickr, crescand astfel vizibilitatea Universitatii Politehnica Bucuresti prin intermediul interfetelor web.

luni, 3 noiembrie 2008

Interfete web - inceputul!

Buna ziua tuturor cititorilor nostri!

Odata cu lansarea acestui blog, lansam si site-ul companiei, cu un specific mai deosebit: folosirea interfetelor web pentru promovarea educatiei superioare. Detalii.. in curand.

Pana atunci, va rugam sa ne vizitati: http://feteweb.uv.ro/