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.

Programare automata

Am adaugat noi elemente de cautare in GyroGears. GyroGears este un sistem automat de dezvoltare bazat pe modelare din specificatii (practic se descrie ce se doreste, iar Gyro va genera intreg codul sursa si framework-ul ... numai bun de integrat in Concept IDE). Noutatea consta in faptul ca acum se poate cauta si dupa entitati inrudite ("relatii").

In screenshot-uri este o aplicatie simpla de evidenta a ofertelor primite de unul din clientii nostri ce primeste pe mail oferte in format XLS si vrea sa aiba produsele intr-un sistem prin care sa caute dupa diverse criterii. Totul a fost foarte simplu, cu toate ca Excel este o tehnologie Microsoft iar Concept ruleaza pe tehnologii Linux (chiar daca ruleaza pe Windows).
Simplitatea a fost data de ODBC ... care a oferit acces imediat la fisierul Excel. Oricum, dincolo de asta, aplicatia a fost dezvoltata in aproximativ 30 de minute (generand inclusiv rapoarte). In curand vom avea o prezentare oficiala pentru GyroGears.

Bohemian_developer.Init()

Spatiul ... ultima frontiera ... cu 5 ani in urma am hotarat ca modelele actuale web si desktop nu sunt tocmai pe gustul meu. Pe atunci eram student ... am hotarat sa ma avant (cu capul inainte) in acest proiect ... proiect numit Concept Application Server ... practic este un limbaj de programare cu un framework si un model unic ce functioneaza peste internet. Mai multe informatii gasiti pe site-ul www.radgs.com. Aceasta ar fi compania pe care incerc (fara prea mult succes) sa o conduc.

Oricum, scopul blog-ului nu este acesta, ci ideea din spatele CAS (Concept Application Server). Este un proiect ce imi este foarte drag si e gratis! Este dezvoltat din pasiune si cu forte proprii. Am cautat cele mai bune solutii pentru tot ceea ce am facut: de la bibliotecile linux in licente LGPL pana la standardale Windows. Sper sa nu deschid iar o discutie "windows" vs. "linux". Ok. De aici "boemitatea" ... totul e facut din pura pasiune ... asa cum se intampla peste tot prin anii 80, cand formatiile rock cantau de placere, jucatorii jucau de placere iar banii si tot ceea ce este material parca nu insemna nimic. Din pacate, nu vreau sa fiu ipocrit si sa spun ca programam ... pe pietre colorate si scoici gaurite ... cu toate ca ar fi frumos ...

Prin anii 80, 2 gemeni, "The Oliver twins" au creat Dizzy ... poate unii din voi il mai stiu ... cei ce au apucat sa aiba un HC 91 sau un CIP. Era uimitor ce se putea face cu mai putin de 20 de cuvinte cheie si in mai putin de 48Ko de memorie. Oricum, sa revin ... cei doi gemeni au facut o gramada de lucruri extraordinare din pura pasiune si din pasiunea lor si-au luat Ferrari-uri ... este interesant, pentru ca scopul nu a fost "Ferrari" ... si a fost vorba de arta in adevaratul sens al cuvantului ... fara a alerga dupa profit.