Silverdocs, sau memoria de elefant

Ei bine, se stie ca sintagma cu memorie de elefant nu este adevarata, micutele animale avand chiar o memorie mica, comparativ cu frumoasa incinta in care o stocheaza. Si totusi titlul e potrivit pentru articolul curent, in care ma adresez in special programatorilor ce lucreaza pe platforme ce comporta o multime de biblioteci, care necesita o multime de configurari si bucatele mici de cod configurate cum trebuie, astfel incat aplicatia dezvoltata sa functioneze cum trebuie. Cititorul atent a observat ca ma adresez cu predilectie programatorilor de Java, insa nu numai.

Problema pe care o ridic este urmatoarea: cum reusiti sa tineti minte toate configurarile, bucatelele de cod, posibilitatile de configurare, toate optiunile ce trebuie folosite atunci cand lucrati cu Hibernate, JPA, Spring, JSF, Struts, etc, faceti deploy pe JBoss, Weblogic, Websphere, doriti sa aveti HTTPS pe server, doriti sa aveti basic/digest/form authentication, trebuie sa va semnati aplicatia cu un certificat de test generat tot de voi, cum tineti minte care sunt URL-urile pentru API, documentation, manual de utilizare, reference page, cheat sheets, downloads page, etc. Cum reusiti sa tineti minte toate chestiile astea? Le notati undeva? Sau le cautati de fiecare data pe Google?

Sub JME – Java card si Smart cards (Part 1)

Dupa cum bine se stie in aria de Java, avem 3 platforme de dezvoltare: JEE (aplicatii enterprise, application servers, web stuff), JSE (desktop applications, Windows forms, GUI, Swing/AWT/SWT) si JME (MIDP si CLDC, aplicatii pentru device-uri cu limited capabilities (procesor+memorie), cum ar fi, in special, telefoanele mobile dar si frigidere, cuptoare cu microunde, etc).

Recent am citit niste stiri care, combinate cu curiozitatea nativa, m-au dus sa descopar inca o platforma, mai mica decat JME, si anume Java Card. In cele ce urmeaza doresc sa prezint cateva informatii legate de Java Card si Smart cards, urmand sa revin, intr-o parte a 2-a, cu informatii suplimentare, development process si sample-uri de cod.

Cum ar arata mail-ul…

… daca ar fi inventat astazi?

Recent, e un mare buzz in jurul unui produs de la Google, numit Google Wave. Sistemul este inca in varianta de preview, s-au adunat cereri de account-uri, Google a deschis un sistem de cereri si oferte de invitatii. Per ansamblu, tot mai multa lume vorbeste si comenteaza pe tema acestui nou sistem. Un film de prezentare de 1h 20min poate fi accesat aici, un film mult mai scurt cu 15 hot features din Google Wave poate fi vizualizat aici.

Exceptiile in Java

Vinerea care tocmai a trecut, cautand informatii legate de un cu totul al subiect (serialVersionUID in clasele Java), am dat peste postul asta: Plugins that generate serialVersionUID. Pe la 1/4 din post, discutia o ia putin pe aratura, si se trece la a discuta mecanismul de exceptii din Java, folosirea improprie a exceptiilor, si, lucru cel mai interesant, cam cum ar trebui de fapt sa fie acest mecanism de exceptii (in principal in Java, insa conceptele discutate, desi la un nivel nu foarte profund, totusi se pot aplica oricariu limbaj).

Din discutia curenta o sa las la o parte folosirea improprie a exceptiilor, si faptul ca oricat de safe sau de inteligent ai face un mecanism, pana la urma el se bazeaza pe folosirea judicioasa a facilitatilor oferite de limbaj. Asadar, dupa cum bine se stie, exista 2 tipuri de exceptii in Java: exceptii checked si exceptii unchecked (aka exceptii runtime).

Tot despre retele, dar sociale

Recent am dat peste urmatoarea gaselnita: XHTML Friends Network. Pe scurt, pe bloguri, la link-urile care de obicei sunt cuprinse in rubrica Blog Roll sau Links, se ataseaza atributul HTML ref=”xxx yyy zzz”, unde poti pune o serie de tag-uri prestabilite, indicand gradul tau de amicitie si modul in care ai cunoscut persoana catre care faci referire.

Mai concret, daca eu am blogul ionel.wordpress.com, iar Maria are blogul maria.wordpress.com, iar eu ca Ionel o plac pe Maria, atunci la link-ul catre blogul ei pun <a href=”http://maria.wordpress.com” ref=”met friend crush“>Maria</a>. Astfel prin tag-ul XFN “met” indic faptul ca am cunoscut-o pe Maria in real life, “friend” ca sunt prieten cu ea, si “crush” ca sunt mort dupa ea.

Pareri… testate

La proiectul la care lucrez acum la firma am terminat faza de implementare, am intrat in faza de testare, Q&A, testare, bug fixing (nu ca nu am fi facut si pana acum bug fixing), testare si… testare am zis? De-a lungul dezvoltarii acestei prime versiuni a aplicatiei, am descoperit o serie de “best-practices”, ca sa zic asa, chestii pe care le observam cat de misto/avantajoase sunt doar in punctele sau in momentele cand acestea ar fi trebuit sa existe, si nu erau. Practic lipsa lor ma facea sa imi doresc sa fie. Unul din aceste puncte este legat de unit-testing.

M-am decis asadar sa scriu un mic post, pe care intentionez sa il dezvolt pe urma intr-un articol mai detaliat, cu aceste “personal best-practices”, publicat eventual pe blog-ul meu. Pana una-alta insa, iata ce practici am descoperit ca sunt benefice cand scrii unit-tests.

Visul unui soft perfect

Mă gândeam zilele trecute ce puncte ar trebui să acoperi pentru a face un soft perfect. Aici, prin perfect, mă refer nu numai la îndeplinirea exactă şi completă a funcţiilor pentru care acel soft a fost conceput, nici la oferirea către utilizator a unei interfeţe intuitive, uşor de folosit, complet ergonomică, şi aşa mai departe. Mă refer în schimb la abilitatea soft-ului de a face faţă cu brio în orice condiţii ar fi rulat. Mă refer la abilitatea lui de a îşi adapta interfaţa la absolut orice necesităţi sau condiţii ciudate ar avea utilizatorii săi.

Prin urmare m-am decis să incerc să identific măcar o parte din cazurile în care soft-urile sunt puse în dificultate. Plec evident de la premiza că părţile care sunt în general adresate în proporţie cât mai mare de dezvoltatori (funcţiile soft-ului, utilizarea memoriei, interfaţa grafică, etc) sunt acoperite 100%. Prin urmare avem un program care nu are bug-uri, nu crapă sau se blochează, nu consumă toată memoria de pe maşina gazdă, nu are funcţii lipsă. Cu alte cuvinte, merge perfect.

Standardizarea in cadrul proiectelor – 2

In postul anterior am luat in discutie standardizarea la un nivel foarte jos in proiect, si am prezentat Maven ca un build system cu o multime de avantaje, care din start promoveaza un standard in structura modulelor. Este de ajuns sa lucrezi cu un singur proiect Maven, pentru a te adapta usor si a-ti gasi drumul in absolut orice alt proiect/modul Maven.

Trec mai departe abordand impartirea pe module. Intr-un proiect anterior am avut o structura care mi-a placut foarte mult. Aplicatia era compusa din mai multe servicii, fiecare serviciu publicand o serie de functionalitati catre celelalte servicii. Prin urmare am hotarat ca fiecare serviciu sa aiba cel putin 3 module Maven: interfaces, business si persistence.

Standardizarea in cadrul proiectelor – 1

In cadrul proiectelor la care am luat parte, am intalnit atat situatii in care se foloseau anumite standarde sau conventii (formale, gen coding conventions, naming conventions, cat si ne-formale, cum ar fi numele directoarelor dintr-un anumit modul, numele fisierelor SQL, modul de abreviere a serviciilor sau a componentele, samd) cat si situatii in care aceste standarde/conventii lipseau.

Cu ocazia acestor intalniri, am experimentat senzatia placuta si confortul pe care ti le da un proiect bine organizat (chiar daca dupa niste reguli proprii acelui proiect) si disconfortul si frustrarea rezultate din interactiunea cu un proiect in care domneste haosul, fiecare contribuie la proiect in maniera proprie si fara niciun fel de respectare de reguli, de ajungi sa te intrebi cum de merge acea aplicatie si cum de chiar face ceea ce trebuie.

Clientul nostru, stapanul… cui?

Evident tot al nostru. Insa de-a lungul proiectelor prin care am trecut, m-am aflat de cateva ori in situatia de a avea de ales intre doua optiuni care ambele corespundeau cu cerintele functionale ale proiectului, ambele erau (aproximativ) la fel de rapide/performante/consumatoare de resurse insa una era simpla de implementatt si confortabila pentru mine (in unele cazuri chiar f. placuta) iar cealalta era mai complicata insa rezultatul era mai dragut si mai user-friendly pentru utilizatorul componentei sau al aplicatiei pe care o dezvoltam.

Domain Oriented Programming

Privind retrospectiv la tipurile de programare si la modul de a scrie programele pe care le-am avut+experimentat pana pana acum, observ o evolutie foarte interesanta, evolutie marcata de utilizarea intr-un pas nou doar a pasului anterior. De aceea, doresc in articolul de fata sa prezint firul acesta al evolutiei, asa cum il observ acum si, cu putina fantezie, sa incerc sa il continui, ajungand astfel la o posibila conturare a modului “de maine” de a scrie programe si de a dezvolta software.

AsOP. Avem in primul rand Assembly Oriented Programming, caracterizata de scrierea de programe folosind instructiuni similare si apropiate (in unele cazuri chiar identice) cu limbajul cod-masina. Probabil ca asta nu a fost primul pas, probabil inainte am putea sa asezam scrierea de programe folosind cartelele perforate… nu stiu, e posibil. Pentru usurinta, o sa consider AsOP ca fiind primul pas.

In slujba cetateanului

Saptamana asta am avut de umblat o gramada prin oras si pe la diferite ghisee pentru a obtine actele pentru un leasing. Mergi la firma, la administrativ, obtine cererea de ridicare a cartii de munca, apoi mergi la ITM (Inspectoratul Teritorial de Munca), stai la coada 45 de minute, depune cererea, vino a doua zi, ridica respectiva carte de munca. Apoi mergi iar la administrativ, pentru obtinerea fisei fiscale, etc etc.

In toate peregrinarile astea, am dat peste o gramada de oameni, fiecare cu cate o problema, fiecare asteptand la niste cozi ce pareau ca nu mai avanseaza secolul asta. O multime de hartii, o multime de papetarie, acte, dosare, fisiere, dulapuri pline de cutii cu dosare si etichete, si altele. Am prins si o perioada nefasta a anului, si anume momentul in care persoanele autorizate din cadrul firmelor vin si depun fisele fiscale pe anul anterior. Fiecare cu 5-6 hartii in mana si cu discheta de 1.44 pe care se afla fisierele cu datele pentru viitoarele fise fiscale. Pentru fiecare persoana asteapta sa se preia acele hartii si discheta, asteapta ca (saraca) tanti de la ghiseu sa le proceseze, urmand ca apoi fiecare persoana sa se intoarca dupa cateva zile sa ridice noile fise fiscale.

Expresivitatea numelor

O sa ma leg astazi de o chestie foarte mica, care insa ma deranjeaza destul de mult, mai ales in ultimul timp. As zice ca se incadreaza in categoria “Claritatea codului” (fac referire catre Outsourceing, ownership si cod mostenit, Hardcodari si personalitate, si La ce nivel, in echipa?). Este vorba de numele date claselor, de modul in care cineva decide cum trebuie sa se numeasca o clasa.

Evident aceasta numire este destul de scazuta in importanta. Adica ok, te gandesti, alegi un nume expresiv, si gata, treci mai departe, gandindu-te ca de fapt e important cum implementezi acea clasa, cum o relationezi cu celelalte clase si interfete din cadrul codului tau. Insa nu e chiar asa.

OS Santa

Draga Mosule, fiindca am fost baiat cuminte all my life, am ceva dorinte pentru tine. Specific, as vrea niste chestii modificate in sistemele de operare (si aici ma refer la OS ca si produs in general, nu la Windows, Linux, Mac, etc). Mai exact, am stat si m-am gandit, si sincer chestii gen transparenta, Aero, Beryl & Compiz si chestii de genul asta sunt dragute, insa nu sunt functii pe care sa le astept asa de nerabdator de la producatori. Prin urmare iata ce imi doresc.

(Disclaimer: stiu, Mosule, ca s-ar putea unele chestii sa fie fanteziste sau inutile, dar oricum, si anul trecut ti-am cerut chestii fanteziste, si mi le-ai adus, asa ca poate merge si tura asta ).

Functii IDE (in)utile

Citind articolul lui Alex de ieri cu privire la unelte UML, in care mentiona Borland Together, mi-am adus aminte de unele functii de prin IDE-uri si unelte RAD (Rapid Application Development) care si acum si si la vremea la care am folosit respectivele unelte, mi s-au parut inutile. Asta, sau poate modul in care sunt obisnuit sa lucrez sau exigenta pe care o cer de la codul pe care il scriu nu se potriveste cu aceste functii bagate pe gat de catre IDE-uri.

Dar sa le luam pe rand.

Versionarea interfetelor

O sa scriu astazi despre o problema care apare atunci cand incercam sa materializam idealul de cuplare cat mai slaba a componentelor sau vrem sa comunicam cu sisteme externe existente, si definim cu grija interfetele dintre aceste componente, timpul trece, si la unele dintre interfetele componentelor vrem sa aducem mici/mari modificari. Problema este, insa, ca restul componentelor sunt deja in productie, si ne trezim astfel ca unele componente trebuie mai nou sa stie sa accepte si clientii noi dar si clientii vechi in dialog. Problemele apar atat in interfata propriu-zisa (in care trebuie sa reflecti versiunea folosita de client si server pentru comunicare) cat si in cod, unde deodata ai 2 sectiuni de cod foarte asemanatoare dar nu identice, care trebuie sa parseze mesaje sau request-uri venite de la clienti de versiuni diferite.

Caut baterii la privighetoare

Din multimea oamenilor care militeaza pentru ceva vreau astazi sa ma refer la cei care militeaza impotriva “digitizarii” lumii din jurul nostru, impotriva tuturor gadget-urilor si a roboteilor si in general impotriva a tot ce inseamna digital/mecanic in viata noastra. Nu sunt unul dintre ei, sunt chiar pro tehnologie digitala si mecanica, insa unul din punctele lor de vedere imi tot revine de ceva timp in minte si mi se pare interesant de abordat.

Acum vreun an mi-am redescoperit pasiunea pentru cartile SF. Intr-una din aceste carti, mai exact “Naked Sun” de Isaac Asimov, se prezinta o situatie sociala foarte interesanta si puternic legata de ce mentionam mai sus. Stiu ca e plictisitor, dar bear with me, ajung repede la subiect: pe planeta Solaria, putin mai mica decat Pamantul insa cu aceleasi conditii atmosferice si climatice, sunt aproximativ 10.000 de locuitori, fiecare detinand undeva intre 1000 si 10.000 de roboti. Fiecare solarian detine pamanturi intinse, care sunt lucrate de roboti. In casa muncile sunt facute iarasi de roboti, practic fiecare masinarie si device din casa avand un singur scop: acela de a il multumi pe proprietar.

Spamul coardelor sensibile

Doresc, cu ocazia invitatiei lui Dan de a scrie pe cultivatinro pentru ziua de vineri, sa ating un subiect ciudat si probabil ignorat de multi. Spam-ul sentimental.

Ziua de lucru incepe normal: deschizi calculatorul, deschizi Outlook/Thunderbird/Gmail/Ymail, citesti cele N mail-uri, stergi sau marchezi ca spam cele M mailuri cu ceasuri, Viagra, auto insurance, amenintari cu moartea, castiguri la loteriile din UK, transferuri in care tu castigi sigur milioane de lire sterline, etc dupa care te apuci de lucru.

Totusi in noianul asta de mailuri nedorite, se evidentiaza o categorie, e drept putin numeroasa, de mailuri menite sa atinga corzile sensibile (a se citi sa faca secretarele sa lacrimeze). Sunt acele mailuri ce contin ingerasi, peisaje, poduri, masini traznet, copilasi care au nevoie de o donatie si s-au asociat cu AOL/Yahoo/Google/MSN/etc. Aceste mailuri TREBUIE trimise la 2500 de prieteni, altfel o catastrofa se va intampla in urmatoarele 5 minute.