Saturday, June 27, 2015

You'll always miss 100% of the shots you don't take

The first time I read Wayne Gretzky's famous quote I was a teenager who was trying to understand which direction he should take in life. Although I had a rough idea about what's expected of me: get an education, get a job, start a family and so on; over the years I discovered that life has much more in store than I initially thought. There are so many things to do, there are so many things to be passionate about. It would be a shame to limit ourselves and never try something new, never try to improve our character, our skills and eventually our way of living.

Meanwhile I discovered that my passion is software engineering and many things have changed over the past ten years or so. Whether I'm thinking about the college years or the seven years I've been working as a full time employee for various companies, there were times of struggle, times of celebration but most important the satisfaction of accomplishing something meaningful after a hard day's work.

During my last year in college I discovered the power and diversity of the Java platform and I was amazed at how many things one can do with it. Soon I decided that I want to invest time and energy into learning as much as I can about it and right after finishing my studies I got my first job as a Java developer. I've been working with Java technologies ever since. I won't spend more time talking about this particular topic because I'm more interested in sharing my thoughts about what it means to me to be a software engineer.

Working as a software engineer challenges me constantly. It helps me evolve both professionally and personally because software engineering is not sitting in front of a computer and hacking some code. It's interacting with people - actually many times mastering the art of dealing with people is more important for the success of a project than the ability to write code -, taking the right decisions, being rigorous and organized, committed and responsible. And perhaps one of the most important things: being curious and hungry for knowledge, constantly learning. In my country there's a saying about doctors, and everybody agrees that they have to learn new stuff their whole lives. Few people that are not working in IT see though that if you're a software engineer and you want to stay in business you can never leave out the learning part.

Also, working in this domain helped me see more clearly different aspects of life. The explosion of the technology related things everybody uses every day made me realize that somehow we are shaping the present and also the future of our civilization. That leads me to another conclusion: we have a lot of power therefore we have greater responsibility. People that are part of the IT culture - because software and hardware engineering it's not just a job, it has become a culture - are the ones that come with new ideas, innovate and make that future possible.

Being part of a large company has its benefits. For instance, you're exposed to a lot of information both from a technical and business perspective. Also it was essential for me at the beginning of my career that I received guidance from the more experienced colleagues. Another important aspect is the stability a company usually offers. Even when things are not that great most of the time they find a solution. However, companies are profit oriented, and it's normal to be so. Therefore there are many constraints that have to be met and many times those constraints hurt freedom; the freedom to choose the project you're working on, the freedom to choose the technologies you're using and eventually, the freedom to express your most innovative ideas and bring them to life. Of course that's not a rule, but I've seen it happening many times.

At some point during the past few years I began to feel more and more the need to be able to choose what I'm working on. Then I began to understand how important it is to be passionate not only about the technologies you're applying but also about the reality you're trying to model through the product you're developing.

It seems that another important ingredient that contributes to a success story is the context which you find yourself in, and I'm thinking here about timing and location. Developing software is a creative process and artists need to be able to choose the time and place of working so they can deliver their masterpiece. Of course we can't take that to extreme, because usually the success of a project also relies on that dreaded word, "deadline". What I'm trying to say is that it's nice from time to time to be able to wake up in the middle of the night and implement some genius idea that solves the problem you just couldn't find a solution to during the day. It's also nice to be able to escape the crowded city and charge your batteries in a quiet place without needing to call it a vacation.

Such things are possible through Toptal's way of doing business. I've recently learned from a friend a few things about the Toptal team and it seems that it's a great community to be part of. I'll soon have a discussion with a representative and I'm excited about that! I'm looking forward to knowing them better and eventually be able to confirm myself that these things are true and more!

Wednesday, June 24, 2015

Aplicații IoT cu Java ME Embedded 8

(Publicat în revista Today Software Magazine, Numărul 36, Iunie 2015: http://issuu.com/todaysoftmag/docs/tsm_36_2015_ro)

În numărul 31 al revistei am făcut o introducere în ceea ce privește subiectul Internet of Things din perspectiva platformei Java. Așa cum am promis, vom continua această discuție prezentând detaliile creării unui proiect Java ME Embedded 8. Această versiune reprezintă un important pas înainte, odată cu adoptarea CLDC 8 - care este un sub-set al Java Standard Edition - și MEEP 8 - specificație care definește un mediu puternic și flexibil pentru sisteme embedded de dimensiuni reduse. Alături de acestea, trebuie să remarcăm alinierea platformei despre care discutăm la Java SE 8.

Tooling pentru aplicaţii ME - Oracle Java ME SDK 8.1

Aplicațiile Micro Edition pot fi dezvoltate atât manual, cât și cu ajutorul unui SDK dedicat, cunoscut sub numele Oracle Java ME SDK 8.1. SDK-ul, distribuţia Java ME, documentaţia şi orice alte resurse mai sunt necesare dezvoltării aplicaţiilor embedded, se găsesc la adresa Oracle dedicată platformei.

Înainte de a începe să dezvoltăm aplicaţii embedded, Oracle recomandă, în primul rând, instalarea Oracle Java ME SDK 8.1 - pachet software care la momentul scrierii acestui articol este disponibil doar pentru sistemul de operare Windows. Următorul pas este descărcarea distribuţiei Java ME Embedded 8 destinată dispozitivului pe care dorim să rulăm aplicaţiile. Aceasta vine sub forma unei arhive ZIP şi trebuie transferată pe dispozitiv - cu ajutorul unui tool cum este PuTTY -, unde urmează să fie instalată. De asemenea, se recomandă păstrarea unei cópii pe sistemul desktop, unde se va executa dezvoltarea aplicaţiilor. Acest ultim pas nu este obligatoriu, însă este recomandat pentru cazul în care dezvoltatorul doreşte să execute comenzi pe dispozitiv cu ajutorul AMS CLI (Application Management System Command Line), prin intermediul programului Developer Agent.

Prima noastră aplicaţie Java ME

Odată ce am instalat SDK-ul şi Java ME, putem să începem dezvoltarea unei aplicaţii embedded. Sub forma ei cea mai simplă, o astfel de aplicaţie trebuie să conţină o clasă care extinde clasa abstractă javax.microedition.midlet.MIDlet, un fişier manifest şi un fişier JAD (Java Application Descriptor). Am putea scrie o astfel de aplicaţie manual, fără ajutorul unui IDE, care să automatizeze anumiţi paşi. Acesta este un bun exerciţiu pentru dezvoltatorul care intră pentru prima dată în contact cu Java ME Embedded 8. Astfel, ne propunem să creăm o simplă aplicaţie, care afişează în consolă un mesaj la pornirea aplicaţiei şi unul la oprirea acesteia.

În primul rând, creăm o clasă care extinde javax.microedition.midlet.MIDlet, implementând metodele startApp() şi destroyApp(boolean unconditional):

public class Hello extends javax.microedition.midlet.MIDlet {
    public void startApp() {
        System.out.println("Hello MIDlet");
    }
    public void destroyApp(boolean unconditional) {
        System.out.println("Goodbye MIDlet");
    }
}

Pentru a continua în aceeaşi manieră, compilăm manual clasa pe care tocmai am scris-o, cu o comandă similară celei listată aici:

javac -cp %JAVA_ME_SDK%\lib\meep_8.0.jar -d classes src\ro\leje\Hello.java

Observăm că avem nevoie de biblioteca meep_8.0.jar la compilare, întrucât aceasta defineşte clasa abstractă MIDlet. Această bibliotecă se găseşte în directorul %JAVA_ME_SDK%\lib, unde %JAVA_ME_SDK% reprezintă calea unde a fost instalat SDK-ul.

Următorul pas îl reprezintă crearea fişierului manifest, care trebuie să conţină cel puţin următoarele informaţii:

MIDlet-Name: Hello
MIDlet-Version: 1.0
MIDlet-Vendor: Today Software Magazine
MIDlet-1: Hello,,ro.leje.Hello
MicroEdition-Configuration: CLDC-1.8
MicroEdition-Profile: MEEP-8.0

Presupunând că am salvat fişierul manifest cu numele MANIFEST.MF, putem trece la următorul pas, care este crearea arhivei JAR. Această arhivă trebuie să conţină clasa compilată şi fişierul manifest. Realizăm aceasta lansând în execuţie următoarea comandă:

jar cfm build\Hello.jar MANIFEST.MF -C classes .

Odată ce am creat fişierul Hello.jar, pentru această aplicaţie mai avem nevoie de un singur lucru, şi anume descriptorul aplicaţiei, cunoscut şi sub numele de fişier JAD (Java Application Descriptor). Acesta se aseamănă cu fişierul manifest, conţinând următoarele linii obligatorii:

MIDlet-Name: Hello
MIDlet-Version: 1.0
MIDlet-Vendor: Today Software Magazine
MIDlet-1: Hello,,ro.leje.Hello
MIDlet-Jar-Size: 1076
MIDlet-Jar-URL: Hello.jar
MicroEdition-Profile: MEEP-8.0

Observăm că unul dintre atributele obligatorii ale fişierului JAD este dimensiunea în bytes a arhivei. Salvăm acest fişier cu numele Hello.jad în acelaşi director cu arhiva JAR.

Rularea aplicaţiei cu un emulator

În acest moment avem o aplicaţie Java ME Embedded 8 completă, pe care o putem lansa în execuţie. Cea mai simplă modalitate pentru a face acest lucru este folosirea emulator-ului pe care ni-l pune la dispoziţie SDK-ul. Presupunând că am adăugat în PATH calea %JAVA_ME_SDK%\bin şi că directorul curent este directorul build al proiectului nostru, putem lansa următoarea comandă:

emulator -Xdevice:EmbeddedDevice1 -Xdescriptor:Hello.jad

Cu ajutorul opţiunii -Xdevice specificăm numele dispozitivului pe care dorim să rulăm aplicaţia. EmbeddedDevice1 este un dispozitiv emulat, configurat automat în momentul în care instalăm SDK-ul. Cea de-a doua opţiune prezentă în comanda pe care am executat-o este -Xdescriptor, prin intermediul căreia specificăm locaţia şi numele descriptorului aplicaţiei noastre.

Putem observa rezultatul rulării aplicaţiei în următoarea figură:

Aplicaţia Hello în emulator

Mesajul Hello MIDlet este afişat la pornirea MIDlet-ului, iar mesajul Goodbye MIDlet la oprirea acestuia, cu ajutorul combinaţiei de taste Ctrl + C.

Rularea aplicaţiei pe dispozitiv

O altă modalitate de a rula aplicaţia este prin instalarea acesteia pe dispozitivul ţintă. Pentru acest articol am folosit o plăcuţă de dezvoltare Raspberry PI Model B+, dotată cu un dongle Wi-Fi. De asemenea, menţionăm faptul că platforma are deja instalat un sistem de operare Linux, ceea ce facilitează munca noastră cu acest hardware. Având această configuraţie la îndemână putem accesa de la distanţă sistemul Raspberry PI, cu ajutorul unui program precum PuTTY.

Accesăm plăcuţa cunoscându-i IP-ul şi un user cu drepturi de root. Odată ce ne-am autentificat, schimbăm directorul curent, pentru a ne situa în directorul bin al distribuţiei Java ME Embedded 8 instalată. Acest lucru este ilustrat în următoarea captură de ecran:

Accesarea plăcuţei de dezvoltare cu PuTTY

Figura ne arată faptul că următorul pas a fost rularea script-ului usertest.sh cu ajutorul comenzii sudo ./usertest.sh. Acest script a lansat în execuţie Java runtime, care permite accesul la AMS. Platforma ascultă pe portul 2201 şi ne permite să ne conectăm de la distanţă pentru a face managementul aplicaţiilor ME.

Înainte de a putea continua, trebuie să înregistrăm dispozitivul cu ajutorul aplicaţiei Device Connections Manager. De vreme ce avem instalat SDK-ul, ar trebui să găsim în SysTray o iconiţă intitulată Oracle Java(TM) ME SDK 8.1 Device Manager. Făcând click pe aceasta, deschidem managerul de conexiuni, unde putem adăuga plăcuţa noastră, pe care o identificăm după IP. Odată ce am înregistrat dispozitivul, ar trebui să avem în fereastra activă ceva similar figurii următoare:

Înregistrarea unui dispozitiv

Acum putem instala pe Raspberry PI aplicaţia pe care am creat-o intr-o secţiune anterioară. Avem la dispoziţie câteva modalităţi pentru a face aceasta, una dintre ele fiind cu ajutorul utilitarului Device Selector, care este la dispoziţia noastră, bineînţeles, datorită faptului că am instalat SDK-ul. Deschizând această aplicaţie, observăm o listă cu toate dispozitivele instalate la momentul curent. Predefinit, avem la dispoziţie trei dispozitive emulate: EmbeddedDevice1, EmbeddedDevice2 şi QualcommIoEDevice. Alături de acestea, putem vedea plăcuţa Raspberry PI, pe care tocmai am înregistrat-o, cu numele EmbeddedExternalDevice1. Dorim să rulăm aplicaţia Hello pe acest dispozitiv, aşa că facem click-dreapta şi alegem Run JAR or JAD..., după cum este ilustrat şi în figura următoare:

Rularea aplicaţiei pe dispozitiv

Alegând de pe disk fişierul Hello.jad cu ajutorul ferestrei de tip Open care a apărut, platforma lansează în execuţie managerul de aplicaţii, care instalează pachetul nostru software pe plăcuţă, lucru pe care îl putem vedea în următoarea captură de ecran:

Managerul de aplicaţii

Faptul că aplicaţia noastră Java ME Embedded 8 rulează într-adevăr pe dispozitiv ni-l demonstrează consola PuTTY, unde putem vedea output-ul pornirii şi opririi aplicaţiei:

Output-ul aplicaţiei în consolă

Observăm faptul că în captura de ecran anterioară este listat şi mesajul care trebuie afişat la distrugerea aplicaţiei. Aceasta pentru că înainte de a face captura am apăsat butonul Remove, prezent în interfaţa aplicaţiei de management.

Aşadar, oricare ar fi modalitatea aleasă pentru a rula aplicaţii Java ME Embedded 8 fie pe dispozitive, fie într-un emulator, acesta este un proces relativ facil. Mai există o cale de a rula aplicaţii embedded pe dispozitive, cu ajutorul liniei de comandă AMS, prin intermediul utilitarului Developer Agent, însă această metodă este în fază de concept în această versiune a platformei.

Pe parcursul acestui articol am urmărit paşii creării, instalării şi rulării unei aplicaţii minimale, efectuând manual fiecare sarcină. Totuşi, platforma ne pune la dispoziţie o serie de unelte care vin în întâmpinarea nevoilor dezvoltatorilor şi ţintesc sporirea productivităţii acestora. Într-un articol viitor ne propunem să prezentăm procesul dintr-o altă perspectivă, automatizat cu ajutorul acestor unelte.

Concluzii

Dezvoltarea aplicaţiilor Java ME Embedded 8 poate fi un proces interesant şi distractiv, dar uneori dificil şi frustrant. Din păcate, materialele de studiu dedicate Java ME Embedded 8 sunt puţine. Până în momentul de faţă există o singură carte publicată care abordează subiectul dezvoltării aplicaţiilor Java ME Embedded 8. De asemenea, majoritatea articolelor existente pe această temă au o abordare generală, prezentând în linii mari trăsăturile acestei noi platforme. Deocamdată, thread-urile dedicate pe forumuri sunt relativ puţine, însă putem observa interesul din ce în ce mai mare al utilizatorilor, dornici să înveţe cum să folosească noua versiune. Cele mai consistente resurse pe care le avem la dispoziţie sunt ghidurile oficiale compilate de către Oracle, care pot fi descărcate de pe site-ul oficial al platformei.

Tuesday, January 20, 2015

Procesoare de șabloane pentru dezvoltare web în Java

(Publicat în revista Today Software Magazine, Numărul 23, Mai 2014: http://www.todaysoftmag.ro/article/882/procesoare-de-sabloane-pentru-dezvoltare-web-in-java)

Îmulte dintre proiectele informatice întâlnite avem de-a face cu situaţii în care trebuie să procesăm text, să generăm rapoarte, scripturi sau cod sursă. Adeseori, aceste probleme pot fi rezolvate cu ajutorul unor unelte numite procesoare de șabloane. Totuși, cel mai des întâlnit scenariu pentru utilizarea procesoarelor de şabloane este acela al dezvoltării de aplicaţii web, unde s-a observat nevoia separării logicii aplicaţiei de prezentare.
În cazul aplicaţiilor web dezvoltate cu tehnologii Java, standardul pentru partea de prezentare a fost mult timp JavaServer Pages, care are trăsăturile unui procesor de șabloane. Marele neajuns al acestei tehnologii este posibilitatea inserării debusiness logic în codul de prezentare. Astfel, avem posibilitatea să inserăm în documentul JSP scriptlets sau chiar blocuri de cod Java. Deși acest lucru ne poate ajuta în anumite situații, codul devine în mod rapid mai complex și greu de întreținut. Mai mult decât atât, această practică încalcă principiul design pattern-ului MVC.
Din cauza neajunsurilor de acest gen, JSP a pierdut teren semnificativ în favoarea altor procesoare de şabloane, care sunt folosite în tot mai multe proiecte, sporind productivitatea dezvoltatorilor şi calitatea produselor. Proiectele despre care vom discuta ne ajută să creăm cu ușurință conținut dinamic, combinând șabloanele cu modelul de date, pentru a produce documente rezultat. Șabloanele sunt scrise într-un limbaj de templating, iar documentele rezultate pot reprezenta orice fel de text formatat.
Pe lângă procesoarele deja consacrate, cum ar fi Apache Velocity sau FreeMarker, în ultimii ani a fost lansată o varietate de noi produse de acest gen, care oferă funcţionalităţi diverse. În continuarea acestui articol vom analiza patru produse disponibile gratuit pentru uz comercial, încercând să realizăm o comparaţie a acestora.

Spring MVC şi procesoarele de şabloane

Când ne gândim la dezvoltarea unei aplicaţii web cu ajutorul tehnologiilor Java, unul dintre primele lucruri pe care le facem este să alegem un framework MVC. Practica ne-a arătat că Spring MVC este unul dintre cele mai populare framework-uri web, iar în acest articol vom analiza utilizarea procesoarelor de şabloane din perspectiva integrării cu acesta. Pentru a ilustra anumite trăsături ale fiecărui procesor prezentat, vom dezvolta o aplicaţie web simplă, ce va fi compusă din două pagini: una care afișează o listă de produse și alta care afișează detaliile unui produs.

Apache Velocity

Velocity (http://velocity.apache.org/) este un proiect distribuit sub licenţă Apache Software License, care se bucură de o mare popularitate printre dezvoltatorii de aplicaţii Java. Deşi este utilizat de cele mai multe ori în context web, nu suntem limitaţi să folosim produsul doar pentru acest tip de proiecte. Poate fi utilizat fie ca un utilitar de sine stătător pentru generare de cod sursă şi rapoarte, fie ca o componentă integrată în alte sisteme.
Asemeni altor procesoare de şabloane, Velocity a fost proiectat astfel încât designerii web să poată lucra în paralel cu programatorii Java. Astfel, Velocity ne ajută să despărțim codul Java de codul paginilor web, oferind o alternativă viabilă tehnologiei JSP.

Velocity Template Language

Apache Velocity se bucură de un limbaj de scripting propriu, numit Velocity Template Language (VTL), care este puternic şi flexibil. Autorii Velocity anunţă cu mândrie că flexibilitatea produsului lor este limitată doar de creativitatea utilizatorului. VTL a fost creat cu scopul de a oferi cea mai simplă şi curată cale pentru a încorpora conţinut dinamic într-o pagină web.
Velocity foloseşte referinţe pentru a îngloba conţinut dinamic în paginile web, iar unul dintre tipurile de referinţe este reprezentat de către variabile. Acestea pot referi obiecte definite în codul Java sau pot primi valori chiar în interiorul paginiiweb, prin intermediul unei declaraţii VTL. O astfel de instrucţiune începe cu un caracter #, după cum putem observa în exemplul următor:

#set( $magazineUrl = "http://www.todaysoftmag.com/" )

Integrarea cu Spring MVC

Spring MVC are suport nativ pentru procesorul de șabloane despre care discutăm, și în consecință integrarea acestora este un proces simplu. Presupunând căfolosim Maven pentru crearea proiectului, alegem arhetipul maven-archetype-webapp din grupul org.apache.maven.archetypes. Fără a enumera toate dependințele Maven necesare, menționăm totuși că avem nevoie de artefactele velocity și velocity-tools din grupul org.apache.velocity. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă: https://springvelocity.googlecode.com/svn/trunk.
După ce am declarat în web.xml servlet-ul DispatcherServlet care va gestiona toaterequest-urile și am definit fișierul servlet-context.xml cu toate elementele specifice Spring, putem declara bean-urile pentru lucrul cu Velocity. În primul rând, avem nevoie de un bean cu id-ul velocityConfig, căruia îi vom transfera calea relativă la care se vor găsi șabloanele pentru paginile aplicației:



Apoi, declarăm un view resolver, care primește mai multe proprietăți. Clasa care va determina tipul acestui bean trebuie să implementeze interfața ViewResolver și are ca principal rol găsirea view-urilor după nume. Cea mai interesantă proprietate a acestui bean este layoutUrl. Aceasta reprezintă numele șablonului care va stabili layout-ul general:


De asemenea, Velocity are capacitatea de a face caching șabloanelor folosite, lucru specificat prin proprietatea cache.
Acum că am configurat aplicația astfel încât partea de vizualizare să fie reprezentată prin șabloane Velocity, putem să vedem cum arată aceste șabloane. Partea cea mai interesantă a șablonului care determină layout-ul general este prezența variabilei speciale $screen_content. Aceasta va conține la runtimerezultatul procesării șablonului corespunzător view-ului returnat de controller-ul Spring MVC. În cazul aplicației noastre există un singur controller, care poate returna fie view-ul list, fie view-ul detailsȘablonul corespunzător view-ului list este list.vm și are următorul conținut:


#foreach($product in $products)
#end


În blocul de mai sus observăm cum iterăm o colecție și cum accesăm proprietățile obiectelor din model cu ajutorul VTL.

Avantaje și dezavantaje

Fiind unul dintre cele mai cunoscute proiecte în materie de template processing, Velocity beneficiază de susținerea unei comunități bine stabilite. De asemenea, documentația de pe site-ul oficial este generoasă și există multe articole, care răspund la diverse întrebări. În plus, în decursul timpului au fost publicate câteva cărți dedicate proiectului Apache Velocity. Dacă aceste resurse nu sunt de ajuns, există un mailing list cu o arhivă bogată, la care ne putem abona.
Există o varietate de aspecte care ne pot convinge să utilizăm acest produs în următorul nostru proiect: Velocity este un procesor robust, flexibil şi bogat în funcţionalităţi. Există dezvoltatori care afirmă că acesta ar fi cel mai puternic toolde acest tip de pe piaţă.
Un alt plus al acestui proiect este faptul că, pe lângă Velocity Engine, are în componență o serie de subproiecte: Tools (unelte și elemente de infrastructură, folositoare pentru dezvoltarea de aplicații web și nu numai), Anakia (transformare de documente XML), Texen (generare de text), DocBook Framework (creare de documentație), DVSL (Declarative Velocity Style Language - transformări XML).
Când vine vorba despre suport pentru IDE-uri, Velocity beneficiază de o serie deplugin-uri dezvoltate de membri ai comunităţii. Aceste plugin-uri sunt dedicate unor IDE-uri precum Eclipse, NetBeans, IntelliJ IDEA, ca să le amintim doar pe cele mai populare. Multe dintre acestea oferă evidenţierea sintaxei şi chiarautocompletion. La dezvoltarea exemplului prezentat în acest articol am folosit Velocity Edit pentru Eclipse.
Așa cum am arătat într-un paragraf anterior, integrarea cu Spring MVC este facilă. De asemenea, distribuţia Spring MVC conţine o bibliotecă de macro-uri pentrubinding support şi form handling, unelte valoroase pentru dezvoltarea de aplicațiiweb.
Deși este cel mai popular template engine în universul Java, Apache Velocity nu a mai beneficiat de niciun release din noiembrie 2010, când s-a lansat versiunea 1.7 a nucleului proiectului. Proiectul este încă activ, însă comunitatea pare a fi mulțumită cu funcționalitățile deja implementate și încă nu există un releaseplanificat.
Velocity este un proiect la care s-a contribuit intens, devenind un produs complex, intimidant pentru noii utilizatori. Sintaxa este oarecum greoaie, iar scrierea detemplate-uri fără ajutorul unui IDE care să suporte sintaxa VTL poate fi un coşmar.

FreeMarker

FreeMarker este un produs matur, distribuit sub licenţă BSD. Asemănător proiectului Apache Velocity, FreeMarker oferă funcţionalităţi complexe care vin în întâmpinarea nevoilor dezvoltatorilor de aplicaţii web. Acesta a fost proiectat pentru generarea eficientă a paginilor HTML, însă posibilităţile utilizării tool-ului nu se opresc aici. Aşa cum afirmă creatorii proiectului, acesta este un produs software generic pentru generarea de text, aceasta însemnând orice de la HTML la cod sursă.

FreeMarker Template Language

Pentru descrierea şabloanelor, FreeMarker ne pune la dispoziţie un limbaj puternic de templating, numit FreeMarker Template Language. FTL ne permite definirea de expresii, funcţii şi macro-uri în cadrul şabloanelor pe care le scriem. De asemenea, ne este pusă la dispoziţie o bibliotecă bogată cu directive predefinite, care ne dau posibilitatea să iterăm colecţii de date, să includem alte şabloane şi multe altele. În continuare, prezentăm un exemplu de apel al unei directive FTL, care asignează o valoare unei variable:
<#assign magazineUrl = "http://www.todaysoftmag.com/">
Observăm că în limbajul de templating specific FreeMarker, directivele predefinite se apelează folosind sintaxa <#numedirectiva parametri>, iar macro-urile se apelează cu ajutorul sintaxei <@macro parametri>. Expresiile se scriu astfel:${expresie}.

Integrarea cu Spring MVC

La fel ca în cazul Apache Velocity, FreeMarker beneficiază de suport pentru integrarea cu Spring MVC chiar din partea creatorilor framework-ului web. Astfel, distribuția Spring MVC ne oferă o implementare de ViewResolver, dar şi o bibliotecă cu macro-uri pentru binding support şi form handling.
Folosind aceeași modalitate pentru a crea o aplicație Spring MVC + FreeMarker ca în cazul Apache Velocity, remarcăm că singurele modificări pe care trebuie să le efectuăm sunt în fișierul de configurare Spring și în șabloane. De fapt, vom vedea că acest lucru este valabil și atunci când ne vom ocupa de proiectele Thymeleaf și Rythm. De asemenea, trebuie să remarcăm că avem nevoie să declarăm în fișierul de configurare Maven dependința freemarker din grupul org.freemarker. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă:https://springfreemarker.googlecode.com/svn/trunk.
În servlet-context.xml înlocuim bean-ul de configurare și bean-ul cu rol de view resolver. Cel mai interesant aspect al acestor elemente XML este proprietatea cu cheia auto_import, care ne permite să importăm în toate fișierele noastre FTL macro-urile definite în fișierul spring.ftl, oferit de către distribuția Spring MVC. Acestea sunt accesibile prin intermediul alias-ului spring:
/spring.ftl as spring
Șablonul corepunzător view-ului list este reprezentat de fișierul list.ftl. Partea notabilă a acestuia este prezentată în continuare:
<#include "header.ftl" />

Products

<#include "footer.ftl" />
În acest template observăm cum se poate include conținutul altui șablon, cum putem itera o colecție de obiecte și cum scriem o expresie FTL.

Avantaje și dezavantaje

Proiectul FreeMarker se bucură de o documentație cuprinzătoare, site-ul oficial oferind un manual bogat, din care atât programatorii, cât și designerii pot extrage multă informație utilă. De asemenea, există un mailing list pentru discuții, însă utilizatorii sunt încurajați să ceară ajutor pe Stack Overflow, punând întrebări marcate cu tag-ul "freemarker". Deși FreeMarker este un template engine popular, până în prezent s-a publicat o singură carte dedicată acestuia.
FreeMarker oferă un limbaj de templating complet și relativ ușor de înțeles. Se poate spune că acest procesor de șabloane se bate de la egal la egal cu Velocity, fiind un produs matur, gata să fie integrat în proiecte enterprise. Merită menționat că, asemeni proiectului prezentat anterior, FreeMarker oferă mecanisme decaching al șabloanelor.
Pe pagina oficială există o listă cu o serie de plugin-uri pentru diverse medii de programare. Pentru exemplul prezentat în acest articol am folosit plugin-ul care face parte din JBoss Tools Project pentru Eclipse. Acesta oferă evidențierea sintaxei, indicatori pentru erorile de sintaxă, code completion pentru numele de macro-uri și de proprietăți ale bean-urilor. Trebuie să remarcăm că plugin-urile disponibile pentru FreeMarker nu sunt la fel de puternice precum cele scrise pentru Apache Velocity. De fapt, plugin-ul dedicat NetBeans nu pare să funcționeze pentru versiunea 7 a acestuia, deși pe site este indicat că suportă versiunile mai mari sau egale cu 6.
La fel ca în cazul Apache Velocity, FreeMarker se integrează ușor cu Spring MVC. Așa cum am văzut într-o secțiune anterioară, Spring MVC oferă atât o implementare pentru ViewResolver, cât şi o bibliotecă cu macro-uri pentru binding support şi form handling.
Proiectul este destul de activ, cea mai recentă versiune fiind 2.3.20, publicată în iunie 2013.
Am văzut că proiectul prezintă cam aceleași plusuri precum procesorul de șabloane prezentat înaintea lui și putem spune că și la capitolul minusuri se aseamănă. Fiind un proiect la care se lucrează de ani buni, a devenit complex, apărând uneori ca dificil de stăpânit pentru noii utilizatori.

Thymeleaf

Thymeleaf este o bibliotecă Java distribuită sub versiunea 2.0 a licenței Apache, având ca scop principal crearea de șabloane într-un mod elegant. Cel mai potrivituse case pentru Thymeleaf este generarea de documente XHTML / HTML5 în context web. Totuși, acest tool poate fi folosit și în medii offline, fiind capabil să proceseze documente XML.
Creatorii Thymeleaf ne oferă un modul pentru integrarea cu Spring MVC, care ne dă posibilitatea să folosim acest produs pentru stratul de vizualizare al aplicațiilor noastre web, fiind astfel un substituent pentru JSP. Thymeleaf este bazat pe seturi de trăsături numite dialecte. Distribuția standard vine cu dialectele Standard șiSpringStandard, care ne permit să creăm așa-numite natural templates. Acestea pot fi afișate corect de către browser, chiar dacă le accesăm ca fișiere statice. Astfel, aceste documente pot fi privite ca niște prototipuri. Dacă avem nevoie de alte funcționalități decât cele predefinite, Thymeleaf ne dă posibilitatea să ne creăm propriile noastre dialecte. Un dialect oferă funcționalități cum ar fi evaluarea expresiilor sau iterarea colecțiilor.
Nucleul Thymeleaf este construit în jurul unui motor de procesare DOM, care este o implementare proprie, de înaltă performanță. Cu ajutorul acestui mecanism realizează o reprezentare a șabloanelor în memorie, iar apoi efectuează procesări pe baza configurației curente și a setului de date pus la dispozițe, traversând nodurile.

Standard Dialect și SpringStandard Dialect

Aceste două dialecte au aceeași sintaxă, marea diferență între ele fiind așa-numitul expression language folosit. Dacă dialectul Standard folosește OGNL, StandardSpring are integrat Spring Expression Language. De asemenea, dialectul SpringStandard are o serie de mici adaptări pentru a utiliza mai bine anumite funcționalități oferite de Spring. Notația pe care o folosește Thymeleaf în șabloanele sale poate fi observată în exemplul următor:
Today Software Magazine
Atunci când șablonul de mai sus este procesat cu Thymeleaf, acesta evaluează expresiile reprezentate ca valori ale atributelor situate în spațiul de nume th și înlocuiește valorile atributelor clasice HTML cu rezultatul procesării.
Pentru a putea beneficia de validarea documentului, trebuie să declarăm spațiul de nume astfel:

Integrarea cu Spring MVC

Așa cum am menționat, Thymeleaf ne oferă un modul pentru integrarea cu Spring MVC, disponibil atât pentru Spring 3 cât și pentru Spring 4. Pentru a beneficia de acesta, pentru exemplul nostru am adăugat în pom.xml dependința thymeleaf-spring3 din grupul org.thymeleaf. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă:https://springthymeleaf.googlecode.com/svn/trunk.

Avantaje și dezavantaje

Thymeleaf este un proiect care atrage tot mai mulți utilizatori, dar și programatori care contribuie la dezvoltarea acestuia. Site-ul oficial ne oferă o varietate de resurse pentru a ne familiariza cu acest produs. Mai mult decât atât, documentația existentă ne prezintă și cum putem extinde Thymeleaf cu propriile noastre dialecte. Pe lângă aceste tutoriale, avem la dispoziție articole pe diverse teme, un forum pentru utilizatori și un tutorial interactiv. Deși la momentul scrierii acestui articol nu există cărți dedicate acestui proiect, putem găsi numeroase articole despre Thymeleaf. De asemenea, avem la dispoziție și documentațiile Javadoc pentru API-urile thymeleaf și thymeleaf-spring.
Acest procesor de șabloane vine cu o filosofie diferită față de de Velocity și FreeMarker, lucru ce se poate observa și în sintaxa dialectelor Standard și SpringStandard. Thymeleaf pune mare accent pe conceptul de natural templating, care oferă posibilitatea creării de prototipuri statice.
O dată cu lansarea versiunii 2.0 a motorului Thymeleaf, mecanismul de procesare a șabloanelor a fost înlocuit, sporind performanțele acestuia. De asemenea, există și un sistem de caching al șabloanelor.
În ce privește integrarea cu mediile de programare, există un plugin pentru Eclipse care oferă autocompletion. Din păcate, nu există suport și pentru alte IDE-uri.
Asemeni proiectelor despre care am discutat până acum, integrarea cu Spring MVC este ușor de obținut, întrucât autorii Thymeleaf au creat un modul special pentru aceasta.
Proiectul beneficiază de lansări frecvente, versiunea curentă fiind 2.12.RELEASE. Aceasta este disponibilă publicului din decembrie 2013.
Thymeleaf oferă o gamă largă de funcționalități, însă testele arată că procesarea șabloanelor este mai lentă decât în cazul unora dintre competitorii săi.

Rythm

Rythm este un procesor de șabloane pentru aplicații Java distribuit sub licență Apache, versiunea 2.0, descris de autorul său ca fiind un produs cu scop general, ușor de folosit și foarte rapid. Asemeni altor procesoare de șabloane, putem procesa cu ajutorul acestuia documente HTML, XML, scripturi SQL, cod sursă, email-uri sau orice alt text formatat. Rythm a fost inspirat din proiectul .Net Razor, datorită sintaxei sale simple și elegante.
În aceiași termeni laudativi, autorul pretinde că preocuparea numărul unu a proiectului este experiența utilizator. De la API până la sintaxa șabloanelor, produsul este caracterizat prin simplitate. De asemenea, produsul a fost proiectat astfel încât utilizarea acestuia să fie cât mai facilă pentru programatorii Java.

Sintaxa procesorului de șabloane

Rythm folosește caracterul special @ pentru a introduce toate elementele de sintaxă. Acest lucru este exemplificat în blocul de cod prezentat în continuare:
@for (product: products) {
  • @product.getName()
  • }
    Pentru a putea utiliza în template obiecte adăugate modelului de date în controller-ul Spring, trebuie să folosim următoarea notație:
    @args java.util.List products

    Integrarea cu Spring MVC

    Pentru integrarea cu Spring MVC avem la dispoziție o bibliotecă de clase third-party, disponibilă ca artefact Maven sub id-ul spring-webmvc-rythm și grupulcom.ctlok. Având această dependință în proiect, putem declara bean-urile necesare în servlet-config.xml. Una dintre proprietățile bean-ului rythmConfigurator estemode, cu ajutorul căreia putem specifica în ce mod rulăm aplicația: dev sau prod. Codul sursă al proiectului exemplu poate fi descărcat de la următoarea adresă:https://springrythm.googlecode.com/svn/trunk.

    Avantaje și dezavantaje

    Spre deosebire de Velocity și FreeMarker, Rythm procesează șabloanele, transformându-le în bytecode Java. Datorită acestui lucru, la runtime, procesarea acestora este foarte rapidă, plasând acest proiect alături de cele mai rapide procesoare de șabloane din universul Java.
    Deși nu este la fel de vastă precum a celorlalte produse prezentate, documentația proiectului este cuprinzătoare, permițându-ne să deprindem abilitățile necesare dezvoltării de aplicații web cu ajutorul Rythm Template Engine. Pe site-ul proiectului există o serie de tutoriale, atât pentru programatori, cât și pentruwebmaster-i, iar cu ajutorul instanței Fiddle dedicate putem scrie șabloane Rythm și vedea rezultatul imediat. Fiind un proiect relativ tânăr, comunitatea din jurul lui nu este încă dezvoltată.
    Rythm poate opera în două moduri: dev (development) și prod (production). Astfel, în modul dev șabloanele sunt reîncărcate de fiecare dată când sunt modificate, pentru a scurta timpul de dezvoltare; pe de altă parte, în modul prod acestea sunt încărcate o singură dată, pentru sporirea performanței.
    Unul dintre minusurile proiectului Rythm este faptul că momentan nu oferă niciunplugin pentru medii integrate de dezvoltare. Astfel, deși sintaxa acestuia este cât se poate de prietenoasă, nu avem asistență din partea IDE-ului preferat pentru scrierea șabloanelor, un aspect important pentru mulți dezvoltatori.
    Rythm permite inserarea de cod Java în cadrul unui șablon, acesta fiind unul dintre aspectele care ne-au îndemnat să renunțăm la JSP în favoarea altor procesoare de șabloane. Așadar, vedem acest lucru ca pe un minus al proiectului.

    Performanțe

    Există prea puține teste relevante pentru determinarea performanței procesoarelor de șabloane prezentate în acest articol, însă în continuare vom prezenta rezultatele unor astfel de studii. Folosind tool-ul de benchmarkingdisponibil la adresa https://github.com/greenlaw110/template-engine-benchmarks am obținut următoarele rezultate pentru 10000 de request-uri:
    • Velocity: 3.8 secunde,
    • FreeMarker: 4.8 secunde,
    • Thymeleaf: 43.2 secunde,
    • Rythm: 3 secunde.
    Un alt test (disponibil la adresa http://www.slideshare.net/jreijn/comparing-templateenginesjvm), în care Rythm nu a fost inclus, arată că Velocity și FreeMarker au avut performanțe aproape identice, în timp ce Thymeleaf a fost, din nou, printre cele mai lente procesoare.
    Astfel, Rythm pare a fi cel mai rapid template engine dintre cele despre care am discutat în acest articol, Velocity și FreeMarker își dispută locurile al doilea și al treilea, în timp ce Thymeleaf a obținut cel mai slab timp.

    Concluzii

    Deși am văzut că proiectele prezentate ne pun la dispoziție funcționalități similare, în urma acestei discuții putem trage câteva concluzii. Atât Velocity, cât și FreeMarker sunt produse consacrate, care și-au dovedit valoarea în multe proiecte de succes, oferind performanță decentă. Pe de altă parte, Thymeleaf și Rythm sunt proiecte mai tinere, care vin cu o filosofie nouă, adaptată trendurilor în dezvoltarea web. Spre exemplu, Thymeleaf excelează la capitolul naturaltemplating, în timp ce Rythm oferă o sintaxă curată, ușor de înțeles atât pentru programatori, cât și pentru webmaster-i. Putem concluziona că alegerea unuitemplate engine depinde, în primul rând, de proiectul pentru care avem nevoie de acesta, fiecare dintre procesoarele despre care am discutat meritând să fie luat în considerare.

    Integrarea datelor între sisteme cu Talend Open Studio

    (Publicat în revista Today Software Magazine, Numărul 25, Iulie 2014: http://www.todaysoftmag.ro/article/1038/integrarea-datelor-intre-sisteme-cu-talend-open-studio)

    Aşa cum menţiona Jonathan Bowen în cartea sa, „Getting Started with Talend Open Studio for Data Integration”, de îndată ce a apărut cel de-al doilea calculator, integrarea sistemelor a devenit o parte esenţială a muncii echipelor IT.

    Complexitatea sistemelor de astăzi, împreună cu ritmul alert în care afacerile evoluează, evidenţiază nevoia de a avea la îndemână un set de unelte care să ne permită executarea rapidă a sarcinilor de integrare. De asemenea, trebuie să fim în stare să reacţionăm cu promptitudine la oportunităţile de noi afaceri.

    Experienţa ne-a arătat că, de cele mai multe ori, noii clienţi vin cu cerinţa de a integra în ecosistemul acestora produsul pe care noi îl oferim. Rareori un sistem informatic funcţionează izolat, în propriul său univers. În mai multe rânduri am observat că succesul proiectului propus unui client a depins de capacitatea noastră de a integra sistemul cu produsele pe care acesta deja le folosea.

    Procesul despre care vorbim poate însemna sincronizarea a două baze de date o singură dată sau recurent, consumarea unor servicii – fie ele servicii web sau de altă natură – generarea şi transferul de fişiere în diferite formate etc. Aşadar, observăm că avem de-a face cu o varietate de modalităţi prin care putem duce la îndeplinire aceste sarcini, acest lucru contribuind la creşterea complexităţii problemei. De asemenea, uneori este la latitudinea noastră să decidem modalitatea prin care vom realiza integrarea însă, de multe ori, clientul are cerinţe specifice şi în legătură cu acest aspect.

    Atunci când ne confruntăm cu o astfel de situaţie, putem fie să construim manual interfaţa între sisteme, ca o soluţie custom, fie să utilizăm un tool specializat pe rezolvarea problemelor de integrare. Un astfel de tool este Talend Open Studio, care vine cu o ofertă interesantă pentru a ne ajuta la rezolvarea sarcinilor noastre de integrare.

    Un overview al mediului Talend Open Studio

    Talend Open Studio for Data Integration este un mediu de dezvoltare grafic care, după cum spune şi numele acestuia, este specializat în integrarea datelor între sisteme. La baza sistemului open source stă mediul Eclipse. Alături de crearea soluţiilor de integrare, Talend Open Studio cuprinde şi mecanismele necesare livrării acestora – job-urile pot fi rulate atât din interiorul mediului, cât şi ca script-uri de sine stătătoare.

    Pentru modelarea proceselor, sistemul utilizează conectori. Dezvoltatorii produsului ne oferă peste 800 de astfel de conectori, care ne dau posibilitatea să conectăm cu uşurinţă baze de date, să citim informaţii din diverse surse, să transferăm fişiere şi să efectuăm operaţii asupra lor. De asemenea, avem posibilitatea de a conecta componente specializate pentru a defini procese complexe de integrare.

    O bună parte din munca pe care o îndeplinim cu ajutorul Talend Open Studio este reprezentată de modelarea grafică a proceselor pe care dorim să le definim. În tot acest timp, platforma îşi face treaba de zidar în background, generând cod Java. În fond, fiecare componentă pe care o utilizăm are asociat un comportament, descris prin intermediul codului Java.

    Având în vedere faptul că acesta este un tool grafic, produsul poate fi utilizat atât de programatori, cât şi de persoane care nu au cunoştinţe de programare. Totuşi, pentru a putea defini anumite comportamente complexe, este nevoie să scriem din când în când cod Java, lucru care ne determină să concluzionăm că utilizatorii care nu cunosc programare se confruntă cu anumite limitări.

    Talend Open Studio este relativ uşor de folosit, este o modalitate rapidă de a modela scenarii de integrare, de cele mai multe ori reducând timpul de implementare de la săptămâni sau luni, la zile sau chiar ore, în funcţie de complexitatea proiectului. Totuşi, trebuie să avertizăm cititorii că, asemeni multor altor domenii, dacă din cauza excesului de zel sau a unui design nepotrivit facem overengineering, riscăm să obţinem o soluţie complexă, greu de înţeles pentru alţi utilizatori sau chiar ineficientă. Există şi aici necesitatea respectării unor bune practici, care să asigure calitatea soluţiei noastre.

    Printre alte beneficii ale utilizării Talend Open Studio, trebuie să remarcăm că acesta este un produs open source, care permite utilizatorilor să extindă platforma după nevoie. De asemenea, utilizându-l creşte productivitatea, deoarece dezvoltatorii se pot concentra mai mult la definirea procesului decât la implementarea tehnică a acestuia. Ne sunt puse la dispoziţie o mulţime de componente, potrivite situaţiilor mai mult sau mai puţin obişnuite, cu care putem opera pentru a ne defini procesele. În plus, comunitatea utilizatorilor Talend este activă şi gata să ofere sfaturi tehnice.

    Scenarii de utilizare

    După cum am menționat în secțiunea anterioară, cele mai obișnuite scenarii de utilizare a proiectului Talend Open Studio sunt următoarele:

    Transfer între baze de date: Atunci când sunt create sisteme noi sau cele existente sunt actualizate, este nevoie ca datele să fie migrate într-o nouă bază de date. Aceasta poate să aibă aceeași schemă sau una diferită, iar Talend Open Studio ne oferă conectorii și acțiunile necesare acestui proces.

    Schimb de fișiere: Sarcinile de integrare pot necesita transferuri de date în cantități mari. Acest lucru se realizează adesea prin intermediul fișierelor. Un exemplu de astfel de fișier este clasicul CSV (comma separated values). De asemenea, este posibil ca sistemul care primește fișierul de transfer să aibă nevoie de date într-un alt format. Și acest caz este acoperit de către Studio, fiindcă ne dă posibilitatea să definim procese care efectuează transformări asupra datelor transferate. În plus, avem la dispoziție capabilități de management al fișierelor, prin operații cum ar fi transferul prin FTP sau arhivarea.

    Sincronizare: Sistemele care colaborează nu sunt conectate întotdeauna la același data repository, ceea ce înseamnă că anumite informații pot fi duplicate într-un ecosistem. În consecință, avem nevoie să ne asigurăm că acestea sunt sincronizate periodic. Acesta este cazul datelor despre clienții unei companii, care pot fi prezente, spre exemplu, în sistemul de finanțe, cel de distribuție sau în platforma CRM. Talend Open Studio poate fi folosit pentru a realiza sincronizarea sistemelor, cu ajutorul unor job-uri care automatizează procesul.

    ETL: Acesta este un acronim pentru Extract, Transform, Load, termeni care descriu un proces de bază pentru sistemele data warehouse. Un astfel de proces extrage date din sisteme operaționale, le transformă aplicând reguli sau funcții, iar apoi le încarcă în data warehouse. Din nou, Talend Open Studio ne face viaţa mai uşoară, ajutându-ne substanţial la implementarea acestui tip de proces.

    Exemplu

    Pentru a ilustra uşurinţa utilizării acestei platforme, creăm un proiect cu un job care transformă un fişier XML într-un fişier CSV. Modelul grafic pentru acest job simplu este ilustrat în figura de mai jos.


    În partea stângă avem o componentă de tip tFileInputXML, iar în partea dreaptă o componentă de tip tFileOutputDelimited. Acestea sunt conectate printr-un conector Main. Înainte de a trage componenta de intrare în designer am definit un obiect metadata, căruia i-am asociat un fișier XML. Studio-ul a detectat automat schema documentului și ne-a dat posibilitatea să selectăm ce noduri să fie transferate către output. Prin intermediul conectorului Main, Talend a transferat către fișierul de ieșire exact structura pe care am definit-o, fără ca noi să scriem vreo linie de cod. Tot ce a trebuit să configurăm în componenta de ieșire a fost calea și numele fișierului CSV.
    Bineînțeles, putem extinde acest job, conectând în continuare alte componente, cum ar fi cele care lucrează cu conexiuni FTP, pentru a transfera fișierul nostru către sistemul țintă.

    Concluzii


    În secțiunile anterioare am văzut pe scurt care este contextul în care sunt realizate procesele de integrare, ce este Talend Open Studio și care sunt beneficiile utilizării acestui produs. De asemenea, printr-un mic exemplu am încercat să ilustrăm simplitatea utilizării Studio-ului, rapiditatea implementării job-urilor și să ne facem o părere despre capacitatea acestei platforme.

    Atlassian JIRA REST API

    (Publicat în revista Today Software Magazine, Numărul 30, Decembrie 2014: http://www.todaysoftmag.ro/article/1186/atlassian-jira-rest-api)

    Nu cred că este o coincidenţă faptul că Atlassian JIRA este tool-ul folosit pentruissue tracking în toate proiectele la care am luat parte până acum. Deşi există destul de multe produse de genul acesta pe piaţă, JIRA este unul dintre numele recunoscute de majoritatea actorilor implicaţi în proiecte informatice. Alături de alte titluri sonore precum Bugzilla sau Redmine, JIRA iese în evidenţă prin setul complet de funcţionalităţi, calitate, uşurinţa utilizării, dar şi prin extensibilitatea sa.
    Atlassian JIRA a fost conceput ca un produs flexibil, uşor extensibil prin intermediul plugin-urilor. De asemenea, sistemul comunică cu lumea exterioară printr-o interfaţă REST, prin intermediul căreia clienţii platformei pot efectua diverse operaţii. În rândurile care urmează ne vom concentra atenţia asupra trăsăturilor acestui API, discutând câteva use case-uri clasice, cum ar fi căutarea unui issue sau adăugarea unui comentariu. De asemenea, vom petrece puţin timp uitându-ne atât la clientul Java pus la dispoziţie de Atlassian, cât şi la implementarea unui client REST utilizând Jersey, implementarea de referinţă de la Oracle.

    JIRA REST Java Client

    Atlassian ne pune la dispoziţie o bibliotecă de clase menită să ne înlesnească lucrul cu API-ul REST, aceasta numindu-se sugestiv JIRA REST Java Client. Această bibliotecă expune la rândul său un API aproape complet pentru operațiile pe care le putem face într-un proiect JIRA. Spre exemplu, prin intermediul acestui client avem posibilitatea să găsim un anume proiect după cheie, să creăm tichete, să le ştergem, să adăugăm atașamente, să adăugăm worklog-uri și multe altele.
    Metodele pe care le avem la dispoziție sunt grupate în mai multe clase, în funcție de obiectul business despre care este vorba. De exemplu, putem apela metodele ce țin de administrarea issue-urilor doar după ce obținem un obiect de tip IssueRestClient. Înainte de aceasta, avem nevoie de un obiect de tip JiraRestClient, creat prin intermediul unei implementări asincrone a interfeței JiraRestClientFactory.
    Detaliile menționate mai sus pot fi observate în clasa JiraClient care face parte din proiectul demonstrativ ce însoțește acest articol. Proiectul poate fi descărcat de la adresa menționată în secțiunea Resurse. Trebuie să observăm faptul că acest proiect Java are scop didactic, codul sursă fiind unul minimal, care nu urmăreşte să respecte bunele practici.
    Să presupunem că dorim să obținem cu ajutorul bibliotecii JRJC un obiect de tip Issue, ce modelează detaliile unui tichet JIRA. Acum că avem la dispoziție un obiect de tip JiraRestClient putem scrie următoarele:

    Promise promise = jiraRestClient.getIssueClient().getIssue("JRA-9");
    Issue issue = promise.claim();

    Observăm că metoda getIssue(String issueKey) returnează un obiect de tip Promise, motiv pentru care, pentru a obține instanța Issue trebuie să apelăm metoda claim(). În aceeași manieră trebuie să procedăm și pentru obținerea altor obiecte, cum ar fi proiecte, worklogs etc. .
    Unul dintre avantajele utilizării acestei biblioteci îl reprezintă faptul că nu trebuie să ne preocupăm de subtilitățile lucrului cu servicii REST. În fond, până în acest moment pentru noi a fost transparent faptul că avem de-a face cu un API REST. Pentru a ne face o părere mai clară despre ce înseamnă JIRA REST API, trebuie să realizăm propria noastră implementare a unui client REST, lucru pe care îl vom face utilizând Jersey.

    Client REST cu Jersey

    Jersey ne oferă un mod simplu și rapid de a crea un client REST, aspect pe care îl ilustrăm în continuare:

    String auth = new String(Base64.encode(USERNAME + ":" + PASSWORD));
    Client client = Client.create();
    WebResource webResource = client.resource(JIRA_SERVER + REST_PATH + query);
    Builder builder = webResource.header("Authorization", "Basic " + auth)
        .type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);

    Revenind la scenariul în care dorim să regăsim un tichet pe baza cheii, presupunem că parametrul query conține o cale de genul issue/JRA-9, unde JRA-9este cheia tichetului. Pentru a obține obiectul Issue apelăm metoda get(), care corespunde metodei HTTP GET.

    ClientResponse clientResponse = builder.get(ClientResponse.class);

    În acest moment putem obține obiectul JSON serializat, sub forma unui String:

    String json = clientResponse.getEntity(String.class);

    Acest String poate fi apoi deserializat într-un bean creat de noi cu ajutorul bibliotecii Jackson, care ne pune la dispoziție diverse unelte de lucru cu JSON. Acest scenariu este unul dintre cele mai simple, însă lucrurile devin mai complicate atunci când trebuie să creăm un worklog, spre exemplu. În acest caz, mai întâi trebuie să creăm un bean cu ajutorul căruia să modelăm un worklog și să populăm o instanță cu informațiile pe care dorim să le salvăm. Apoi trebuie să serializăm acest obiect sub forma unui String și să-l transmitem serviciului REST după modelul de mai sus, însă folosind metoda HTTP POST de data aceasta. Răspunsul serviciului va conține obiectul salvat sub formă serializată, îmbogățit cu noi informații, cum ar fi id-ul worklog-ului.

    Concluzii

    JIRA REST API este o interfață către lumea exterioară care are o valoare business incontestabilă. Acest API oferă organizațiilor posibilitatea să integreze cu ușurință tool-ul în ecosistemul propriu, pentru a defini procese dintre cele mai creative și complexe. Totuși, se poate observa că JIRA REST API nu acoperă în totalitate scenariile de utilizare JIRA. Unul dintre aspectele pentru care utilizatorii așteaptă o rezolvare îl reprezintă imposibilitatea de a lucra cu filtrele salvate. Există și un tichet pe acest subiect (JRA-36045), care încă este deschis.
    Pe de altă parte, trebuie să menționăm că API-ul REST vine cu funcționalități importante, cum ar fi posibilitatea de a regăsi câmpurile custom și valorile acestora, operație pe care nu o puteam face cu API-ul SOAP.
    JIRA REST API a ajuns la versiunea a doua şi, chiar dacă există loc de îmbunătăţiri, putem spune că este un produs matur, care vine cu funcţionalităţi importante față de predecesorul său.

    Resurse

    1. https://jira-rest-client-ro-leje.googlecode.com/svn/trunk
    2. https://docs.atlassian.com/jira/REST/latest/
    3. http://www.j-tricks.com/tutorials/java-rest-client-for-jira-using-jersey
    4. http://www.baeldung.com/jackson-ignore-null-fields