Prezentare GyroGears !

Salut. Am facut un draft al primului tutorial GyroGears. E un pic cam lung (41 de minute), deoarece am inceput prin a prezenta si Concept Application Server (primele 10 minute).

Vizionare placuta (daca exista rabdarea necesara) !

"Enhancing the User Experience" sau poze colorate

Revin cu elemente noi prin GyroGears (distributia de pe www.radgs.com a fost deja actualizata, pachetul Concept Application Server, ce contine GyroGears BETA). In afara de foarte multa depanare, am mai adaugat thumbnails-uri pentru campurile de tip 'picture'. Cred ca se poate oferi astfel o aplicatie vie, ce poate reuseste sa prezinte view-uri mai ... "non-foxpro" (fara suparare fata de programatorii fox). Practic sunt puse cap la cap toate elementele pentru a genera un catalog virtual sau un magazin virtual in cateva minute. Sa nu uit ! Screenshot-ul este dintr-o aplicatie "A basic organizer" definita folosind GyroGears in 21 de minute. Exista si screencast-ul pt asta, doar ca, inca nu am avut timp sa fac comentariile pentru prezentare.

GyroGears si touch screen

Am finalizat suportul de touchscreen pentru GyroGears. Totul se rezuma la cateva operatii foarte simple, astfel: un flag(bifa) cu "Optimize for touch screen" si filtre de touch screen. Un filtru de touchscreen imi va genera niste butoane foarte mari, pe care utilizatorul va face click "sectionand" view-urile. Astfel, daca ne gandim la un sistem horeca, putem defini filtre pentru "sucuri", "bauturi alcoolice", "cafele", etc.. Cand utilizatorul va alege "sucuri", i se vor afisa numai entitatile din "Produse" ce fac parte din categoria "suc". Am atasat si 2 screenshot-uri: primul din GyroGears, din zona de definire a filtrelor de touch screen si un al doilea screenshot cu interfata rezultata, cu "Handpad"-ul vizibil.

.
Fig 1 - Definirea filtrelor de touchscreen


Fig 2 - Interfata touchscreen

Intre o cana de ceai si IT Academy

Ce fac programatorii Concept in week-end:

- Am fost sambata sa le vorbesc celor din AISEC despre Concept. Trebuie sa recunosc ca a fost destul de interesant, reusind sa stabilesc contact cu destul de multe persoane interesate.

- Intre Gyro si Concept, m-am pus la o cana de ceai de menta, in umbra bradului meu de Craciun. Dupa care, am realizat ca doar ce a trecut 1 Martie si inca mai am bradul ... dar e frumos, si inca nu naparleste ... oare va rezista pana in decembrie ? ... sau va trebui, ca in anii precedenti, sa-l scot tiptil-tiptil noaptea, ca sa nu ma vada vecinii, probabil candva prin luna mai ?

GyroGears BETA pentru toata lumea

Am revenit. Din pacate luna aceasta am fost foarte ocupat, atat cu CAS si mai ales cu GyroGears. Multe lucruri noi, printre care: combo-uri conditionate, astfel:
Daca avem o relatie (many to *) atunci putem sa definim un filtru. La ce este util ? La foarte multe, cum ar fi, entitatile de tip Judet ce sunt in relatie cu Orase. Atunci, intr-un form, cand aleg judetul, e mult mai interesant daca pentru oras, nu ma lasa sa aleg decat din orasele judetului.

Multe briz-briz-uri adaugate precum suportul de touchscreen (butoane mai mari si buton "context-helper" pentru emularea click-dreapta) ... si nu in ultimul rand ... mult debugging !

O alta veste buna este ca: GyroGears 0.91 BETA este inclus in pachetul Concept Application Server !
... fiind free, dar din pacate, deocamdata nu open-source.
Pachetul poate fi downloadat de pe www.radgs.com.

Optimizari!

In ultimul timp am fost preocupat de optimizari pentru Concept Application Server si GyroGears. Astfel, dupa o gramada de bataie de cap, am reusit reducerea cu 48% a necesarului de memorie, un server putand rula acum un numar dublu de aplicatii CAS/Gyro. Optimizarile au fost facute doar in framework (44%) si in core(4%). Totusi, ma gandesc la mai mult: avand in vedere ca cea mai mare cantitate de memorie intr-o aplicatie GyroGears este folosita de UI, m-am gandit sa fac un "MinimalControl". Este practic o clasa ce are numarul minim de membri, se opereaza mai low-level cu ea (ex: proprietatile se scriu minimalControl.SetProperty(P_CAPTION, "Text") ). Aceste clase nu vor interactiona cu programatorul (codul fiind generat automat de GyroGears si de CIDE). Ma astept ca in acest mod sa reduc inca o data la jumatate necesarul de memorie. Inca ma gandesc cum voi face transofrmarea de la un "MinimalControl" la controlul echivalent, de exemplu RButton.
Pentru aplicatia de test (HRCompanion) am redus practic consumul de memorie de la 178MB la 93MB. Acum, daca as reusi sa ajung sub 50MB ar fi excelent (avand in vedere ca este o aplicatie foarte complexa).

Pana atunci, intram iar in BETA cu framework-ul ... dar probabil ca-l voi propune ca versiunea 1.1.

Pregatiri Concept(uale)

Lucrez intens la partea de Web pentru GyroGears. Nu e un secret faptul ca atunci cand se doreau aplicatii web traditionale (pagini web de server) se rula in general prin Apache + Concept CGI.
Dezavantajele folosirii interpretorului CGI erau evidente: de la securitate, pana la timpul de raspuns crescut (dar de cele mai multe ori insesizabil). Dincolo de asta, erau cazuri cand nu se interceptau erorile (din diferite motive, cum ar fi netrimiterea header-urilor s.a.m.d.).

Solutia a fost sa fac un modul de Apache 2.x. Bataie mare de cap de un week-end ... in principal din cauza documentatiei sau mai bine spus a lipsei "dansei". In final, cu chiu cu vai, uitandu-ma peste ce au facut altii si facand zeci de artificii, numite de mine "ciorba" am legat ceva ... ii voi spune deocamdata versiunea 0.8 beta. De ce 0.8 ? Pentru ca asigura 80% din functionalitate. Concept pentru aplicatiile web, foloseste qDecoder. O biblioteca bine gandidata pe fiecare versiune in parte ... dar prost gandita in materie de versiuni, astfel, codul scris pe versiunea 6 nu va fi compatibil pe versiunea 9 ... Dincolo de asta, a trebuit sa iau versiunea 6 si sa o modific astfel incat sa functioneze si cu Apache. Practic, qDecoder presupunea rularea ca CGI si citea totul din variabilele de mediu (environment variables). A trebuit sa modific inclusiv in CORE-ul Concept astfel incat sa am un parametru "userdata" (care poate fi practic orice) care sa circule intre Apache si qDecoder, traversand Concept CORE... mare bataie de cap, dar a iesit bine.
Acum, problema este cu memoria: Daca in materie de CORE lucrurile stau relativ bine(bine e imposibil, pentru ca vorbim de software => bug-uri), in multe biblioteci 3rd party exista memory leak-uri, facand sa creasca memoria necesara procesului Apache HTTPD. Creste, dar pana cand ? ... pana se restarteaza Apache. Suna un pic alarmant, dar leak-urile tin de bibliotecile altora ... O poza intitulata "not my job" imi explica punctul de vedere(nu o copiez aici pentru a evita problemele de drepturi de autor). Acum, nu spun ca nu exista memory leak-uri in CORE-ul Concept sau in Concept Framework ... Probabil ca exista, si cum le voi descoperi sau imi vor fi raportate, le voi repara.
Pe pagina http://www.radgs.com/43-apache-2-module.html exista instructiuni pentru configurarea lui Apache HTTPD 2.x atat pentru ferestre cat si pentru pinguini sau draci.
Pana atunci, testam interfetele pe cativa din clientii nostri, care au trecut azi de pe CGI pe mod_concept si deocamdata n-au aparut probleme.

PS: Am rezolvat un bug minor din Concept Client care facea consola sa ramana uneori deschisa atunci cand aparea o eroare. Acum se inchide. Era un bug minor, deoarece nu afecta functionarea aplicatiilor. Oricum, am pus update-ul pe site.

GyroGears devine BETA de Craciun

In timp ce oamenii normali* sarbatoreau Craciunul alaturi de cei dragi, eu am sarbatorit in felul meu: lucrand. Am lucrat foarte mult in ultimul timp la cateva elemente noi:

1. Generatorul automat de help pentru aplicatiile Gyro
2. Rapoartele avansate (ca un inceput de solutie de B.I.<<nu ca as fi pe deplin lamurit ce inseamna B.I. >>)

Acum, pe rand: Generatorul automat de help, face documentatia pentru toata aplicatia generata de GyroGears. Am mers pe o solutie foarte simpla, templatizata (astfel incat sa fie foarte usoara adaptarea pentru o alta limba decat cea default). Un exemplu poate fi vazut aici: http://www.radgs.com/help_sample/ . Veti observa probabil romengleza in care este scris. Acest lucru este cauzat (nu datorat !) de faptul ca aplicatia este descrisa in limba romana iar template-ul de help este in limba engleza (iar, a se ignora greselile gramaticale - voi reveni asupra template-urilor in perioada BETA). Toata aceasta documentatie a fost generata 100% automat fara pic de interventie din partea mea. De asemenea, este integrata in aplicatie, raspunzand la F1 - pentru prezentarea "capitolelor" sau Ctrl-F1 pentru help senzitiv, afisand help pentru contextul din care se invoca help-ul.

Acum, revenind la lucruri (si mai) serioase: Rapoartele avansate
Aici, cateva probleme au fost intalnite:

1. rapoartele in Gyro se bazeaza foarte mult pe XSL:FO, standard ce mie personal imi place tare mult, dar recunosc ca nu sunt inca familiarizat cu tot ce stie/poate sa faca. Din pacate este destul de greoi, mai ales cand deployment-ul rapoartelor se face pe Apache FOP (ce nu are o implementare 100% compatibila). Solutia a fost implementarea a unui nivel nou, asemanator cu HTML-ul (chiar partial compatibil cu HTML-ul) pentru generarea rapoartelor. Cateva elemente au fost adaugate, precum pie, chart, datasource, parameter, call, etc.. A fost nevoie de aceste tag-uri pentru a interactiona elegant, modular si in siguranta cu baza de date. (vezi screenshot).
2. Parcurgearea rezultatelor interogarilor (a dataset-urilor) poate genera ambiguitati atunci cand sunt folosite succesiv. De exemplu: pentru un dataset, poate avem nevoie de o parcurgere 2 pasi inainte, unul inapoi. Acum totul depinde de "client"-ul bazei de date si de setarile facute pentru accesta. Daca tot rezultatul va fi adus pe client, este permisa trecerea de la un rand(row) de index mai mare la unul cu index mai mic. Daca nu (daca rezultatul este adus succesiv in cate 1-2-5-N row-uri), nu va fi posibila o astfel de parcurgere. Solutia a fost relativ simpla, dar mancatoare de memorie: aducerea intregului rezultat intr-o matrice. In acest fel, datele pot fi parcurse, extrase sau prelucrate fara limitari si fara restrictii data de setarile clientului pentru baza de date. Daca ai obiectiuni, am un argument cat se poate de serios: daca extragi milioane de inregistrari (cat sa umpli intreaga memorie disponibila) ... unde le vei tipari ? ... pentru ca vorbim totusi de rapoarte "standard" si nu interogari ale bazei de date. In 99% din cauzuri este vorba de pie-chart-uri, grafice sau niste tabele "citibile" de oameni.
3. Abstractizarea extragerii de date, astfel incat sa poata fi prelucrate date atat de la o simpla interogare SQL sau o succesiune te interogari SQL (ce pot fi grupate si astfel incat rezultatul uneia poate fi parametru de intrare la alta) cat si de la o functie scrisa manual (pentru cazuri speciale).

Dupa ce toate problemele au fost rezolvate si a fost gasita si o solutie de setare a parametrilor pentru rapoarte (tot XML-based) s-a ajuns la:






Am atasat si raportul in format XML.
Cateva screenshot-uri cu raportul in formatul final (asa cum a fost generat) si cu help-ul integrat in aplicatie:



Ok. Acum la 2:15, in noaptea de Craciun, ma pot culca linistit stiind ca GyroGears poate satisface orice solicitare in materie de baze de date si raportare, atata timp cat "orice" este egal cu 98%.

"Craciun fericit" celor crestini si "Sarbatori fericite" celorlalti.

*) oameni normali = presupunem conceptul de normalitate ca fiind definit de majoritate, pentru ca in final nimeni nu-mi pare mai normal decat mine si probabil ca nimeni nu-ti pare mai normal decat tine. In concluzie, cum imi spunea un prieten foarte bun candva: "normalitatea este relativa"

GyroGears 1.0

Am tot vorbit de GyroGears, dar nimeni nu l-a vazut inca. Il veti vedea candva prin aprilie 2009 ... pana atunci, am pus un mic filmulet ca sa va faceti o idee.

Date conditionate

Am revenit, bineinteles cu features-uri noi prin GyroGears. Nu de alta, dar simteam nevoia de a ma lauda. Ideea este ca avem cateva elemente noi:
1) cautarea dupa parinti a entitatilor
Practic acum putem sa cautam folosind o sintaxa foarte simpla. Sa presupunem ca avem Client, Oferte si Produse. Vrem sa cautam toate produsele ce figureaza pe oferta unui client. Atunci, pur si simplu definim in interfata Gyro o cale de cautare:

Furnizori: Furnizor/Oferte primite/Produse

In aplicatia rezultata ni se va genera un camp de cautare de unde vom alege un Furnizor. Legatura este definita de calea de mai sus (exact ca o cale de directoare). Simplu, nu ?

2) Campuri conditionate
Folosind aceste definitii XML (ca in screenshot) se pot defini conditionari. Pentru exemplu de mai sus putem defini ca atunci cand unitatea de masura este 'g'(gram) sa nu se mai ceara numele produsului. Practic putem dezactiva sau ascunde categorii intregi, nu numai campuri. Stiu ca exemplul este unul ... oarecum inutil ... dar pe el am testat.

3) Campuri de definire a rapoartelor
De acum cateva versiuni exista posibilitatea de a defini elemente de adaugat in rapoarte, asa cum se vede in imaginea alaturata. Va las pe voi sa va dati seama ce si cum face.