joi, septembrie 29, 2005

Carti ordonate.

Cu un efort considerabil mi-am ordonat cartile de Java.
A rezultat un total:

Total disks: 1 (1.56 GB), folders: 13 (1.56 GB), files: 350 (1.56 GB)

Pe edituri:

Addison Wesley 265,067,749
Apress 10,666,306
Diverse 148,888,003
Hungry Minds 66,740,179
Manning 317,060,164
ORelly 164,153,946
Pragmatic 7,745,300
Prentice Hall 210,732,448
Sams 47,936,970
Sun 67,459,036
Sybex 18,011,245
Wiley 205,537,916
Wrox 150,860,675

Lista completa de carti.

UNELTE UML


Mai demult, pentru diagrame UML am lucrat cu Together de la Borland. Un mediu sofisticat care mergea mana in mana cu JBuilder. Cum JBuilder o sa mearga mana in mana cu Eclipse iar eu ador Eclipse, cautarile mele sau indreptat spre un plugin pentru acest IDE.

Pe net am gasit Together ca plugin pentru eclipse (practic nu am reusit sa il integrez in distributia mea de Eclipse ci doar instalat cu propria distributie). O unealta la fel de sofisticata ca si Together SOLO sau cu JBuilder. Arata foarte bine, si e clar ca poate foarte multe. Din fericire am invatat ca dintr-un model trebuie desenat doar ceea ce este essential si nu intreg businessul. Sper sa il folosesc cu succes o luna pana expira key-ul.


Am mai gasit o unealta care se pretindea plugin Eclipse – Poseidon UML (deabia intr-o versiune superioara se poate integra cu Eclipse). E un Community Edition si e util in desenare. In versiunile superioare permite conversii spre cod. Dupa parerea mea, acesta e un lucru nesemnificativ. Modelul conceptual este cel important - UML la nivel de concepte abstracte si nu la nivel de implemntare. La salvare marcheaza ca diagrama nu poate fi folosita in productie. O unealta sofisticata, cu un design nemaivazut – oare in ce e facuta (prima oara am crezut ca e Swing cu un Look and feel dragut dar am mari indoieli). Demn de testat si de folosit.


Ultimul incercat e OMONDO - un adevarat plugin pentru Eclipse. Mai putin spectaculos in versiuna free, dar care promite multe. Foloseste cu adevart resursele Eclipse. Merita urmarit mai ales pentru ca incearca sa tina pasul cu framework-urile care aduc aplicatiilor arfitectura (e un lucru real chiar daca nu ati observat poate asta).




Pentru UML exista 2 genii care au scris carti pe masura (... sunt si in colectia mea de carti nemuritoare :) ):

Martin Fowler - a scris printre altele -> "UML Distilled"
Scott Ambler -a scris printre altele -> "The Object Primer"

vineri, septembrie 16, 2005

Domain Driven Design -> citate

Inca doua citate din Domain Driven Design. Autorul da si un exemplu clar intre modelarea obiectuala si “modelarea” procedurala a unei aceeasi probleme.

“Object-oriented programming is powerful because it is based on a modeling paradigm, and it provides implementations of the model constructs. As far as the programmer is concerned, objects really exist in memory, they have associations with other objects, they are organized into classes, and they provide behavior available by messaging. Although many developers benefit from just applying the technical capabilities of objects to organize program code, the real breakthrough of object design comes when the code expresses the concepts of a model. Java and any other tools allow the creation of objects and relationships directly analogous to conceptual object models.”


“MODEL-DRIVEN DESIGN has limited applicability using languages such as C, because there is no modeling paradigm that corresponds to a purely procedural language. Those languages are procedural in the sense that the programmer tells the computer a series of steps to follow. Although the programmer may be thinking about the concepts of the domain, the program itself is a series of technical manipulations of data. The result may be useful, but the program doesn't capture much of the meaning. Procedural languages often support complex data types that begin to correspond to more natural conceptions of the domain, but these complex types are only organized data, and they don't capture the active aspects of the domain. The result is that software written in procedural languages has complicated functions linked together based on anticipated paths of execution, rather than by conceptual connections in the domain model. “

miercuri, septembrie 14, 2005

Domain Driven Design - Tackling Complexity in the Heart of Software

In sfarsit o carte cu adevarat palpitanta: Domain Driven Design - Tackling Complexity in the Heart of Software.

Este asa, pentu ca trebuie sa rezolv o mare problema care ma preocupa. Refuzul interior de a lua contact cu business-ul abordat. Pentru mine au devenit foarte importante tehnologiile, in special framewor-urile. Dar ele nu reprezinta nici pe departe ceea ce trebuie facut in aplicatii ci mai mult cum trebuie facut. Ele sunt mai mult unelte care te ajuta sa implementezi un business. Dar nu ele dau valoare intrinseca apliactiei.

Dezvoltarea domeniului aplicatiei e ceva ce neglijez de mult. Parca ceva in mine refuza sa ia contact cu business-ul de orice natura ar fi el. Pentru ca e complicat, si nu are o valoare continua. E util numai pentru aplicatia curenta. E complex, e extrem de complex.

E foarte interesant raportul tau cu business-ul modelat. Intr-un fel trebuie sa il cunosti foarte bine pentru ca altfel te blochezi in implementare dar nici nu trebuie sa iti murdaresti prea tare mintea cu el. Deci trebuie sa iei din el o esenta care sa te lege de el. In principiu trebuie sa-I creezi un model, care este o abstractizare a domeniului respectiv care surprinde numai aspectele importante, oricare ar fi ele. Si pe care trebuie sa il stapanesti. Nu te poti lega de business prin amanunte, care se schimba cel mai des. Trebuie sa te legi printr-un model care reprezinta o parte tare.

Cateva citate:

“A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.”

“Domain modeling is not a matter of making as "realistic" a model as possible. Even in a domain of tangible real-world things, our model is an artificial creation. Nor is it just the construction of a software mechanism that gives the necessary results. It is more like moviemaking, loosely representing reality to a particular purpose.

Even a documentary film does not show unedited real life. Just as a moviemaker selects aspects of experience and presents them in an idiosyncratic way to tell a story or make a point, a domain modeler chooses a particular model for its utility.”

“Instead, the technical talent goes to work on elaborate frame-works, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.”


“There are systematic ways of thinking that developers can employ to search for nsight and produce effective models. There are design techniques that can bring order to a sprawling software application. Cultivation of these skills makes a eveloper much more valuable, even in an initially unfamiliar domain.”

miercuri, septembrie 07, 2005

MONSTRI SACRI

Monstrii se aduna impreuna. Rod Johnson si Martin Fowler, Interface 21 si ThoughtWorks (cine stie cunoaste). Mai multi monstrisori pe blogul lui CAMERON PURDY. Printre ei Floyd Marinescu, Bruce Eckel, etc. Spor.

joi, septembrie 01, 2005

From Eclipse IDE

I publish from Eclipse. So, there are some many methods to make post's in Blogger: from Microsoft Word, from blogger itself, from mail, from my mobil phone, from my preferate IDE -> Eclipse. I make a god chose!!! Yaaa!