vineri, octombrie 26, 2007

Our new car!

In final a venit Fordul (un Ford Focus in 4 usi). E mai frumos decat ne asteptam. A venit fix in 2 luni. Timpul promis de dealer.

Mai multe informatii daca doriti sa va luati un ford. Sunt doar trei dealeri in Bucuresti:

Mai multe informatii pe forum. Se pare ca service-ul e jalnic. O sa vedem prima oara cand o sa avem nevoie.

miercuri, octombrie 24, 2007

Software on Windows

Ce as dori sa am instalat pe o masina Windows pentru dezvoltare Java. Intradevar pe unele le-as dori pe o alta masina - cele care ar sta pe un server (eventual un Linux). Am pus [OS] acolo unde sunt free (e clar ca messenger-ele spre exempu nu au licenta open source!). Cele comerciale le-am adnotat cu [CO].

Am dat echivalent free pentru cele comerciale. Am sa incerc sa tin lista actualizata. Le gasiti si descarca cu siguranta de pe softpedia.com. Acolo le puteti compara cu altele din clasa lor.

duminică, octombrie 21, 2007

Arhitectura unui sistem

Nu putem sa vorbim despre lucruri atat de inalte fara a face referiri la inaintasi. Martin Fowler in articolul sau Who Needs an Architect, pune o intrebare interesanta Ce este un architect? Pentru aceasta trebuie sa raspunda la o alta Ce reprezinta arhitectura unei aplicatii? Si pentru aceasta este nevoit sa dea o definitie arhitecturii. Pentru asta face cateva incercari reusite:

“…the highest level concept of a system
in its environment. The architecture of a software
system (at a given point in time) is its organization
or structure of significant components
interacting through interfaces, those components
being composed of successively smaller components
and interfaces.”

“In most successful
software projects, the expert developers working
on that project have a shared understanding of the
system design. This shared understanding
is called ‘architecture.’ This understanding
includes how the system is divided into
components and how the components interact
through interfaces. These components
are usually composed of smaller
components, but the architecture only includes
the components and interfaces that
are understood by all the developers.”

“…architecture
is the set of design decisions that
must be made early in a project.”

De aici se desprinde ca arhitectura implica:

  • o viziune asupra componentelor constituiente ale unui sistem si a interactiunilor dintre ele
  • un consens intre membrii unei echipe
  • un set de decizii corecte care trebuie luate, sau mai bine zis ar fi de preferat sa fie luate

O greseala des intalnita este aceea de a considera ca rolul arhitecturii e acela de a crea sisteme optimizate. Adevaratul scop al arhitecturii este acela de a oferi o usoara mentenanta a sistemului, faza cea mai lunga a existentei unui proiect. Deci este o chestiune mai mult de organizare, o metoda de a gestiona complexitatea unui proiect prin sinteza, analiza si experienta.

Deci arhitectura = mentenanta.

Desigur aspectele legate de optimizare trebuie sa constituie o preocupare de baza chiar din fazele initiale ale proiectului. Dar din nefericire la un moment dat toate presupunerile devin simple supozitii, daca nu sunt confirmate de masuratori. Trebuie tinut cont ca business-ul modelat evolueaza si complexitatea creste. Deci, undeva in faza finala a unui proiect, cand business-ul implementat este stabil, trebuie sa existe o etapa de masuratori (facute cu un profiler si folosind unelte de stess, load testing, etc. ), care sa spuna in numere performantele, scalabilitatea, etc. unui sistem (link). Un set de citate care confirma cele spuse:

“More computing sins are committed
in the name of efficiency (without necessarily achieving it)
than for any other single reason - including blind stupidity.” - W.A. Wulf

“We should forget about small efficiencies,
say about 97% of the time:
premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%.”- Knuth, paraphrasing Hoare

“The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!):

Don't do it yet.” - Michael A. Jackson

Deci arhitectura!=optimizare.

In principiu putem gandi arhitectura unui proiect indiferent de tehnologiile folosite. Dar trebuie sa recunoastem ca acestea in sine aduc/impun elemente de arhitectura sistemului. Framework-urile alease, implementarile de specificatii, librariile folosite sunt hotaratoare. Cele mai importante sunt cele care impun un model de programare cum ar fi cazul framework-ului Spring sau a specificatiei J2EE. Ele trec peste aspecte specifice cum ar fi prezentarea web, persistenta, spre a oferi o intreaga infrastructura aplicatiei, asa cume cazul serverului de aplicatii in cazul J2EE si a containerului IOC in cazul Spring.

miercuri, octombrie 10, 2007

Timpi in dezvoltarea proiectelor

Timpii in dezvoltarea unui proiect reprezinta faze din procesul de dezvoltare. In esenta se refera la starea proiectului care evolueaza prin treceri intre surse - dezvoltare si artifacte - runtime. Din acet motiv se pot confuda cu fazele clasice din build-ul unui proiectului (in Maven spre exemplu – build phases, in cazul ANT nu existe faze standard).

Modul de lucru consta in repetarea urmatorilor pasi:

  1. se editeaza sursele, resursele, testele unitare
  2. se face build pentru a obtine artifactele
    • in procesul de build se executa si testele unitare, eventual se populeaza baza de date cu date de test (plugin Maven, DbUnit)
  3. artifactele se deployaza in serverul de aplicatii (la rece sau la cald)
    • se poate face manual, folosi plugin-uri de maven, target-uri de ant, sau manageri pe care ii pun la dispozitie serverele de aplicatii
  4. se testeaza functional
    • manual in browser
    • folosind teste automate (Canoo WebTests, Selenium IDE)

Timpii de dezvoltare pentru un proiect:

  • edit time
    • se referal la scrierea/editarea surselor si a testelor
    • in dezvoltare proiectul are o structura de directoare proprie
      • structura de directoare este sicronizata cu SCM-ul pentru a fi accesibila celorlalti dezvoltatori
      • in Maven exista o structura predefinita, in pom.xml se marcheaza doar exceptiile de la reguli
    • in urma procesului de build vor rezulta artifactele pentru runtime (aplicatii enterprise, web, simple jar-uri)
  • design time
    • se refera la folosirea unui IDE pentru a face design
    • in cazul componentelor Swing sau JSF
  • generation time
    • se refera la generarea de surse
    • se poate folosi un famework de tip MDA
    • se pot folosi diverse plugin-uri de maven sau tarsk-uri de ant de generare
  • compile time
    • reprezinta procesul de compilare
    • in CLASSPATH trebuie sa existe toate dependintile utilizate in surse
  • boot time
    • reprezinta faza de startare a unei masini virtuale cu incarcarea resurselor
    • se refera la un server de aplicatii, containere usoare, micro kernel-uri
    • in general serverul incarca foarte multe resurse la startare, gen pool-uri de obiecte, pool-uri de working threads care sunt ridicare in container si ready de a accepta request-uri pe mai multe fire de executie
    • se prefera un timp pierdut in bootare decat timp pierdut in runtime
  • configuration time
    • reprezinta o faza din procesul de boot in care sunt cititesc fisierele de configurare si se incarca resursele descrise acolo
    • spre exemplu: faces-config.xml pentru JSF, struts-config.xml pentru Struts, application-context.xml pentru Spring, etc
    • si alte fisiere de configurare conform anumitor specificatii: web.xml pentru aplicatia web, application.xml pentru aplicatii enterprise, fisiere in care se declara MBean-uri JMX, etc
  • run time
    • reprezinta faza de rulare a aplicatiei intr-o masina virtuala Java (JVM)
    • JVM permite expunerea de porturi prin care clientii (in general IDE-uri) se pot conecta pentru debug, profiling, configurare/management in runtime, etc
    • in general in JVM se porneste un server de aplicatii care incarca mai multe aplicatii definite de dezvoltator
    • la pornirea masinii virtuale se porneste un thread din grupul run care executa metoda main dintr-o clasa publica expusa ca parametru (poate fi chiar serverul de aplicatii daca aplicatia nu este stand-alone – acesta ridica in runtime aplicatiile deployate)

luni, octombrie 08, 2007

Compozitie fizica

Principalul aspect al arhitecturii il reprezinta decompozitia: impartirea intregului in parti constituente. Aceste parti pot fi fizice sau logice(conceptuale). Incercam sa le enumeram pe cele fizice si mai apoi pe cele logice specificand legaturile dintre ele.

Prin componente fizice se inteleg acele elemente de compozitie care au o reprezentare fizica (in general elemente induse de un limbaj de programare care au o reprezentare in file system). Enumerate de la complex la simplu ele sunt:
  1. Aplicatie enterprise (.ear)
  2. Modul (module .jar, .war, etc – unitate de deployment)
  3. Pachet (package – ierarhie de directoare in file system)
  4. Unitate de compilare (compilation unit - fisier)
  5. Tip (type)

In sine ele au relevanta si prezenta fizica in unul din timpii proiectului: compile, runtime, configuration time, etc.

Aplicatie enterprise
Un astfel de element de arhitectura apare numai in cazul unei aplicatii construite conform J2EE (serverul de aplicatii are container de EJB-uri) - altfel este indeajuns un modul web.
Impartirea pe aplicatii a sistemului se realizeaza pe criterii de business si de executie in runtime (serverul de aplicatii).
O aplicatie enterprise este alcatuita din mai multe module – jar, war, ejb, etc conform specificatiei J2EE – aceste module sunt descrise intr-un fisier de configureare conform J2EE.
Daca sunt mai multe aplicatii care alcatuiesc un singur sistem, acestea se integreaza prin puncte stabile de acces: expunere de API-uri (interfete, DTO-uri, exceptii) eventual URL-uri stabile (REST) si in cel mai nefavorabil caz prin baza de date (expunere de view-uri).
Securitatea este gestionata de serverul de aplicatii impreuna cu celelalte servicii de middleware si poate fi partajata intre toate aplicatiile sistemului printr-un sistem SSO.
Este de preferat ca plicatiile sa gestioneaza propria lor schema de baze de date (eventual un spatiu de nume dintr-o schema) si sa expuna API pentru integrare (expuneme de functionalitati spre exterior).
Pot expune interfete-serviciu pentru integrarea cu alte aplicatii din alte sisteme (cu care pot rula in acelasi JVM sau pe JVM-uri diferite).
Injectarea de implementari de servicii se face in runtime via JNDI (aplicatiile pot rula in acelas JVM sau JVM-uri diferite).


Modul
Reprezinta un element fizic reprezentat print-un .jar, .war, etc deploy-abil in runtime.
Un modul special este cel web (.war) care necesita un container de servleturi si JSP-uri pentru runtime si contine tipuri specifice: servlet, filtru si resurse specifice: JSP-uri, fisiere de configurare.
Impartirea pe module se realizeza in general pe criterii de deployment.
Un modul este alcatuit in edit time din mai multe pachete continand types (pot contine si resurse).
Modulele sunt generate din edit time de o unealta de build - Maven – pentru fiecare modul sursele si resursele sunt stocate in locatii diferite in file system.
In editare reprezita de asemenea subproiecte de Eclipse.
In general ele corespund in plan conceptual unui subsistem reprezintand intersectia intre un layer tehnologic si un vertical slice de business, dar pot contine un intreg layer sau un vertical slice.

Pachet
Reprezinta un element fizic al arhitecturii – o ierararhie de directoare in file system.
Un pachet cuprinde mai multe unitati de compilare care sunt la randul lor elemente fizice.
Conceptual este parte a unui subsistem. Mai multe pachete alcatuiesc un subsistem.
Impartirea pe pachete se realizeaza pe criterii de business si tehnologice.
In denumirea unui pachet se gaseste astfel cel putin numele unui subsistem + un nume specific din cele enumerate in continuare:
- managedbeans
reprezinta legatura intre layer-ul de prezentare si domeniu (corestund Action-urilor de Struts)
- services
sunt reprezentate de SLSB's
- domain
cuprinde entitatile necesare (si) in procesul de persistenta (EJB Entity Beans)
intre ele sunt relatii de asociere
nu au logica ci doar stare (domeniu anemic)
- dto
cuprinde obiecte folosite in transportul intre layerele alicatiei (numite si VO – Value Objects)
obiecte surogat, doar cu stare fara funtionalitate/logica
- exceptions
exceptii custom ale aplicatiei - de sistem sau de business

Unitate de compilare
O unitate de compilare cuprinde unul sau mai multe tipuri (unitatea de compilare = compilation unit este un fisier .java).
In Java orice unitate de compilare expune cel putin un tip public – trebuie sa aiba cel putin o definitie de tip पब्लिक.

Tip
Tipul = type reprezinta o definitie de clasa, interfata, enum, etc (prin type se intelege un tip de data referinta – variabile de tip referinta pointeaza in runtime spre o zona din memoria HEAP)
Un type este alcatuit din membri care pot fi
o metoda – logica/functionalitate
o field - stare
Un tip este incarcat de class loader in runtime.