Transilvania, CA

Pentru cei interesati, o prezentare de-a mea despre Silverlight plus linkuri si surse ale unei aplicatii care face acelasi lucru, scrisa in Flex si apoi Silverlight.

Sa zicem ca lucrezi intr-o agentie online de tip “full service”, pe post de dezvoltator. Agentie mare, clienti multi, proiecte care consuma multa energie, resurse.

Marele avantaj este ca atingi o gramada de tehnologii. Majoritatea clientilor vin la tine cu platforme deja bine infipte in peisaj. Iar proiectul tau trebie sa ruleze pe aceste platforme. Unii vor .Net, altii J2EE sau PHP. Sau vin cu tot felul de servere pentru aplicatiii exotice cu componente adunate de la razboiul de independenta incoace. Si nu ai incotro, trebuie sa iei manualele la puricat si sa inveti. Suficient de multe pentru a-ti rula si optimiza proiectul astfel incat sa mearga bine in aceste zone crepusculare.

Marele dezavantaj este nu vei fi specialist in nici una dintre aceste tehnologii. Le folosesti o luna, doua dupa care sari intr-alta, poate te intorci la un moment dat, pentru putin timp insa. Ciclul continua, nu ai cum sa evadezi. Ajungi sa te pricepi cate putin la toate si de fapt la nimic foarte bine.

Si il inteleg. Nu am fost niciodata un mare fan. Desi sunt de acord ca Flash Lite este o jucarie draguta, nu cred ca este o tehnologie pentru aplicatii serioase, stabile, folosibile. Eu mai degraba sper sa apara sub forma de plugin pentru browsere mobile. Pe larg.

Sunt interesante miscarile de pe proaspata piata a, nici nu prea stiu cum sa le spun, runtime-urilor care permit instalarea/rularea la purtator a unor aplicatii on-line. Sau in fine, ceva de genul asta. Principalii participanti sunt momentan Google Gears, Microsoft Silverlight si Adobe Air. Google tocmai a lansat Gears pentru…. IE sub Windows Mobile. Iar Microsoft si Nokia anunta ca vor lansa Silverlight pentru Symbian 60 (adica mai ales pentru Nokia). Ce urmeaza? Abobe Air pentru Android?

Demult a murit romantismul schimbarii. Da, mi-a placut la inceput. Nu neaparat la nivel de design, ci chiar sistemul de operare (cu exceptia Finder-ului care e o farsa, comparativ cu Explorer-ul din Windows), felul in care instala si rula aplicatii, faza cu Unix-ul si cu Java, serverul incorporat si alte chestii de-astea, de geek.

Problema cu Mac-ul este ca-i proiectat in asa fel incat sa fie cat mai putin extensibil. Cu cat il incarci mai mult cu atat devine mai lenes, mai hamesit dupa memorie sau spatiu pe disc. Ceea ce e logic si ok, atata timp cat ma lasa sa mai adaug memorie sau sa-l extind prin periferice. Aici e chichita insa. Treaba cu memoria nu merge, vine din fabrica cu imbecila limitare de 2 GB de ram (4 GB pentru modelele mai noi). Bineinteles ca daca-i intrebi de ce, ei baga faze cu domn’e nu e testat, probleme de fezabilitate etc. Adevarul e ca abia asteapta sa dai de limitarile sculei pentru a-ti curge balele dupa modelul mai nou, care nu costa decat cu vreo $600 mai mult decat al tau.

Apoi ar mai fi perifericele care nu prea merg sau nu au drivere. Dar asta stiam cand m-am decis sa-mi iau un Mac, deci nu ar trebuie sa ma plang.

In final si cateva de bine. Nu zic ca e o scula rea, merge brici daca nu o bati la cap prea tare. Chiar merge sa scrii cod pe ea, Eclipse, servere, baze de date, toate ruleaza frumos. Dar daca te apuca creativitatea si vrei sa-i bagi un adaptor pentru WIFI N sau vrei sa construiesti o mica retea privata cu acess la imprimante si la harduri comune, vai de capul tau. Numai nervi.

Folosesc de cateva luni prototype.js, o biblioteca JavaScript, nu neaparat de buna voie, mai degraba din nevoia de a standardiza cat de cat dezvoltarea proiectelor care folosesc JS extensiv. Mi-a placut un timp, am tolerat-o apoi pentru ca acum sa ma enerveze. Motivele sunt mai ales legate de fortarea sintaxei de Ruby peste JavaScript si performanta. Dar in fine, nu asta e problema mea acum.

Pentru un proiect mai vechi folosesc  Observer ca sa citesc/folosesc in timp real ce scrie utilizatorul in campul unui formular. Ceva de genul:

usernamelookup = new Form.Element.Observer(‘EditUsername’, 0.1, lookUpUsername);

Toate bune si frumose pana cand, la un moment dat, nu mai vreau ca acest lucru sa se intample, adica vreau sa resetez observer-ul. Din pacate documentatia pentru API-ul prototype.js nu-mi spune cum as putea sa-l distrug sau sa-i spun sa faca altceva, sta acolo pe vecie. Acum e adevarat ca as putea sa ma bag in sursa dar nu am nici un chef. Ca nu de aia m-am hotarat sa folosesc o biblioteca cu API. Idei?

Air a iesit in sfarsit din Beta. Cum ziceam, e oarecum de bine. Ca sa subliniez ce ma doare mai tare, agentiile care se ocupa in exclusivitate cu lansarea de produse online nu vor mai avea nevoie sa angajeze terte parti pentru a dezvolta aplicatii care sa ruleze local, la client. Cu personalul din dotare, care presupunem ca stie sa scrie cod pentru web, vor putea produce astfel de aplicatii in AIR, pentru Windows, Mac si in curand, chiar pentru Linux. La o intalnire cu programatorii din Silicon Valey, baietii si fetele de la Adobe promiteau aseara ca vor incerca sa scoata cate o versiune de Air pentru orice sistem de operare, referindu-se mai ales la dispozitive mobile, telefoane etc. Sa vezi atunci distractie si killer apps.

Pana una alta, asa printre randuri, au anuntat o noua versiune (3) de Flex.

Si aici un exemplu de aplicatie AIR care merita instalata: Google Analitics AIR.

In ultimul timp am m-am lovit de probleme generate de viteza redusa cu care aplicatiile construite de mine sau de altii servesc cantitati mai mari de date clientului, adica browserului. Este vorba – nu neaparat in cazul aplicatilor scrise de mine – de limite introduse de hardware. Concomitent, din discutii cu diversi si incercand sa scot o arhitectura cat mai eficienta pentru resursele actuale, iese la suprafata din ce in ce mai des conceptul de baze date la purtator, adica in browser. Adobe a atins subiectul in AIR, unde applicatiile pot folosi o versiune locala de SQLite, la fel si Google in Gears. Cum ar fi sa cauti niste adrese pe o aplicatie de harti online si apoi, fara sa fi conectat la internet, sa poti sa revii si sa schimbi trasee sau sa iti improspatezi memoria cu amanunte?

In ultimul timp vad din ce in ce mai multi programatori folosind Mac-uri. Initial am remarcat numarul mare de MacBookPro si MacBook la o conferinta Adobe ActionScript 3, dar am crezut ca multi dintre participanti erau mai degraba flasheri inraiti, veniti din zona de design si animatie. Dar nu, majoritatea programatorilor pe care i-am intalnit in ultimele saptamani lucreaza pe aceasta pltaforma.

Pentru ca tot sunt la doi pasi de Silicon Valley am inceput sa particip la tot felul de intalniri ale programatorilor din zona. Puse una peste alta, aceste intalniri reprezinta probabil cel mai potent think-tank din lume la nivel de tehnologie computeristica.

Tocmai am fost la un fel de tabara organizata de o asociatie a dezvoltatorilor de aplicatii pentru web din Silicon Valley. Pe langa socializare si discutii aprinse depre de ce Java este la ani lumina distanta fata de .NET(parerea lor nu a mea), diverse firme cu nume din zona se prezinta sau isi prezinta produsele. La ultima intalnire au venit baietii de la Facebook, care se ocupa de legatura cu dezvoltatorii. De retinut doua chestii care mi s-au parut importante si interesante. Unu – aplicatia foto de baza din Facebook, asa simplista, amarata, lipsita de stralucire, cu rezolutie modesta, are.. atentie, un trafic dublu fata de Flickr, Photobucket si Picasa la un loc. Doi – din punct de vedere tehnic, Facebook este deja o adevarata platforma pentru dezvoltatori, lucru care nu prea mi-a fost clar la prima vedere… Am intalnit oameni care asta fac, asta le e meseria: dezvoltatiri de aplicatii pentru Facebook.

Pe langa socializare si prezentari, intalnirea a mai continut un element care a transformat cladirea care a gazduit-o in cel mai geeky loc de pe planeta: un concurs de aplicatii scrise ad-hoc, in timpul noptii dintre sambata si duminica. Copii vin cu pijamale si paturi pliante sau saci de dormit si-si petrec nopatea intr-o hala, cu pizza si cola, codand pana-n zori.