care credeti ca e viitorul programarii (cu cine ati vota?)

[psycho too]

aaroman

Hai sa revenim de unde am plecat, la afirmatia ta plina de aroganta cu inspaimantatul.
DE CE crezi ca ne inspaimanta sa folosim delete sau free astora care am aflat ca mai exista si alte limbaje decat C/C++?

Pe tine te deranjeaza analogia (daca m-ai cunoaste ai sti ca sunt plin de exprimari plastice) pe care am facut-o si o consideri proasta, crede-ma, asa cum e ea proasta, reflecta foarte bine senzatia pe care tot acolo am prezentat-o, ceea ce tu nu ai cum sa contesti, oricat ai invarti din "bad analogy"-a la care tot faci trimitere.
Si am senzatia ca te ascunzi in spatele cuvintelor, cand e sa raspunzi la o provocare, lucru la care sunt sigur ca ar mai subscrie si altii de pe forum. PREA USOR ocolesti replicile care nu iti convin.
As avea o rugaminte, TE ROG sa raspunzi pe rand la replicile care ti se adreseaza direct, nu ca si cand ai manca seminte: pe asta o mananc, pe asta o ignor, pe asta numai o ling (bad analogy!), macar din bun simt fata de noi astia prosti. Asa bun cum esti, iti permiti sa joci si cinstit, nu?

Hai sa iti spun eu despre analogie.
O tot dai inainte cu ce cretini suntem noi ca programam in C# si Java vs. C/C++.
As vrea sa te intreb de ce programezi in C/C++?
Nu te simti limitat?
Pune mana si fa totul in ASM, doar se poate face in ASM orice se face in C/C++ si chiar mai mult!!

Te rog sa ma lamuresti de ce e mai rau cu GC decat cu delete. Ard de nerabdare! (Sper sa fi obiectiv!)

[KLAMATH]

Originally Posted by aLeXb

KLAMATH, in Java daca nu dai close() la anumite lucruri in mod cert o sa ai probleme. Cazul de care am amintit mai sus (cursoarele Oracle) este elocvent.

"Klamath, daca programul e foarte dinamic, si aloca resurse si le dealoca in mod repetat, daca nu faci Dispose si te lasi in grija GC-ului, o sa cam ai niste probleme, in special daca resursele alea sunt limitate. Pana se trezeste GC-ul, ai timp de injuraturi suculente la adresa Java."

aLeXb.....sa nu confundam close cu dispose. Sint 2 lucruri distincte. Close e folosit de anumite obiecte (de ex un stream sau o db connection). Cind tu deschizi unul din obiectele mai sus mentionate (care , repet, NU implementeaza IDisposable) esti constient ca asta trebuie "closed" dupa ce termini cu el.

Aaroman...vezi chestia de mai sus. In plus, dupa cite stiu eu, Java nu suporta un pattern (ca dispose in .net) pt "dealocarea/eliberarea" inainte de actiona GCul. Deci cind vorbesti de Dispose o sa presupun ca vorbesti despre .NET.
Hai sa luam un exemplu :

MyWickedDialog wdg = null;

try
{
wdg = new MyWickedDialog();
DialogResult drs = wdg.ShowDialog();
if(drs == DialogResult.OK)
{
//do stuff with it.
}

}
catch
{


}
finally
{
// if(wdg != null)
// {
// wdg.Dispose();
// }
}

Avem o System.Windows.Forms (care wrap un win32 handle). Codul din finally e comentat astfel ca fereastra nu e niciodata disposed. Poti sa creezi jde mii de ferestre fara sa le dispose niciodata (desi evident ca asta nu e recomandat...). La un moment dat GCul va kick in si va colecta gen0 disposing obiectele care sint garbage.
Acum, explica si mie, CONCRET cum " o sa cam ai niste probleme".

[Zircon]

KLAMATH, stiu asta. aaroman insa a folosit dispose() pentru a face in realitate close()

Java are finalize() dar metoda este apelata de catre GC. Din acest punct de vedere .NET este cava mai flexibil.

[Adi[CG]]

Originally Posted by KLAMATH

Adi[CG]Gindeste-te, de ex, la designul unui web service sau unui singleton in remoting...creezi clasa respectiva ca si cum ar avea numai metode statice si fiecare isi face treaba ei fara sa aiba tangente cu celelate. Iar toate luate impreuna reprez. "serviceul" tau. NU te apuci sa creezi properties, sa raise events & stuff. (ma rog...asta ar fi un caz ideal...ca se poate sa ai nevoie de asa ceva).

Yeeeeeah ... not !
Pai cazul stateless este intr-adevar cel mai banal DAR aplicatiile non-helloworld mai au si ceva persistenta in spate (sesiune pentru context de autorizare, cel mai bun si clasic exemplu). Asa ca desi aparent ai de-a face cu stoluri de metode disparate, de fapt exista niste corelatii foarte precise care trebuie urmarite pentru ca treaba sa mearga.

Originally Posted by KLAMATH

Pentru monitoring & stuff noi folosim direct perf counters din WinNT.

OK, asta e avantajul integrarii produselor MS cu sistemele de operare tot MS Good point. Dar, gandeste-te ca managerii vor si ei o idee despre business monitoring (dar sub forma "azi pe la ora 14 sistemul procesa 200 de cereri de creditare pe minut si durata uneia a ajuns la 17 secunde"). E un monitoring de nivel mai inalt care la care nu stiu daca perf counters ajuta foarte tare.

[KLAMATH]

Si legatura dintre coada vacii si stampila primariei fiind.....ahhhh....care ?!
Dude...vorbim de SOA aici. Daca tot ai adus ex cu authentification...eu
scriu un web service in .NET folosind WS Security. Tu il consumi folosind
implementarea BEA a J2EE (paranteza...stiu ca WebSphereul lu' IBM implementeaza
majoritatea/toate WS*urile. Care e situatia cu celelalte implementari J2EE la cap. asta?)
care , sa spunem, nu suporta WS Security (te apuci si-i dai cu soap extensions? .....ce legatura are asta cu persistenta ?!!!
Ce legatura are asta cu "contextul de autorizare" ?!!! Remember...SOA !!!!
In Indigo, de ex, eu pot consuma servicul tau prin IPC (folosid tcp pe loopback sau chiar
WM_DATA !!!!) Cum se leaga asta de ex tau ?! Dude...stateless rules**...eu vreau doar sa consum
un serviciu (ShowMeHowMuchIStillHaveToPayForRepairingTheCarMyWifeCrashed(string name) !! ). Ce legatura
are treaba asta cu "corelatiile" care fac ca serviciul expus de tine sa functioneze ?


**Ex cu autentificarea nu e cel mai bun. Poti folosi,de ex, auth chiar si ca parametri ai metodei care "reprezinta" serviceul.

[Adi[CG]]

Duuuude ...
Cred ca ai citit Indigo security introduction si plutesti pe un norisor pufos si cald. Prepare for worse, my friend. Sigur ca 'exista' WS Security, dar citeste matale ce spun ei "The following topics are outside the scope of this document: Establishing a security context or authentication mechanisms that require multiple exchanges." Ala va cadea tot (cel putin pe una din parti) in sarcina matale si tot sesiune se numeste si va necesita gestionarea de stari si de context. O sa zici ca se ocupa de asta Indigo server dar ntz! Si stii de ce ? Pentru ca orice integrare cu o aplicatie legacy e de fapt legata de o sesiune chioara, cu user/parola, care are sau nu are anumite drepturi (ca majoritatea aplicatiilor legacy sunt de fapt un client batranesc peste o bd relationala). Indiferent de cum vopsesti cioara ulterior ! Piata principala a SOA pana una-alta este legata de integrarea cu aplicatii legacy peste care se pune o pojghita de web service sau ce o oi vrea matale. Ca daca s-a adresa numai solutiilor noi ... multi ar muri de foame instantaneu.
Da, sigur, putem spune povesti cu Longhorn, ce frumos o sa fie Indigo, dar e interesant si sa ridicam coltul covorului ca sa ne uitam nitel acolo. Nu uita, Indigo n-o sa fie singur pe lume, ca o floare inmiresmata, comunicand Indigo cu Indigo si poate cu Indigo si eventual cu Indigo. Vei constata ca teoria cu everything stateless e un basm de indata ce vei incepe sa integrezi doua sau mai multe aplicatii cat de cat serioase. O sa scrii la plumbing de-o sa-ti vina acru. Experienta personala - si imi vine greu sa cred ca brusc lucrurile o sa se schimbe odata cu Longhorn. D'asta zic teoria e frumoasa si placuta, e bine s-o invatam din timp pentru ca dupa aia vom fi ocupati sa facem tot felul de tips&tricksuri imputite ca sa ne mearga aplicatiile.
Acu' sincer sa fiu ca tot m'ai intrebat de implementari in 2001-2002 cand am avut nevoie, WS-security era inca in gestatie, asa ca am scris un layer de autentificare 'proprietar'. Protocolul era similar kerberos :
- gigel apela prin soap o metoda in stil getChallengePhrase('gigel') si primea de la Server un challenge phrase criptat cu cheia lui publica
- gigel decripteaza challenge-ul folosind cheia privata, il recripteaza cu cheia privata a serverului si-l trimite inapoi, unde serverul reconstruieste fraza initiala. Daca se pupa, atunci challenge-ul ramane ca id de sesiune (uglyyyyy).
- dupa care toate mesajele SOAP era 'semnate' adica un camp continea semnatura payload-ului (toate celelalte campuri utile) si contineau evident id-ul de sesiune undeva intr-un campuletz + cateva din campurile "sensibile" cum ar fi numele sau adresa pacientului erau si ele criptate cu cheia publica a serverului.
Nu am folosit nici un container J2EE:
-pentru framework-ul de server Jakarta Avalon (de fapt o implementare care se numeste Phoenix)
-pentru SOAP am lucrat cu GLUE (acum la WebMethods) apoi cu Apache Axis (care mi s-a parut execrabil, dupa GLUE)
-pentru encryption am folosit BouncyCastle, care bate la fund cu putere pe Win32 Crypto API (fie si numai din cauza ca pe 98 o metoda din Crypto API face o chestie si pe XP o cu totul alta chestie nu am exemplul concret dar clientul a avut de furca vreo 2 zile fara sa stie cauza)

La 'cateva din capetele' firului stateau clienti C++ (Borland) care consumau serviciile web si pilotau [printr-un PC cu vreo 32 de interfete seriale multiplexate (arf arf !)] un ERP medical de pe o plarforma Wang. Nenea "legacy" de care vorbeam anterior si inca un reprezentant de seama ... e impresionant sa vezi monstrul functionand inca dupa 20 de ani, cand un laptop de acu' 5 ani deabia daca-l dau cu 2-3 sute de euro pe okazii.

Deci, ca sa revin, viata reala e mult mai 'interesanta' decat povestile de pe MSDN. Chiar daca se rezolva partea de autentificare si security, n-o sa fie totul transparent, fii sigur. O sa mai fie si ceva cod de scris, ceva arhitectura de rumegat...

[Adi[CG]]

precizez - in postul anterior era vb de o aplicatie Java

[Zircon]

Din multe puncte de vedere e mult mai convenabil sa folosesti legacy-ul ala vechi si urat decat sa treci totul pe o jucarie noua. Mie imi scot peri albi niste amarate de baze de date facute cu FileMaker-ul si astea sunt chiar simpliste in comparatie cu alte uratenii.

In alta ordine de idei, la ce performanta are Axis-ul (si nu numai, nici .NET nu straluceste) iti cam bagi picioarele in ele de web service-uri ...

[Adi[CG]]

Axis e cumplit, cu GLUE te mai descurci, dar evident ca nu o sa ajungi la zeci de tranzactii pe secunda nici in visele erotice.
Dar - cum Wang-ul proceseaza 2000 de dosare de pacienti pe zi, din care se spera ca 10-12% sa vina de pe net (adica vreo 200 pe zi, gaussian pe orarul unei zile de lucru, maxim ar veni cam 50-60 de dosare ora, ceea ce faci fluierand in orice limbaj vrei matale si cu cel mai lent API de SOAP de pe piata, mai ales pe un powerdell dual P3/1.4 cu 1G ram si 2 drive-uri wide ultra SCSI in RAID1). Dar : e mai rapid decat operatoarea de calculator care sta mai mult de un minut pe dosar si care oricum a fost data afara de indata ce sistemul informatic a inceput sa functioneze. Si la cat "costa" un job din asta in Belgia cu taxe si impozite cu tot, amortizarea aplicatiei va fi rapida (sorry pentru rata somajului dar asta e offtopic). In plus, capacitatea de procesare a sistemului a crescut, dovada ca prima oara in ultimii 5 ani a fost nevoie sa upgradeze Wang-ul (hard, memorie si capacitate de procesare, cred ca a costat mai mult decat tot rack-ul cu servere Dell pe care hostuiesc restul aplicatiilor "moderne" ). Am inteles ca au mai tras un upgrade pe Wang si anul asta, deci probabil treaba merge ...
Cu riscul de a ma repeta: criteriile de alegere a unei tehnologii in viata reala sunt un pic diferite fata de cele pe care noi tehnicienii le utilizam intre noi. Limbajul X care face Y sau Z este o chestie de care clientul nu ca nu este interesat, dar nici nu vrea sa auda pentru ca il plictiseste profund. Si de asta e bine sa mai scoatem un pic nasul din teorie si sa mai mirosim un client, un sediu real unde tanti secretara introduce date cu degetul aratator, o aplicatie Web in mediul ei natural si nu in reteaua locala.
pe canalul Discovery Customers In The Wild

[aaroman]

In plus, dupa cite stiu eu, Java nu suporta un pattern (ca dispose in .net) pt "dealocarea/eliberarea" inainte de actiona GCul.

Yeap. Nu suporta. My fault. Trebuia sa fiu mai atent. Fiind vorba de doua limbaje din acceasi familie, ceea ce am spus se aplica si la C#, si la Java. E vorba de Close, la anumite clase preexistente, si posibil o alta metoda, numita oricum la clasele definite de programatori.

Avem o System.Windows.Forms (care wrap un win32 handle). Codul din finally e comentat astfel ca fereastra nu e niciodata disposed. Poti sa creezi jde mii de ferestre fara sa le dispose niciodata (desi evident ca asta nu e recomandat...). La un moment dat GCul va kick in si va colecta gen0 disposing obiectele care sint garbage.
Acum, explica si mie, CONCRET cum " o sa cam ai niste probleme".

Incearca cu niste resurse mai limitate. De ce nu incerci cu o sectiune critica? Pana da GC-ul kick toate threadurile vor fi blocate
Cand am o aplicatie multithreading, si am ceva de accesat care-i accesat de mai multe threaduri, pur si simplu fac ceva in genul asta:
{
CLockCriticalSection lock(m_section);
//etc
}
Si gata. Bineinteles, unele limbaje au suport in alt fel pentru sincronizarea threadurilor. Am dat examplul asta doar ca un exemplu concret de resursa limitata. Pot sa fie socket-uri (incearca cu socketuri pentru acelasi port ), pot sa fie fisiere (poate sa fie un singur fisier pe care-l deschizi exclusiv, pana nu da GC-ul iama prin memorie, nu-l mai deschizi, daca nu-l inchizi explicit), poate sa fie un port serial, etc...
In cazul Java & C#, daca ai asemenea clase, trebuie sa realizezi explicit eliberarea resurselor, si asta nu-i exact placut, practic e cam acelasi lucru cu free/delete, numai ca-i alta sintaxa. In C++ mai ai varianta smart pointerilor, sa eviti delete, sau obiecte de tip "sentry", pentru alte resurse...
In C# & Java, daca ai mai multe puncte de return, trebuie sa ai grija ca resursa sa fie eliberata peste tot. Daca se mai pot arunca si exceptii, trebuie sa scrii explicit try/catch/finally (si in finally sa eliberezi resursa), doar din cauza asta. In C++ nu trebuie sa faci nimic. Nici macar nu trebuie sa ai un try acolo, daca nu vrei sa prinzi exceptiile la nivelul ala.
Metoda asta e atat de folositoare, ca aia de la boost au facut smart pointerii in asa fel incat sa poata sa apeleze un delete "custom". Ala poate fi si fclose, de exemplu. Exista niste avantaje deloc de neglijat daca stii cand sunt eliberate obiectele.

Nenea "legacy" de care vorbeam anterior si inca un reprezentant de seama ... e impresionant sa vezi monstrul functionand inca dupa 20 de ani, cand un laptop de acu' 5 ani deabia daca-l dau cu 2-3 sute de euro pe okazii.

LOL Va fi interesant de vazut daca aplicatii Java sau mai ales C# vor functiona tot asa peste 20 de ani
Tiand cont de faptul ca cele doua se schimba mai des decat ciorapii unora, peste 20 de ani va fi greu de gasit VM-ul si/sau OSul potrivit sa ruleze o anumita aplicatie

Si apropo de schimbari, nici bine n-au auzit unii de .net forms, ca iata:
http://msdn.microsoft.com/longhorn/d...iglongch05.asp

[Adi[CG]]

Originally Posted by aaroman

Va fi interesant de vazut daca aplicatii Java sau mai ales C# vor functiona tot asa peste 20 de ani

FYI ... pe mini-urile Wang se foloseste Cobol iar datele sunt stocate in fisiere ISAM.
Comparat cu asta pana si C++ cu templates este o tehnologie tanara, ne-experimentata

[aaroman]

FYI de asemenea se foloseste o gramada si Fortran.
C++-ul si-a dovedit deja capacitatile comparativ cu Fortran-ul (nu degeaba tot am dat exemple de librarii C++ care se folosesc la calcule cu volum mare de date), din moment ce s-au reimplementat librarii in C++ pentru a inlocui vechile librarii in Fortran, tehnologii experimentate timp de zeci de ani . Si aici nu-i vorba de aplicatia secretarei care introduce cu un deget, aici e vorba de aplicatiile celui mai mare centru de cercetare in fizica particulelor din lume. Nu e vorba de o baza de date de cativa GBytes, e vorba de 10 TBytes la o singura rulare.
Chiar daca e o tehnologie "tanara si neexperimentata" (C-ul care e un subset al C++-ului nu e chiar asa de tanar - si e folosit la o mare majoritate a implementarilor sistemelor de operare, bazelor de date, implementari CORBA, si lista continua la nesfarsit - bineinteles, acolo unde nu e C++, chiar si C++-ul are o lista foarte lunga ), nu e neverificata. Tehnologie tanara nu e, comparativ cu altele, iar despre exeperimentare, timpul redus a fost compensat de numarul mare de aplicatii implementate in C++.

Evolutia C++-ului nu a fost "evolutie" de tipul C# sau Java, cu aparitie peste noapte prin trunchierea unui limbaj existent (dimpotriva, a fost extins un limbaj existent), shimbarile de standarde nu s-au realizat in fiecare an cate una.
Desi are niste minusuri (n-ar strica finally si closures, de exemplu, si mi-ar place ca multe lucruri din boost sa ajunga in standard) stiu ca indivizii care se ocupa de standard vor sa le rezolve, si in mod cert nu sunt minusurile din celelalte limbaje (nu degeaba tot le complica de la o versiune la alta, mai adaugand cate o chestie din C++ - ba template-uri, ba ala cu Java incepe sa recunoasca supraincarcarea operatorilor ca fiind o chestie buna - parca-i vad ca adauga si asta la java , dupa ce la inceput spunea ca e evil ).
Eu personal prefer schimbarile gandite cu atentie, nu alea conduse de moda si piata, mai frecvente decat salariile lui Bill (asta apropo de inlocuirea win forms cu avalon, la renuntarea la "standardele" rdo & dao, and so on).

[Adi[CG]]

dunno, discutia era apropo de Wangul baietilor din Belgia...
altfel, parerile tale apropo de C++ le stiu de mult
sanatate

[KLAMATH]

Muhahahhahahaahahha.....
"Vei constata ca teoria cu everything stateless e un basm de indata ce vei incepe sa integrezi
doua sau mai multe aplicatii cat de cat serioase. O sa scrii la plumbing de-o sa-ti vina acru."

I did. Anul trecut am "integrat" o balarie legacy scrisa in VB6 cu Winsock controls. TOTUL
era "stateless". Singurele probleme am avut doar cu bugurile din VB6 winsock control.
Ma enerveaza ca o dai in balarii la modul cel mai jenant. O sa repet....aici vorbim de SOA.
Tu expui un serviciu si eu il consum IN CE MOD vreau eu si CUM VREAU eu. Aici NU vorbim
de web services (ce legatura are ex. tau web services cu SOA ? Sau ar fi trebuit sa dea
mai multa "greutate" afirmatiei "plutesti pe un norisor pufos si cald" !! Un CV nu pui aici ?
Ca sa discutam pe chestii concrete....). Dar sa revenim....ai dat exemplul cu HttpContext session..
Duuuuuuuuuuuuude...SOA...eu vreau sa consum "servicul" tau folosind a fast l33t UDP socket. Pai si ce facem
in cazul asta cu HttpContext ? Nu se poate...pai ce SOA e asta "fratzie" ? Nu se poate sa-l consum
nici prin IPC ? Hmm...adica tu ai un web service chior si-mi "vinzi" mie SOA ?!
Repet...chestia pe care se pare ca NU o intelegi tu e ca SOA ESTE STATELESS !!!!!!!
"Sesiune de autentificare" !!! Muhahaha...eu vreau doar RPC over "ce vrea muschii mei".
Eu vreau sa folosesc UDP sockets ca sa consum serviciul tau...ce ma intereseaza
pe mine de sesiunea ta de autentificare. Eu ma autentific doar pentru a chema metoda
GetMyStuffs(string user, string parola, int stuffsID). ATIT.
Alta chestie....tu pari a avea impresia ca eu nu fac altceva toata ziua
decit sa frec managanu pe MSDN in timp ce tu esti singurul care "write real life shit".
Te asigur ca si eu "scriu cod si rumeg arhitectura" zi de zi....Deci scuteste-ma, te rog,
cu "plutesti pe un norisor pufos si cald".
Indigo and "...bring your old shit to Indigo" http://longhorn.msdn.microsoft.com/portal_nav.htm


Aaroman...dude get a fucking clue. And stop FUDing.

"Pot sa fie socket-uri (incearca cu socketuri pentru acelasi port ),
pot sa fie fisiere (poate sa fie un singur fisier pe care-l deschizi
exclusiv, pana nu da GC-ul iama prin memorie, nu-l mai deschizi,
daca nu-l inchizi explicit), poate sa fie un port serial, etc..."

Ce pielea caprei din padure are mah de-a face un socket || stream cu
patternul IDisposable !!! Clasele System.IO.Stream si System.Net.Sockets.Socket
NU sint "disposable". Cind creezi unul din typesurile de mai sus
esti constient ca asta TREBUIE inchise (aka .Close != Dispose != stupid project wide convension) cit mai repede si
ca NU iti permiti sa le lasi deschise pina la urmatoarul GC.Collect();



"In cazul Java & C#, daca ai asemenea clase, trebuie sa realizezi explicit eliberarea resurselor,
si asta nu-i exact placut, practic e cam acelasi lucru cu free/delete, numai ca-i alta sintaxa".
FUD machine ....discutia asta e in contextul objectelor care wrap OS resources
si pe care GCul nu stie sa le colecteze. I sa sarim gardul si sa folosim
managed types...care nu trebuiesc .close, .dispose and stuff. Putem folosi obj si ...are GCul
grija. In CPP...uitam delete si ne-am facut cu (inca un) memory leak.

"Incearca cu niste resurse mai limitate. De ce nu incerci cu o sectiune critica?
Pana da GC-ul kick toate threadurile vor fi blocate"
CGC. In plus CLR "hijack" threadurile ce au ajuns intr-un "safe point".



WinForms nu e inlocuit cu Avalon (si nu incerca magaria asta...AWT, Swing, SWT, GTK, QT,
wxWindows, *stupid toolkit that nobody heard of.."). E intotdeauna bine sa
creezi un nou API (pt UI) decit sa incerci sa "infigi" chestiile noi deasupra celui vechi.
Si avind in vedere cite diferente vor fi intre Avalon si WindowsForms....
In plus ideea e ca cu WinForms o sa scrii pt toate Vindozele de pina acum. (98 and higher).
Cu Avalon o sa scrii doar pt Longhorn. Mult mai bine sa fii 2 chestii distincte.
Nu te opreste nimeni sa folosesti RDO si DAO. Problema ta e ca lucrurile evolueaza si
tu nu esti in stare sa keep up....

Vezi ca te-a intrebat psycho ceva.....

(c) sictirit.

[Adi[CG]]

Originally Posted by KLAMATH

Aici NU vorbim de web services (ce legatura are ex. tau web services cu SOA ? Sau ar fi trebuit sa dea mai multa "greutate" afirmatiei "plutesti pe un norisor pufos si cald" !!

Pentru ca toata experianta mea SOA-related de pana acum e legata de web services si pentru ca web services sunt "la moda" la ora actuala. Cam toate articolele care trateaza SOA au si ceva povesti de web services. Atat. Nu am negat ca SOA ar trebui sa fie independent de modalitatea in care expui/consumi serviciile, am dat doar un mic exemplu concret, real-life.

Originally Posted by KLAMATH

Un CV nu pui aici ?

Nu vad la ce mi-ar folosi.

Originally Posted by KLAMATH

Duuuuuuuuuuuuude...SOA...eu vreau sa consum "servicul" tau folosind a fast l33t UDP socket. Pai si ce facem

Repet, era vorba de SOAP, NU de http. Transportul pentru un web service se poate face pe ce protocoale vrei matale. Si nu a fost nici o secunda vorba de HttpContext, care NU imi rezolva problema cf caietului de sarcini. Mai citeste o data, te rog, si dupa aia mai vorbim.

Originally Posted by KLAMATH

Eu vreau sa folosesc UDP sockets ca sa consum serviciul tau...ce ma intereseaza pe mine de sesiunea ta de autentificare. Eu ma autentific doar pentru a chema metoda
GetMyStuffs(string user, string parola, int stuffsID). ATIT.

Cred ca vorbim de chestii diferite. Nimeni nu a negat ca esti capabil sa exporti un serviciu in ce tehnologie vrei tu. Am dat doar un exemplu (poate ceva mai complex) si absolut real de tricks-uri la care a trebuit sa recurg intr-un proiect mai vechi. Tocmai din natura (teoretic) stateless a unui serviciu, pusa peste contexte cat se poate de stateful, apare nevoia de orchestrare. THAT was my point.
Anyway, getmystuffs cu user si parola in clar este pure bullshit pentru orice aplicatie ce necesita un nivel de securitate decent. Nu cred ca trebuie sa-ti explic de ce...

Originally Posted by KLAMATH

Alta chestie....tu pari a avea impresia ca eu nu fac altceva toata ziua decit sa frec managanu pe MSDN in timp ce tu esti singurul care "write real life shit".
Te asigur ca si eu "scriu cod si rumeg arhitectura" zi de zi....Deci scuteste-ma, te rog,
cu "plutesti pe un norisor pufos si cald".

Nu am deloc aceasta impresie. Am dat doar un exemplu din experienta personala, ca nu era sa dau din experienta ta. Asteptam poate ceva mai concret de la tine decat niste glumite ieftine dar, ma rog, asta-i marfa cu asta dansam. Pana una-alta Indigo e vaporware, Indigo e alpha, nu am negat ca nu trebuie sa invatam sa-l strunim, dar proiectele care se fac ACUM sunt in tehnologiile care tu sustii ca nu conteaza si folosesc (ca sa te citez) "stupid toolkits that nobody heard of..". Pe stupid toolkit-uri din astea fac eu bani bunicei de ani de zile. Poate-o fi o piata de nisa si nu m-am prins, dar ma lamuresc eu pana in 2008 cand iese Waithor^H^H^H^H^H^H^HLonghorn.

Originally Posted by KLAMATH

Aaroman...dude get a fucking clue. And stop FUDing.

Round and round we go again ...

[KLAMATH]

Originally Posted by aLeXb

La .NET in general injuram Visual Studio-ul.
Si btw, Eclipse da clasa Visual Studio minus editorul vizual. La memorie/viteza e mai trist dar nu insuportabil.

Editorul ala ASP.NET/Html din VS.NET e mai slabutz comparat cu chestii gen Dreamweaver. Dar in rest ? Ce ti se pare atit de "tare" la Eclipse de spui ca ii da clasa VS.NETului ?!. Code editorul Vs.NETului mi se pare a fi de departe cel mai tare dintre toate IDEurile cunoscute de mine (singurul care se apropie e InteliiJ IDEA). GUI Builderul ala din Eclipse nu l-am incercat nicodata deci n-am cum sa-l compar cu ce e in VS.NET..
Sper ca nu incepi cu ...n-are refractoring out of the box and stuffs. Cine cauta gaseste ..
In plus la capitolul viteza Eclipse e "eclipsat" rau de VS.NET....

[Adi[CG]]

1. VS Net n-are refactoring out of the box
2. Plugins, plugins, plugins... Si nu numai scrise de altii, dar cu gheara personala ca sa automatizez vrute si nevrute prin proiecte
3. N-are GUI builder integrat, deocamdata, dar exista un plugin payware swt-designer care RUPE

... Ar mai fi suportul Ant pe care VS deabia incepe sa-l miroasa cu NAnt-ul, Rich Client Platform care nu prea are echivalent in lumea MSFT (poate si pentru ca nu a existat o nevoie pregnanta, but anyway), suportul serios pentru AOP (altfel, concept inventat de un ex-Microsoftist) si faptul ca este intr-adevar un IDE nascut din necesitatile dezvoltatorilor. Si nu e bullshit. Este un produs la care ai acces liber la nightly builds + cateva integration builds pe luna, la care ORICINE poate semnala bug-uri, cere noi features sau sugera ameliorari. Compara asta cu procesul de dezvoltare la VS.Net ("we MSFT develop, you people swallow") plus obiceiul MSFT de a arunca down the drain suport pentru diverse tehnologii in care o groaza de oameni au investit timp de invatare : VB si in curand COM.

Da, sigur ca e mai lent. Si XP-ul e mai lent decat 98-ul. So ? Atata vreme cat se poate lucra pe el in mod decent si nu trebuie sa-mi fac o cafea in timpul unui build cycle, merge.

[aaroman]

Ce pielea caprei din padure are mah de-a face un socket || stream cu
patternul IDisposable !!!

Nici una, decat in mintea ta. A fost o greseala de-a mea initial, pe care am rectificat-o, dar tu n-ai observat asta (sau te faci ca nu observi, si continui pe aceeasi placa).

Clasele System.IO.Stream si System.Net.Sockets.Socket
NU sint "disposable". Cind creezi unul din typesurile de mai sus
esti constient ca asta TREBUIE inchise

La fel si in C++, daca aloci memorie esti constient ca TREBUIE eliberata (daca trebuie ). Tot n-ai sesizat paralela?

(aka .Close != Dispose != stupid project wide convension)

Yeap. Si?

cit mai repede si
ca NU iti permiti sa le lasi deschise pina la urmatoarul GC.Collect();

Nu? Pai cum, GC-ul nu face minunile atat de laudate de fiecare, anume de a scuti programatorii de eliberarea explicita a resurselor? Un smart pointer face acest lucru cat se poate de elegant, daca eliberarea resurselor e facuta in destructorul obiectului. Adica nu mai e necesar sa scrii acel Close in nu stiu cate locuri unde exista return, si sa scrii explicit try/catch samd, daca chiar n-ai nevoie sa prinzi exceptiile in portiunea respectiva de cod.

In CPP...uitam delete si ne-am facut cu (inca un) memory leak.

Nu, in CPP folosim smart pointeri si nu ne facem nici cu memory leaks, nici nu trebuie sa apelam explicit Close...

E intotdeauna bine sa
creezi un nou API (pt UI) decit sa incerci sa "infigi" chestiile noi deasupra celui vechi.

E valabil conceptul asta intotdeuna? Cateodata extinderea interfetelor (aka derivarea din clasele existente) e mai buna decat crearea de clase noi. Chiar n-ai auzit de reutilizare, compatibilitate, and so on?

Nu te opreste nimeni sa folosesti RDO si DAO.

Nu?

Problema ta e ca lucrurile evolueaza si
tu nu esti in stare sa keep up....

Voi fi intotdeauna in stare sa "keep up". Asta nu inseamna ca trebuie sa-mi placa cum "evolueaza" lucrurile.

stupid toolkit that nobody heard of

Daca tu n-ai auzit, nimeni n-a auzit? De unde generalizarea asta?

[KLAMATH]

"Pentru ca toata experianta mea SOA-related de pana acum e legata de web services si pentru ca web services
sunt "la moda" la ora actuala. Cam toate articolele care trateaza SOA au si ceva povesti de web services.
Atat. Nu am negat ca SOA ar trebui sa fie independent de modalitatea in care expui/consumi serviciile,
am dat doar un mic exemplu concret, real-life."

Then make up your mind.
Ori discutam de SOA ori despre web services !!
SOA != ws. SOA ar vrea sa fie un "superset"
al webservicesurilor. Daca wsurile au adus interop
intre "sisteme" folosind wsdl, http si soap, SOA ar trebui
sa faca acest lucru la o scara mai mare permitindu-ti sa
alegi tu "protocolul de transport" si modul in care
datele sint "transmise".Insa..well..ideea e... CU CE ajuta discutiei
despre SOA exemplul tau cu webserviceurile ?
Ar ajuta daca as scrie si eu din amintirile mele....
cind foloseam DCOM (yeah...Windows DNA ) in
distributed apps ?


"Repet, era vorba de SOAP, NU de http. Transportul pentru un web service se poate face pe ce protocoale
vrei matale. Si nu a fost nici o secunda vorba de HttpContext, care NU imi rezolva problema cf
caietului de sarcini. Mai citeste o data, te rog, si dupa aia mai vorbim."

"Pai cazul stateless este intr-adevar cel mai banal
DAR aplicatiile non-helloworld mai au si ceva persistenta
in spate (sesiune pentru context de autorizare, cel mai bun si clasic exemplu)".

Corect. SOAP e independent de protocolul de transport. (ai putea sa
ai o implementare ca sa foloseasca ...porumbei (http://www.webreference.com/authorin...vices/chap3/3/).
Dar sa zicem ca avem o implementare care foloseste UDP sockets.
In acest caz ce inseamna pentru tine "context de autorizare" ?
Si, tinind seama ca ai putea avea SOAP over *whatever* si ca,
in cazul in care *whatever* nu are context (udp sockets),
cum rezolvi tu problema fara a face totul stateless ?
Exemplu concret...ai un web service la care trebuie sa existe autentification.
WSul urmeaza sa fie folosit de un numar FOARTE mare de utilizatori asa ca RBS
e exclus. Cum faci autentificarea ?


"Nu am deloc aceasta impresie. Am dat doar un exemplu din experienta personala,
ca nu era sa dau din experienta ta. Asteptam poate ceva mai concret de la tine
decat niste glumite ieftine dar, ma rog, asta-i marfa cu asta dansam.
Pana una-alta Indigo e vaporware, Indigo e alpha, nu am negat ca nu trebuie sa
invatam sa-l strunim, dar proiectele care se fac ACUM sunt in tehnologiile care
tu sustii ca nu conteaza si folosesc (ca sa te citez) "stupid toolkits that nobody
heard of..". Pe stupid toolkit-uri din astea fac eu bani bunicei de ani de zile.
Poate-o fi o piata de nisa si nu m-am prins, dar ma lamuresc eu pana in 2008 cand
iese Waithor^H^H^H^H^H^H^HLonghorn."

Deci toata discutia era despre SOA/viitor (btw legat de Indigo si alpha...mda..macar
in .NET exista Indigo care va face SOA o realitate. In J2EE ce exista ?). In mijlocul
acestei discutii , repet...despre SOA si viitor, tu te apuci sa dansezi cu tehnologiile (din prezent...yeah..ws rulezz..right ?!)
despre care eu sustin ca nu conteaza. Mda...eu am spus ca Shadowfax NU conteaza. Folosesti Shadowfax AZI ?
Ai luat din context chestia cu "stupid toolkits that nobody
heard of.."(SPUNE-MI ca ai inteles la ce ma refeream cind am scris asta !!!!) si
apoi refulezi cu Longhorn. Congratz dude...ce sa zic. M-ai spart.


AAaroman.


"La fel si in C++, daca aloci memorie esti constient ca TREBUIE eliberata (daca trebuie ). Tot n-ai sesizat paralela?"
Exact...si in CLR/JVM de asta se ocupa GCul. Nu ai sesizat asta pina acum ?


"Pai cum, GC-ul nu face minunile atat de laudate de fiecare, anume de a scuti programatorii de eliberarea explicita a resurselor?"
Evident ca le face. Ideea era, de ex daca deschizi o conexiune de o baza de date sau un stream,
sa nu astepti, in acest caz, sa-ti inchida GCul conexiunea ci sa o faci chiar tu. Closeul il pui in finally.


"Nu, in CPP folosim smart pointeri si nu ne facem nici cu memory leaks, nici nu trebuie sa apelam explicit Close..."
Hehehe...si daca obj nu e declarat la nivelul clasei.Daca, de ex, ai Clasa X cu metoda Y. In metoda Y deschizi un stream. Nu trebuie sa chemi close ianinte
de return ?


"E valabil conceptul asta intotdeuna? Cateodata extinderea interfetelor (aka derivarea din clasele existente) e mai buna decat crearea de clase noi. Chiar n-ai auzit de reutilizare, compatibilitate, and so on?"

Dude aici e vorba de tot UI APIul Windowsului. De ce, de ex, Swingul nu extinde AWTului ? Sau SWTul Swingul ?!
E vorba de 2 chestii distincte cu mari diferente intre ele care au acelasi scop. DE CE ai vrea
ca al 2 sa fie on top la primul ? Bloat blaot bloat bloat... Ai nevoie de WinForms...folosesti win forms.
Ai nevoie de Longhorn only UI folosesti Avalon. "It's that simple."
Dar, desigur, nu ma indoiesc ca tu stii mai bine decit tipii de la MS care au luat
hotarirea asta...


"Voi fi intotdeauna in stare sa "keep up". Asta nu inseamna ca trebuie sa-mi placa cum "evolueaza" lucrurile."
OK...atunci....ce nu iti place la modul in care au evoluat ADO/ADO.NET din RDO/DAO?


"stupid toolkit that nobody heard of. Daca tu n-ai auzit, nimeni n-a auzit? De unde generalizarea asta."
*out of context.Core dumped*.

(c) Next

[KLAMATH]

Originally Posted by Adi[CG]

1. VS Net n-are refactoring out of the box
2. Plugins, plugins, plugins... Si nu numai scrise de altii, dar cu gheara personala ca sa automatizez vrute si nevrute prin proiecte
3. N-are GUI builder integrat, deocamdata, dar exista un plugin payware swt-designer care RUPE".

1. Atita timp cit are....
2. Addins, addins, addins. Si pe deasupra si macrouri. Tot cu gheara din dotare.
3. Eh...atita timp cit e "payware".

Desigur ca nu te poti abtine....

"