luni, august 29, 2005

AJAX in ACTION

Manning publica o carte despre AJAX -> Ajax in Action. O sectiune dintr-un capitol este disponibila pentru review . Aici se vorbeste despre patternul MVC aplicat la diferite niveluri ale aplicatiei, la nivelul controalelor, a paginii Web, si a aplicatiei integrata cu tot cu partea de server.
O perspectiva placuta asupra aplicatiilor in gereral, cu accente asupra dezvoltarii partii de client cu JavaScript.

Am folosit intens Swing impreuna cu sistemul de componente. Acolo, la nivelul componentelor era implementat un MVC simplificat model-delegate unde UI-delegate incorpora controllerul si view-ul componentei. Deci MVC-ul era format din UI-delegare care venea cu look-and-feel-ul si cu sistemul de evenimente, si separat era modelul.

Mai apoi am folosit intens MVC2 in aplicatii Web. De fapt aici am inteles cu adevarat MVC. Contolerul era un servlet care avea rolul sa modifice vizualizarea (in general) prin redirectare. Vizualizarea era alcatuita din JSP-uri care in general afisau colectii de bean-uri fara a avea cunostinta despre ce afiseaza (view-ul nu constientizeaza modelul). Modelul era format din Java bean-uri (sau colectii) cu rol de transport - pattern-ul Value Objects. Partea inteligenta era controllerul.

In JavaScript (ignorand partea de server) lucrurile nu pot sta altfel.

In week-end-ul acesta am studiat urmatoarele:

- prototype - un framework JavaScript
- http://script.aculo.us - colectie de clase JS cu rol in dinamica aplicatiilor pe client
- Rico - idem
- Behaviour - idem

De remarcat MODIv2 -> The Mouseover DOM Inspector, o modalitate de a urmari nodurile arborelui DOM asociat paginii (in FireFox exista un astfel de mecanism implementat in browser) .

De asemenea JSDocs pentru generarea documentatie in stil javadoc (din nefericire cu perl). Si de asemenea JSUnit echivalentul lui JUnit pentru JavaScript.

MyEclipse vine cu AutoComplete pentru JavaScript si HTML, sugerand atat pentru Netscape cat si pentru IE. Mai demult gasisem doar un plugin pentru hightlight-ing.

miercuri, august 24, 2005

Laszlo Systems.

Daca as avea timp m-as ocupa de Open Laszlo. Componete Flash gestionate cu Java Script (a se vedea ceasul din dreapta). Un exemplu de componeta refolosibila: un ceas. Programare declarativa in XML, in cel mai modern stil posibil -> mark-up language pentru descrierea interfetelor grafice in gen XAML (Longhorn) sau XUL (OS). RIA cu Flash. In spate Tomcat, deci suport nelimitat la tehnlogiile Java de middleware. Suport de la IBM in Eclipse pentru partea de tool-uri - LaszloFaces.

Cum spun ei:

Laszlo Systems is the original developer of the open source platform OpenLaszlo, and provider of rich Internet applications and services that advance the Web experience. OpenLaszlo is an XML-native foundation for building next generation Web applications that increase customer retention, conversion and brand loyalty. Laszlo provides comprehensive support services, education, and commercial application modules so that any company can easily make the move to rich Internet applications.

Pacat ca nu am timp (sau bani?) !!!

marți, august 23, 2005

A LIST APART

A list apart este un site de referinta pentru cei care sunt interesati de CSS, DHTML, design Web, etc. Tot felul de artificii ce tin de spatiul Web se gasesc in articole publicate pe acest site. E un loc de unde se poate porni. Il urmaresc de mai demult. acum si-a schimbat si designul. Spor!!!
Carti

Cartile la care am colaborat pot fi acum cumparate de pe net:

Dezvoltarea aplicatiilor Web folosind Java (reeditata Polirom 2004)
Java de la 0 la expert (Polirom 2005)

Referinta de pe situl Polirom nu mai este total corecta. Adevarul e ca am ramas la fel de atasat de Java chiar daca lucrez acum la alta firma si mi-am terminat si masterul.

Cristian Olaru este absolvent al Facultatii de Informatica din cadrul Universitatii „Al. I. Cuza” din Iasi. In prezent este masterand al aceleiasi facultati. Lucreaza ca programator Java in cadrul firmei SetMobile, specializata in dezvoltarea de aplicatii pentru dispozitive mobile folosind tehnologii Java. Este interesat de framework-uri Web si tehnologii enterprise folosind limbajul Java si solutii open source. La Editura Polirom a mai publicat, in colaborare, Java de la 0 la expert (2003).
Portlets si portaluri


Cand eram extrem de interesat de portlets, adica acum cativa ani, am fost foarte impresionat de Plumtree Software, o firma care ocupa la vremea aceea aproape toata piata de portal. Microsoft era nimic, atunici, ca si IBM, cu partal serverele lor.

In lumea Java a aparut JSR 198, care specifica clar ce reprezinta un portlet. Multe din impelmetarile existente au devenit compatibile cu aceasta specificatie.

Java ca open source a evoluat greu in ceea ce priveste tehnologiile de portal. Pluto, JetSpeed, Liferay, Exo. Cred ca inca nu e timpul. Am auzit de implementari de la IBM si JBoss. In rest cunoscutele referinte: MyMSN si MyYahoo - link-urile le gasiti singuri.

Azi o stire: BEA and Plumtree Software today announced that BEA will acquire Plumtree for approximately USD$200 million in cash.
Am descoperit blog-ul lui Graig McClanahan care a facut mult bine in lumea Java, pe partea de server (Struts si JSF printre altele) . L-am postat la link-uri http://blogs.sun.com/roller/page/craigmcc/ .

Ted Neward si-a schimbat blogul. Nu il mai gazduieste in propriul site. A ales o solute bazata pe .Net, un motor facut de altii. Nu l-am actualizat. Spor!!!

Actualizare via email!


Dupa o incercare reusita din Word, sper sa urmeze si una de pe mail. Adica aceasta. Blogger permite intrari via mail. (sper sa mearga).

--
This message was sent using ZAPP Mobile Mail(tm) System

duminică, august 21, 2005

Un mic test din add-in-ul pentru Word

Aceasta intrare in blog este postata din Word folosind add-in-ul pentru Word de pe blogger.com. Foarte interesant. Un exemplu de link : olaru.blogspot.com . Diacriticele: ăîşţâ. Oare cum se vad. Spor.

sâmbătă, august 20, 2005

Din blog-ul lui Martin Fowler despre framework-uri.
  http://www.martinfowler.com/bliki/

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework. This phenomenon is Inversion of Control (also known as the Hollywood Principle - "Don't call us, we'll call you").

One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.

--Ralph Johnson and Brian Foote

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

vineri, august 12, 2005


Eu la 26 de ani (aproape). Intr-o clatorie in tinuturile Moldovei. Imagine postata cu Helloo! Posted by Picasa

Foarte adavarat: o continuare a intrarii precedente din blog

Am gasit aceasta intrare in blog-ul lui Ralph Johnson (Gang of Four). Este o referinta spre Grady Booch (Three Amigos). Parerea mea e ca tot ce spune Ralph despre arhitecturi software, aproape ca poate fi considerar citat. E intr-un fel un mentor in ingineria software cu o mare aplecare asupa pattern-urilor si cu accent spre framework-uri: http://www.cincomsmalltalk.com/userblogs/ralph/blogView

Grady Booch is starting a project to build the Software Architecture Handbook There isn't much there now, but you can see what he is planning, and it is ambitious! He has over a hundred systems on his list. He plans to describe the architecture of each, and then to describe the patterns in them. This is way bigger than any one person can do, and will have a major impact on all software development if he can pull it off.

Un ciatat gasit intro referinta din blogul lui Ralph Jojnson spre un sit al lui Grady Booch. Incredibil de frumos spus: http://www.booch.com/architecture/index.jsp

Software development has been, is, and will likely remain fundamentally hard. To that end, the entire history of software engineering is one of rising levels of abstaction (for abstraction is the primary way we as humans deal with complexity), and we see this reflected in the maturation of our programming languages, platforms, processes, tools, and patterns. Indeed, every well-structured software-intensive system is full of patterns, ranging from idioms that shape the use of a particular programming language to mechanisms that define the collaboration among societies of objects, components, and other parts. At the highest level of abstraction, every system has an architecture, encompassing the key abstractions and mechanisms that define that system's structure and behavior as seen from the perspective of different stakeholders, each with a different set of concerns. In every case - from idioms to mechanisms to architectures - these patterns are either intentional or accidental, but insofar as they are visible, such patterns reflect the style and inner beauty of each system.

It is a sign of maturity for any given engineering discipline when we can name, study, and apply the patterns relevant to that domain. In civil engineering, one can study the fundamental elements of architecture in works that expose and compare common architectural styles. Similarly, in chemical engineering, mechanical engineering, electrical engineering, and now even genomic engineering, there exist libraries of common patterns that have proven themselves useful in practice.

Un alt nivel de abstractizare

Problema abstractizarii ma preocupa in mod deosebit. Imi dau seama ca mintea umana este facuta sa lucreze asa. Ignoram amanuntele si ne jucam numai cu un set de aspecte. Altfel nu am face fata complexitatii. Cine incerca sa stapaneasca tot cu siguranta va pierde si ceea ce are.

In POO, atunci cand un API se vrea a fi facut accesibil si de ceilalti membri ai aplicatiei, acesta se publica (Martin Fowler vorbeste intr-un articol al lui despre public versus publicat). In acest sens un principiu bun de programare sugera ca metodele care vor putea fi accesate de ceilalti sa fie numite publice, iar cele care au rol doar local cu posibilitati mari de modificare sa fie facute private. In ultimul timp a aparut ideea programarii pe interfete (folosit pe larg in framework-ul Spring). Acest lucru face ca fiecarei clase definite sa i se specifice si interfata care contine declaratia metodelor ce se vor a fi executate din exterior. Interfata devine astfel un contract in fata clasei care o implementeaza. Acest lucru, semnifica faptul ca metodele lui pot fi folosite de ceilalti, cu garantia ca semnatura lor nu se va schimba deci cu posibilitatea minima de a aparea incompatibilitati in timp.

In lumea calculatoarelor se intampla aproape la fel. Programam in API-uri care reprezinta colectii de clase deja definite. Nu lucram cu mnemonicile microprocesorului. De mult nu se mai lucreaza asa. Calculatorul a ajuns sa fie infasurat in asa masura in API-uri software incat apoape ca putem sa-i ignoram existenta (si un pocket este la fel de bine invelit). Putem considera ca ceea ce e dincolo de nivelul cu care interactionam nici nu exista. O dovada este faptul ca putem trimite e-mai-uri dintr-o aplicatie Web fara sa cunoastem protocoale de retea sau altceva. Practic, apelam o metoda a unei clase.

Prin contructia sa limbajul Java cu precadere foloseste principiul de abstractizare. Astfel, se lucreaza initial cu o masina virtuala neoptimizata fara a se tine cont ca peste un timp ea este facuta mai performanta. Acest lucru pentru ca interactiunea cu masina virtuala se faca independent de structura ei interna. Optimizarea ei este o problema a specialistilor. Folosirea ei este o problema a dezvoltatorilor.

Ce am facut - ce as vrea sa fac???

Folosind Struts am inteles foarte bine cum comunica browserul cu serverul si aspecte de nivel jos referitoare la aplicatitiile Web (validare, internationalizare, agregare de tile-uri, paradigma cerere-raspuns, stratificarea aplicatiilor). Sincer nu am facut niciodata o aplicatie completa bazata numai pe servleturi si JSP-uri si aproape ca nu imi pare rau. As fi ramas la un nivel prea primitiv de abstactizare (ar fi fost comic sa fac aplicatii care fac interogari SQL din servleturi). Folosind framework-uri m-am ridicat deodata la un nivel mult mai inalt de abstractizare care implica in mod automat si o arhitectura pentru aplcicatii. Nu cat ar trebui.

In procesul de dezvoltare al aplicatiilor WEb, cele mai mari probleme le-am avut la nivelului de prezentare. Tot ce tine de domeniul problemei si de baza de date au fost lucruri usoare. Majoritatea timpului am pierdut-o in juurul fluxului de control pe partea de client (chiar daca in principiu e vorba de JSP-uri din care se genereaza HTML pe partea de server). De aceea un pas pozitiv ar fi gasirea unor plug-in-uri Eclipse pentru partea de prezentare. Am sa incerc MyEclipse in acest sens (se poate testa o luna). Sau o sa trec mai departe la un framework bazat pe componente care sa permita RAD.

Librariile de taguri mi-au oferit cea mai mare putere de reutilizare. Tag-uri pentru vizualizarea tabelelor, meniuri, librariile de taguri standard, Struts, pentru chart-uri si altele, facute de altii si adaptate mi s-au parut cel mai bun lucru posibil. De aceea tind sa cred ca un model bazat pe componete reutilizabile are un viitor sigur; in acest sens a se vesea Tapestry si JSF. Deseori am facut refactoring in JSP-uri pentru a folosi tag-uri in loc de cod Java embeded. Un sistem de componente se potriveste de minune cu ideea unui nivel de abstractizare mai ridicat.


Suportul pe care comunitatile Open Source il ofera dezvoltatorilor este de asemenea ceva nemaintalnit. Sunt profund impresionat si cred in open source. Prin multitudinea de pasionati, cred ca in momentul acesta se depaseste suportul pe care poate o firma sa-l ofere pentru un produs pe care il vand. Suportul consta in forum-uri cu diverse teme, bug-tracking, liste de discutii, arhive ale listelor de discutii, documentatii, demo-uri, sand-box-uri, blog-uri, etc. Si sunt foarte, foarte multi oameni de calitate in opens ource, care impartasesc fara nici o restrictie ideile.

Ce m-ar interesa ar fi folosirea in productie a unor tehnologii de viitor. AJAX pare o alternativa convenabila pentru aplicatiile Web de intranet. AOP o solutie buna pentru tot felul de artificii peste POO. Framework-uri diverse adaptate unor nevoi concrete, iarasi par a fi un subiect de discutie. Test driven developement, pentru a accelera procesul de dezvoltare - ma chinui de un an sa bag acest principiu bun in viata mea. Ce m-ar interesa ar fi sa merg mai departe in problemele de arhitectura si design pattern, pentru a-mi solidifica cunostintele. Impresia mea este ca, tinand cont de experienta acumulata, intr-un momemt de liniste pot sa imi solidific cunostintele si sa le structurez mai bine. A exprima pe un blog, a le explica altora sau a scrie o carte reprezinta tot atatea metode de a merge mai departe.

Ce ma supara si am mira la oamenii din domeni: ignoranta (care vine din mandrie). Nu o sa stau mult pe langa astfel de oameni. Altceva ar fi neprofesionalismul si lipsa de rigurozitate tipic romaneasca. In rest numai de bine...

miercuri, august 10, 2005

Luna de miere in Grecia!


Meteora
Originally uploaded by Cristia Olaru.

La Meteora in Grecia in luna de miere. Inca o reusita in a apela serviciile web ale Blogger. Deci e o actualizare din Flickr via sercicii web. Foarte interesant. Vreau si eu.

Foto-stream Flickr: Grecia

O luna de la casatorie!

10 iulie 2005! Ce frumos!!! A trect o luna de la nunta.

Foto stream-uri:

Casatoria civila

Nunta

Grecia

AJAX --> Asynchronous JavaScript + XML

Nu pot sa descriu in cuvinte repulsia pe care o simt relativ la JavaScript (mai bine spus JScript). Este o adunatura de comenzi, puse claie peste gramada, fara nicio ordine clara. Daca te uiti pe o carte de JavaScript ai impresia ca e un dictionar de comenzi. Parca cei ce l-au conceput sau mai ales dezvoltat (nu au avut oricum o ideie pre buna) au adunat de-a lungul timpului tot ce e mai urat in acest pseudo limbaj. Am aaut probleme cu vizibilitatea variabilelor, imposibilitatea de a depana. Da, da, depanarea e un adevarat chin. Sincer, numai cunoscutul alert. Am impresia ca in Modzila e un depanator, sau cei de la Microsoft au asa ceva. Prea costisitor. Eu fac doar Java.

Este foarte clar ca este nevoie de dinamica pe partea de client. Spun asta ca om care a lucrat la aplicatii web de intranet. Ar fi un nonsens sa nu folosesti avantajele unui scripting pe client in astfel de aplicatii.

In firma unde lucrez am stabilit o regula. Aceea de a nu tine starea aplicatiei pe partea de client ci o o lasa a fi gestionata de server. Astfel purtam datele spre server ca prametri via request. Regula suna asa: ceea ce se vede in interfata este si in baza de date. Altfel lucrurile degenerau in haos, prin incercarea de a tine starea aplicatiei pe client folosind JavaScript. Lucrurile deveneau intotdeauna prea complicate. Java Script se foloseste pentru a arunca ferestre de diaolog, a ascunde elemente, etc... Mici tertipuri... Dar, este vorba dupa cum am spus de aplicatii de intranet.

In cazul aplicatiilor Web (pure - situri Web sa le spunem asa) lucrurile sunt clare. Java script la minimum. Incompatibilitatile browsereleor sunt binestiute.

Totusi am remarcat doua tehnologii care folosesc Java Script si care sunt revolutionare in felul lor. Una ar fi Laszlo Systems, un sistem de componente pentru construirea de aplicatii bogate. Si AJAX, folosit la urma urmei in acelasi scop.

Despre AJAX mai multe in continuare...

Am ramas surprins. Posibilitatea de a face refresh pe o singura zona a paginii este un mare avantaj. E ca si cum s-ar actualiza doar un tile si nu toata pagina. Avantajul se pare ca este adus de specularea unui mic amanunt (a se vedea asemanarea cu AOP care arela baza simpla incterceptie a apelului de metoda). Totul sta in obiectul XMLHttpRequest din Java Script introdus pentru prima oara de Microsoft. Acesta permite actualizarea unei componete din arborele DOM care descrie pagina curenta in mod asincron. AJAX reprezinta un mod abstract de a privi aceasta problema.

Doua exemple de folosire a cestei tehnologii: google sugest si google maps.

In Java exista o implementare care se numeste SWF (Simple Web Framework). Semana cu Struts ca arhitectura, dar este bazata pe XMLHttpRequest. Sunt acolo cateva exemple tulburatoare. Nu cred ca se pot realiza altfel. Fara refresh numai pe un element al paginii nu se pot face astfel de lucruri miraculoase. Ei sustin ca e o alternativa al JSF. Nu cred ca e asa. E mai mult o ncercare de a face lucruri frumoase folosind tot tehnologiile ante-JSF cuma r fi ligrarii de taguri. Intr-un fel se ramane tot la nivel de request-response, http. Nu e vorba de un nivel mai ridicat de abstractizare cum ar fi componente si evenimente. Deci nu se poate pune intradevar problema RAD.

Mai multe altadata. Am de gand sa ma aplec asupra problemei. Pare foarte palpitant - am studiat documentatia standard. Cred ca o sa scimbe fata web-ului. Apropos. Google Mail e realizat cu aceasta tehnologie. Priviti atent. Se actualizeaza numai cate o zona si nu intreaga pagina (jos puteti comuta spre HML standard). Mare lucru...

luni, august 08, 2005

Cu greu m-am decis sa aleg Blogger.com.

In timp am inceput mai multe blog-uri dar din nefericire nici o solutie nu s-a dovedit a fi viabila. Mereu probleme de hosting si instabilitate. Am desis sa incerc pe Jroller, mai ales ca aproape toate intrarile mele erau referitoare la Java. Dar schimband schinurile am ajuns la o inconsistenta in design. Si am renuntat... Cel putin deocamdata. Ar fi fost frumos sa fiu alaturi de The BileBlog si Romain Guy's Weblog... dar nu se poate. Mai bine singur pe Blogger.

Am instalat si hostat Blogsom mai demult si JRoller. E o implementare in Java sub Tomcat, foarte placuta si stabila. Am observat si pe net unii care o folosesc. Din nefericire hosting-ul pentru java este extrem de scump si inca nepopular. Ar fi interesant sa-ti tii si propriul blog.

Ce am observat, este suportul pe care il ofera Google. De fapt Blogger este serviciu Google. A se vedea: serviciile google. Mai e si Picasa cu Hello. Nu am incercat inca, dar daca s-ar putea face transfer direct din Picasa pe Blogger ar fi deosebit. Cred ca se poate din Flickr. Am vazut ceva intamplator. Deci am ales Blogger pentru integrabilitate. Si pentru designul placut. Daca intrati pe pagina cu servicii google ar fi placut sa incercati Google Earth . E nemaipomenit.

Cred ca am sa incers sa mentin o referinta pe Jroller.com. Poate am sa reusesc publicari simultane pe doua blog-uri. Am sa incerc. Spor in toate!