Configurarea obiectelor GUI in Runtime

Terminand mai tot ce mi-am propus pentru zilele astea, mi-a trecut ceva prin cap: ce-ar fi daca am lasa un utilizator final al unei aplicatii Concept sa-si seteze anumite lucruri prin aplicatie, cum ar fi culoarea butoanelor sau poate chiar sa ascunda din campuri. Acum, totul e customizabil, asadar nu va putea edita absolut tot ce vrea el, ci va edita doar ce vrem noi. Ar trebui sa fie comod sa poata edita GUI-ul unei aplicatii Gyro in run-time ... ca pe wikipedia. Pentru asta am adaugat un control nou (de fapt l-am finalizat fiind un proiect abandonat acum cativa ani) - RPropertiesBox ce ne permite sa editam proprietatile unui obiect. Mai mult, am facut obiectul sa-si prezinte singur proprietatile folosind CApplication astfel: CApplication::DescribeObject(button1) ... iar asta ne returneaza toate informatiile despre proprietatile suportate. Apoi, folosind CApplication::ModifyObject(button1, "label") putem sa modificam proprietatile in RUN-TIME! Bun la debugging, bun la customizare. Atasez screen-ul de test.

Suport flash fara Adobe pentru Concept

Am reusit sa compilez Swfdec pe win32, cu toate ca inca mai am ceva probleme legate de sunet. Acum se poate include un swf foarte usor intr-o aplicatie Concept.


Si acelasi lucru pe Mac:


Am testat cateva jocuri, cateva filmulete. Nu merg chiar toate dar oricum, pentru cei ce doresc suport Flash complet, exista ActiveX-ul de la Adobe. Va functiona din pacate doar pe windows.

Inca o noapte de Craciun cu Concept !

Uptime 99.999% cu Concept Cluster

Am pus in kit-ul Concept Server un Load Balancer(CLB=Concept Load Balancer). E fara dependinte, astfel incat sa poate fi pus pe orice masina (ce nu trebuie sa aiba si Concept instalat). Consuma 24k ram/user conectat. Nucleul foloseste un weighted round-robin, asigurand incarcare simetrica si proportionala cu capacitatea serverelor din cluster. Practic fiecare server poate avea alt sistem de operare: putem defini un cluster cu un server windows, unul bsd si unul linux fara probleme, fara ca userul sa observe vreo diferenta. Pe langa asta, CLB este capabil sa se lege la noi servere fara shut down si poate detecta serverele offline (putand de exemplu, peste noapte sa inchid o parte din servere). E frumos ca dupa screenshot-urile acelea frumoase de pe OS X sa trantesc si o consola.


Sa-ti explic scenariul:
Avem initial 4 servere, din care 1 nu functioneaza (cel cu FAIL). Deschidem 16 instante de Concept IDE (sau orice alta aplicatie Concept). Dupa ce deschidem cateva, anuntam ca vrem sa scoatem unul din servere (cel marcat cu REMOVED). Acesta nu va fi inchis automat ci nu va mai primi conexiuni. Va putea fi scos din sistem atunci cand nu mai are nicio conexiune activa, astfel incat sa nu deranjam niciun user. In momentul in care conexiunile ii ajung la 0, atunci va pleca din cluster. Mecanismul este foarte simplu, pentru ca fiabilitate este invers proportionala cu complexitatea.
Mai mult, load balancer-urile pot fi legate unul de altul, ca si cum ar fi servere (ele din exterior vazandu-se ca un server Concept).

Concept pe OS X Leopard

Dupa o saptamana in care m-am chinuit sa inteleg OS X-ul, am reusit sa fac distributia Concept Client 1.1 pentru Mac OS X 10.4 sau mai mare. Am facut-o intr-o masina virtuala 10.5.2 si au testat-o cativa prieteni pe 10.5.7. Mai jos de 10.5.2 nu pot garanta nimic, dar teoretic ar trebui sa mearga pe orice mai mare de 10.4. Serverul inca nu este disponibil pe OS X dar se compileaza foarte usor, pentru cine vrea neaparat. Trebuie doar instalat Xcode si darwinports si modificate flag-urile din makefile-uri din -shared in -dynamiclib. Probabil ca voi face un installer si pentru server, dar nu stiu exact cand se va intampla asta. Daca totusi cineva vrea neaparat, imi poate cere explicit asta si asa as fi mai motivat.

N-am apucat sa va mai spun cum am redus consumul de memorie cu ... 70% pe server. Asta pentru carcotasii care tot vorbesc de concept:// vs http://. Acum, teoretic sistemul suporta cam acelasi numar de useri simultani. Exista acum un flag: UseSharedMemoryPool in concept.ini. By default, e setat la 1 (true), dar daca va crapa, il puteti pune la 0(false). Atunci cand are valoarea 1, toata zona de cod pentru o aplicatie se incarca intr-o zona de memorie partajata iar pentru fiecare user se vor incarca doar cateva informatii specifice acelei conexiuni (in loc de a incarca si codul pentru fiecare user in parte, cum se intampla cand flag-ul este 0). Asta + multe alte operatiuni au redus consumul de memorie drastic.

Atasez cateva screenshot-uri de pe OS X:

Concept 1.1 BETA

Munca multa in ultimul timp, in special pe partea de testare. S-au rezolvat toate bug-urile raportate pana acum (cu multe nopti nedormite). S-au implementat feature-uri noi precum suportul de Twitter (http://www.radgs.com/docs/help/Twitter.html).

Prin client, limita pentru filerequest a fost ridicata la ... infinit ... Din pacate inca exista limitar pe partea de primire de fisier, dar vor fi eliminate si acestea in curand.

Ma gandesc sa numesc cateva din persoanele ale caror idei se regasesc in GyroGears sau care au avut o cotributie majora in implementarea feature-urilor.
Dan Vasile - o gramada de bugfix-uri (nici nu mai stiu exact cate). Pe langa asta, a mai avut si multe idei
Doru Ilasi - editarea direct in view-uri. Nu a fost chiar ideea lui, dar m-a convins sa implementez asta in Gyro
Dan Craciun - semnaleaza si gaseste problemele cu UTF-8 pe Windows 7
Robert Shiplett - comentariile rautacioase, dar indreptatite despre o varianta "broken" de Concept strecurata in distributia oficiala. M-am invatat minte sa testez mai atent.
Emil Tereanu si Ruben Sainiuc - m-au scutit de zile intregi de a ma documenta despre ffmpeg si procesarea/conversia video
Vlad Nemes - cel care se uita ce se intampla prin lume si-mi zice si mie astfel incat sa ma ajute sa tin Gyro si Concept "in trend".

Am inceput sa paricip si pe la geekmeet-uri. Am avut feedback destul de interesant pana acum. Am fost in Cluj, Timisoara si Constanta. Trebuie sa recunosc ca cea mai "exotica" prezentare a fost cea de la Timisoara, unde cred ca voi merge de fiecare data cand voi avea ocazia. A fost poate prezentarea din care am invatat eu cel mai mult.

O sa tot amestec subiectele si voi vorbi si despre scrisoarea lui Monty. Circula pe internet un apel de a "salva MySQL"-ul venit chiar din partea creatorului acestuia. Cu riscul de a supara pe cineva voi spune:
- daca acest apel venea de la oricine altcineva, l-as fi sustinut. Atata timp cat vine de la cel care a vandut MySQL-ul, nu pot sa-l sustin. Este oarecum trist sa vinzi un produs iar apoi sa faci lobby pentru "salvarea lui". Nu as vrea sa folosesc cuvinte mai dure.
- din momentul vanzarii catre Sun, cred ca preluarea de catre Oracle putea fi anticipata. InnoDB a fost cumparat cu mult inaintea lui MySQL. Oare ce ar fi putut urma ?
- Oracle incearca sa creeze un monopol. Dar cred ca asta incearca orice companie ce se respecta, iar asta de cand lumea. Politica de monopol, vorbind "la rece", este cea mai sanatoasa pentru "practicant". Cand Monty isi incasa cecul, nu cauta acolo un raspuns afectiv ? Il respect foarte mult pentru ceea ce face si consider ca ar trebui sa se concentreze pe MariaDB lasand politica pentru politicieni. Sunt tare nerabdator sa incerc MariaDB.
Vezi BerkeleyDB, ce este acum tot in proprietatea Oracle... si a pornit tot ca open source.
- InnoDB+, un engine superior InnoDB e closed source! Iar asta este un lucru rau pentru ca ... ? Nu inteleg de ce trebuie sa fie totul open source. Sunt fan al open source-ului dar nu consider ca nu trebuie sa mai existe altceva in afara de open. Iar daca ne uitam cata politica e prin open source ... incep sa cred ca modelul closed e mai "liber".