marți, noiembrie 21, 2006

INDEED
Indeed este un site pentru cautare de job-uri (jobs engine) la fel ca Dice, Monster, etc. Ce mai important sunt clasamentele care pot fi facute referitor la evolutia cererii de job-uri pe anumite tehnologii (jobs trends).


Pe acest blog sunt si alte comparatii interesante. Alte comparatii le puteti face chiar voi aici.

Observcatiile ar fi urmatoarele, urmarind blog-ul precedent:

- numarul de Job-uri pentru JSF s-au dublat fata de martie acelasi an (2006) - posibil si datorita faptului ca librarii de componente ca ADF, ICEFACES au devenit open source.

- Struts pare avea aceeasi cautare precum batranul Cobol; a ramas in urma cu tot cu infuzia de WebWorks din versiunile 2.x; Spring MVC pare a fi cel mai cautat framework bazat pe cerere raspuns (request/response)

- Spring o sa depaseasca EJB(3) in viitorul apropiat; e posibil ca EJB sa fie doar studiat in curand in scoli ca fiind parte din istoria evolutiei limbajului Java

- Hibernate e leader in ORM-uri; celelalte framework-uri de persistenta se bat sa existe

- Ruby on Rails se pare ca e mai mult studiat decat folosit

Ce se poate desprinde din toate astea pentru Romania. Mai nimic din cate imi dau seama. Aici o sa se foloseasca Struts 1.1 chiar si cand nu o sa se mai foloseasca in restul lumii. EJB 2.0 o sa fie folosit si cand pentru altii o sa fie istorie.

joi, septembrie 07, 2006

Thinking in Java

In final mi-am achizitionat Thinking in Java 4. Dupa cum se stie Bruce Eckel nu mai ofera versiunea 4 din TIJ pe net. Se pare ca s-a hotarat sa stranga niste bani pentru batranete.

Cartea este o caramida (chirpici in traducere libera), numai buna de a o pune la temelia unei case. Groasa si scrisa cu caractere destul de mari.

De remarcat faptul ca se refera la JDK 5 si 6. Deci este o carte actuala. A introdus capitol de Generics. De asemenea a modificat fundamental Concurenta adaugand modificarile din JDK 5. Si altele.

vineri, septembrie 01, 2006

Modularizarea aplicatiilor Web

Am admirat intotdeauna Eclipse prin modul plugin-abil in care este construit. De fapt cred ca acest aspect face diferenta intre Eclipse si alte IDE-uri care nu au fost costruite modular de la inceput. In fapt Eclipse este un nucleu care permite integrarea de plugin-uri. Acestea se incarca dinamic in runtime cand este nevoie de ele. Un fel de initializare tarzie (lazy initialization) - programatorii vor intelege. Platforma Eclipse inseamna cam 100 de plugin-uri care lucreaza impreuna.

Cum se pot construi aplicatii Web modulare? Mai intai, prin modularitate intelegem gruparea functionalitatilor aplicatiei in module distincte. Poate fi vorba despre o simpla inpartire a aplicatiei prin separarea modulelor componente in directoare diferite. Sau poate fi mai mult. Se poate ca fiecare modul particular sa contribuie la un anumit aspect generic al aplicatiei introdus probabil de un alt plugin. Spre exemplu fiecare modul sa aduca propriile intrari in meniul bara al aplicatiei. In momentul in care un modul este scos din aplicatie si intrarile lui din bara de meniu devin inaccesibile. Acesta este un mic exemplu.

In primul caz, daca este vorba despre o inpartire a aplicatiei pe directoare lucrurile sunt destul de simple. In principiu, pentru fiecare modul de business se poate construi un modul in aplicatie. Se creaza cate un director pentru fiecare modul in care se pun fisierele de configurare si sursele corespunzatoare modulului. Struts, Hibernate si alte framework-uri Web permit fisiere de configurare per module si deci acestea vor fi trimise in deployment la locul dorit. In cazul in care framework-ul dorit nu ofera asa ceva, se poate folosi urmatoarea strategie. Se editeaza in local fragmente de fisiere XML care sunt asamblate in deployment via ant. Deci in deployment se recompune fiierul de configurare final obtinut prin asamblarea de fragmente. La fel si sursele prin compilare ajung drept clase la locul dorit in deployment. Structurarea lor pe module poate fi data de numele ales pentru pachete.

In cel de al doilea caz lucrurile sunt mai complicte. Sa luam cazul IDE-ului Elipse. Fiecare modul=plugin al IDE-ului Eclipse poate oferi puncte de extensie pentru celelalte module prin declararea unui punct de extensie. Astfel altii pot contribui la propia ta contributie. Punctul de extensie se declara folosindu-se id sau nume in fisierul plugin.xml din modulul respectiv. De asemenea se specifica print-un template xml valid si ce atribute si proprietati trebuie sa aduca plugin-ul care implementeaza punctul de extensie. Acesta (alt plugin) trebuie sa dea valori reale variabilelor din template pastrand sintaxa. Se poate defini si o clasa care va parsa xm-ul in momentul incarcarii plugin-ului si care va dicta funtionalitatea.

Alte module sau chiar modulul in cauza pot aduce implementari acestor puncte de extensie. In declararea si implementarea de extensii pot aparea nume de clase. Ele se dau in forma completa continand si numele pachetul si trebuie sa se afle in CLASSPATH pentru runtime. Se poate preciza si o dependenta intre plugin-uri specificand pe cele ce se vor incarca inaintea plugin-ului curent.

Asa e cu Eclipse care permite prin acest sistem constructia de clienti bogati peste platforma Eclipse (desigur trebuie ceva dexteritate pentru ca pare o altfel de programare). Dar cum ramane cu Web-ul? Dupa cateva rataciri am gasit un raspuns: HiveMind. Initial am crezut ca Spring-ul pe care l-am folosit cu succes in trecut poate fi solutia, dar Spring e doar un container de servicii si un integrator de framework-uri. El singur nu ofera un mecanism de modularizare pentru aplicatiile Web asa cum e Eclipse pentru clientii grei. O posibila solutie auxiliara poate fi extensia pe care o ofera in Spring Modules pentru Hivemind, EL4J sau noile posibilitati de a defini fisierele de configurare din 2.0.

Daca ati lucrat cu HiveMind va puteti impartasi experienta la comments!

duminică, august 13, 2006

MUNTII ROMANIEI

Departe în munţi, ascuns printre stânci /Se află bătrânul refugiu / Acolo se întâlnesc acei ce iubesc / Pereţii de stîncă şi cerul.

Nu-i nimeni să-i înţeleagă / Nu-i nimeni la fel ca ei, la fel ca ei / Doar dorul în dulce leagăn / Să urce spre creste mereu.

Mi-e inima-n furci, de vrei poti să urci / Să faci primii paşi în perete / Speranţa apoi s-o facem în doi / Să urci cât mai sus către creste.

duminică, iunie 18, 2006


ZALMAN

Saptamana trecuta mi-am schimbat coolerul din cauza zgomotului infernal pe care il producea. Am ales ZALMAN CNPS7000B. Montarea a fost extrem de usoara, chiar relaxanta as putea zice. Sistemul e un AMD BARTON la 2600+ pe o placa de baza ASUS A7V600.

Sistemul l-am cumparat pe bucati si asamblat cu mainile mele acum 2 ani. Coolerul e unul din putinile lucruri care m-au deranjat chiar de la inceput. Am scapat de el. A mai ramas ventilatorul de sursa. Un alt zgomotos. Mi-am pregatit deci calculatorul de vara. Ce ma surprinde este viteza cu care evolueaza piata de hard. Atunci cand am cumparata stiam tot ce ofera piata. Acum sunt surprins de dimensiunile la care a ajuns totul si noii jucatori de pe piata. Cu siguranta softul nu face fata la o asa crestere. Deci este de mancat mult si bine in programare!!!

sâmbătă, iunie 10, 2006

Orice nas isi are nasul


Week-end-ul trecut am fost nasi pentru prima oara. Pentru mine au fost o multime de emotii chiar daca trebuie sa recunosc ca este un rol mai usor decat cel de mire si chiar decat cel de cavaler de onoare. Asta in ceremonii, dupa nunta ar trebui sa fiu mai activ :) . Una peste alta toate au trecut cu bine. S-au facut si un munte de poze din care, o mica particica le-am postat pe Flickr.
category: ,

duminică, mai 14, 2006

Viitorul suna foarte bine pentru interfetele Web

Am sa vorbesc despre JavaScript. Trebuie sa recunosc ca limbajul de scripting pe care il uram cel mai mult tinde sa devina foarte importnat in viitorul aplicatiilor Web. Il uram pentru urmatoarele aspecte: greu de depanat, greu de mentinut, nestandard intre browsere. Probabil problema mea este faptul ca nu am considerat JavaScript un adevarat limbaj de programare. El chiar este asta. Trecand peste faptul ca browserul ofera via JavaScritp o serie de obiecte care permit accesarea structurii logice a paginilor randate, JavaScript este un limbaj in care poti crea propriile tale obiecte. Deci, surprinzator este un limbaj de programare (scripting) obiectual.

Lucrurile au evoluat, de la prima mea intalnire cu JavaScript. Ce s-a intamplat in ultimul timp este aparitia framework-urilor si librariilor JavaScript. Pentru a distinge o librarie de un framework, in cazul unui framework, codul aplicatiei este apelat de framework, in cazul unei librarii, codul aplicatiei apeleaza libraria.

Prima concentrare a fost o incercare de a crea librarii de efecte sau de componente. Urmatorul pas este conturarea unor librarii JavaScript mai complexe care sa inglobeze un stil de programare, suport pentru diverse functionalitati tehnice, etc. Printre ele cele mai semnificative ar fi script.aculo.us si Dojo toolkit. Script.aculo.us este larg raspandit in lumea programatorilor de Ruby on Rails, fiind inclus si in distributiile acestuia. Dojo tinde a fi adoptat de lumea Java fiind inclus in WebWorks si deci in viitorul Struts Action 2. Este integrat si in Tapestry.

Totul a inceput de la prototype, un framework peste care scriptaculous a fost construit. Ideile principale din prototype sunt accesarea in mod unitar a elementelor paginii prin apeluri de genul node = $("elementID") in loc de node = document.getElementById("elementID") si alte functii de acest gen. Un alt aspect este construirea unor obiecte predefinite pentru acces asincron spre server de tip AJAX. A se vedea de asemenea si Behaviour care permite scoaterea apelurilor de JavaScrip inafara codului HTML - consider o mare realizare pentru claritatea aplicatiei. In fapt script.aculo.us aduce electe si componente peste prototype. Am avut ocazia sa testez FLUXIOM si sunt placut impresionat de ce se poate face cu script.aculo.us. Tot prototype sta si la baza RICO (vine de la Rich Internet Aplications) un alt set de componente-efecte demn de admirat.

Dojo imi este oarecum strain chiar daca, ca om de Java ar trebui sa fie preocuparea mea de baza. Se pare ca provine dintr-o incercare de unificare a mai multor librarii DHTML si are un aer mult mai ingineresc decat script.aculo.us care e frumos ca design. Poate acesta e si motivul apropierii de Java care vine dintr-un mediu ingineresc cum e cel de la SUN. O prezentare o puteti gasi aici. Observati motto-ul: “JavaScript is not a bug that needs fixing”.

Alte lucruri interesante despre JavaScript. Cei de la yahoo ofera gratuit o librarie de componente si efecte bine documentata pe care o puteti gasi aici. Dar ce e mai interesant este o colectie de patternuri grafice pe care o puteti gasi aici. Aceasta incearca sa surprinda problemele comune care pot sa apara in interfetele grafice, o sintetizare a lor si solutii comune. E prima oara cand vad asa ceva pentru interfete.

O alta aplicatie care m-a impresionat grafic este Mint, un produs pentru auditul intern al sit-ului. Nu stiu cum a fost realizat si daca are la baza o librarie cristalizata pentru interfata. Stiu ca in partea de server e facut cu PHP. Probabil cel care l-a realizat shaun inman e un bun designer pentru ca blog-ul lui e la fel de placut. O alta aplicatie care m-a impresionat ca design este Base Camp , un soft de management de proect care contine multe elemente noi de design. Este facut in Ruby si probabil cu scriptaculous. La fel si celelalte produse ale 37signals.

In rest, cam toate interfetele pe care le-am vazut si la care am lucrat sunt bazate la fel pe vechiul refresh pe intreaga pagina Web. Intadevar cu mai multe briz-briz-uri. Cele enuntate mai sus folosesc AJAX cu refresh pe componenta si apeluri asincrone spre server. De asemenea au efecte cinematice, colectii de componente si ofera apropiere mult mai mare de modul in care sunt facute aplicatiile de descktop.

Intr-o zi am descoperit un produs minunat care se cheama Javeline Desk Run care iti permite sa rulezi o aplicatie web ca una de descktop. Cand o sa fie prima aplicatie web care nu se va distinge de una de descktop?
category: , , ,

duminică, aprilie 23, 2006

Dihaniile cele cu doua chicioare

Mari suflet au dihaniile chele cu doau chiciare, sa fie ele sanatoase.


Pe cat esti tu de gras esti tu si de naiv.


Iesi la libertate prikoke.


Tu nu ai avut nimic niciodata, de-atat iti pare ca ai tot.


Un clip moralizator, care poate schimba cate ceva in viata ta. La mine a dat roade...

duminică, martie 05, 2006

Samorost

Imi amintesc cu nostalgie de vremurile in care jocurile pe calculator erau principala mea preocupare. Pentru mine totul a inceput in liceu cand mi-am luat primul calculator personal - CIP (o clona de Z80) cu 64K memorie si cu BASIC ars in memorie. Primul joc imi amintesc ca se numea Venon. Stransesem atunci cateva sute de jocuri pentru Z80 pe casete audio. Vremurile acelea au trecut, pentru mine jocurile complicate de azi nu mai prezinta nici un interes. Dar, jocurile Flash au ceva din simplitatea celor din trecut. Un mic exemplu ar fi urmatorul Samorost pe care l-am savurat 0 jumatate de ora in week-end! E captivant! Spor!

joi, februarie 23, 2006

Domain Driven Design and enterprise applications

Am decis sa public din cand in cand in engleza. Mai ales aspecte tehnice. Un mare ajutor am gasit in autocorect-ul si autosugest-ul din Word. De asemenea dictionarul Babylon. Mai demult foloseam Everest. Intrarile in engleza le voi posta pe JRoller alaturi de ceilalti weblogeri din Java. Voi publica pe blogger doar fragmente.


I was very confused after read mister Eric Evans book Domain Driven Design. Is a big contrast into the day to day style I work and what he say in his book about rich object domain. Why they blame the transaction script approach? But now I think this:


Ideas

- enterprise applications are just a data transport centric model for transporting data from presentation to data source and vice versa

- the business domain notions are reflected in database, business and also in presentation and we must try to reuse as much is possible objects and name conventions ( not over configuration yet) (in my case I reuse VO?s and methods names)


The refined architecture

The architecture is about the integration of the parts in the whole. And is about decisions in this sense. The best refined enterprise architecture that is in now in my mind is this (is a decoupled, layered enterprise architecture; I ignore the modularization, exception handling, security and ther specific aspects).

..................

The domain for me is formed from two classes of objects: the services who are a sort of entity objects and VO?s the value objects. VO?s are used for transporting data into the applications packages and into layers. Services are just a way to accessing data from the presentation perspective using value objects (generally are singletons).


The first modeling is the database and here I expect to identify the domain language (the words who express the domain). Then the VO?s who maps to the database tables will represent this words. But the perspective is meet in the middle style in sense that one end of the application is the interface, and the other end is the database. And the junction point is in the middle between the service package and DAO package. Services reflects the view and DAO reflects the database. DAO?s are coarse grained and services uses them in a ne to many relation.

..................


Conclusion: we must clarify some things

For our happiness we must clarify some things:

1) The enterprise applications are doing just data transporting from interface to database and vice versa in a distributed way? They represent a a game between this ends: the presentation and the data source with some calculation and services in the middle? Because your application is distributed you must control the objects proliferation? For distribution style you are constrain by the JVM threads to use a procedural style? In what way you will manage your persistent data. What are the ways to offer services to your application?


2) What is the role of modern frameworks in our applications (they come with architecture for our applications as a part of inversion of control style). And if you use a framework (like a Web framework ~ Struts, JSF, a light container like Spring or Hivemind, or a ORM framework ~ Hibernate, iBatis) you adhere to an architecture. What is the influence in your modeling?

category: , ,

miercuri, februarie 15, 2006

Effective Java

A trecut destul de mult timp de la ultimul post pe blog in timpul acesta m-au vizitat aproape 150 de persoane dupa cum se poate vedea aici. Vizitatorii sunt cu precadere din Europa si State dar si din alte tari ale lumii: cred ca printre ele si Indonezia si China.

Zilele trecute am vizionat in fuga un interviu cu Josh Bloch si Neil Gafter realizat la JavaPolis 2005 de Ted Neward (trebuie sa va faceti un cont pe acest site pentru vizionare). Undeva se vorbea despre o noua versiune a cartii Effective Java. Din curiozitate am rasfoit-o din nou dupa mult timp. E o carte in care se prezinta succint aspecte ale limbajului care ar putea creste calitatea programelor scrise in Java, asa cum marturiseste autorul, mai mult din punct de vedere al claritatii si nu a performantelor (dupa cum stiti optimizarea se face la urma sau deloc).

Josh Bloch a lucrat de la inceputuri ca inginer la Sun chiar in realizarea API-urilor limbajului si este unul din putinii care ar fi putut scrie aceasta carte. In prezent impreuna cu Neil Gafter lucreaza pentru Google si au marurisit ca aceasta firma este foarte interesata de Java. Am auzit de unii romani care lucreaza pentru Google dar nu e acelasi fenomen cum e in cazul Microsoft. Ce e foarte interesant e ca Bill Gates a afirmat ca rivalul Microsoft este IBM si nu Google.

In Effective Java sunt principii de bun simt, pe care din graba sau dezinteres tindem sa le neglijam sau ignoram crezind ca codul nostru nu o sa mai fie niciodata citit. O mare eroare, pentru ca e sigur ca vom scrie codul o data dar de citit il vom citi noi sau altii de mai multe ori.