Jump to content

SUBIECTE NOI
« 1 / 5 »
RSS
Incalzire casa fara gaz/lemne

Incalzire in pardoseala etapizata

Suprataxa card energie?!

Cum era nivelul de trai cam din a...
 probleme cu ochelarii

Impozite pe proprietati de anul v...

teava rezistenta panou apa calda

Acces in Curte din Drum National
 Sub mobila de bucatarie si sub fr...

Rezultat RMN

Numar circuite IPAT si prindere t...

Pareri brgimportchina.ro - teapa ...
 Lucruri inaintea vremurilor lor

Discuții despre TVR Sport HD.

Cost abonament clinica privata

Tremura toata, dar nu de la ro...
 

Servlet Java EE

- - - - -
  • Please log in to reply
23 replies to this topic

#1
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017

 Mosotti, on 15 martie 2017 - 15:23, said:

Depinde de citi oameni vrei sa ai. Poti sa ai 20 mediocri, unde nu conteaza cine pleaca,
Sau poti sa ai 20 beton si nimeni nu se supara ca vine altcineva sau pleaca.

Quote

sau poti sa ai 5 beton, care sa poate face oricare orice, iar cind pleaca unul, se simte zdravan.
Pai daca se simte zdravan cand pleaca unul atunci inseamna ca in realitate compania este praf de creta.

Quote

Agile nu rezolva problema plecarilor frecvente din companie cind e vorba de un proiect masiv la care vrei sa ai cit mai putini oameni si deci cit mai mare profit :w00t:
Noi mergem pe filosofia ca trebuie sa avem atati developeri cat proiectul necesita , astfel incat  sarcinile sa fie egal distribuite dupa competentele lor.Asta facem noi prin Agile.Ne asiguram ca fiecare
developer nu are nici un plus dar nici in minus taskuri, ci acele taskuri sunt exact pe masura priceperii lor.Astfel Agile ne asigura distributivitatea efortului in echipa.

Quote

Intrebarea ta e prea vaga pentru mine, servletul e controller, business logicul e separat si ar trebui apelat de controller, habar n-am ce vrei sa spui "dpdv al business logicului". Sau la voi, la profesionistii de talie mondiala, se face business logicul in servleturi? :lol:
Este de inteles ,ca din moment ce nu stii partea de baza  a stivei de tehnologii JAVAEE, respectiv JSP/Servlets/JSTL/EL  sa incerci sa reduci functionalitatea servletului la un simplu controller dintr-unde MVC framework.

Quote

Oricum, dpdv al profesionistilor, nu invoci nici un servlet, folosesti in framework :w00t:
Iar un framework este format din servleti.Mai bine zis o colectie dinamica, bine organizata de servleti care pot fi inlantuiti si rearanjati in liste de executie astfel incat acestia sa
formeze noi cai  de executie si noi fluxuri de date in functie de dorintele developerului.Iar inlantuirea servletilor se face prin RequestDispatcher apelat prin clauza "include" sau prin clauza "forward".
Daca vrei de exemplu ca un servlet sa astepte dupa alt servlet sau dupa o colectie de servleti , atunci folosesti clauza "include" a RequestDispatcherului, daca vrei sa rutezi sau sa deleghezi actiunea unui
servlet catre alt servlet sau catre alta componenta (filtru/etc) atunci folosesti clauza "forward".
Intr-un framework path-urile intre servleti le creezi fie prin mapaare in fisier XML, fie prin annotari.

Deci ca o mica concluzie, tu de fapt spui (fara sa-ti dai seama) urmatoarea chestie:
Oricum, dpdv al profesionistilor, nu invoci nici un servlet, folosesti in framework (care este o colectie organizata de servleti)
Betooon, acum incepem sa ajungem la un numitor comun.
De aceea daca stii baza JAVA EE, atunci folosirea unui framework este foarte usoara.
Insa daca nu cunostii baza JAVA EE , atunci folosirea unui framework iti creaza un handicap in sensul ca te face prizonier al acelui framework iar
fara existenta frameworkului tu nu mai intelegi ce trebuie sa faci cu un request in conditiile in care ai lib-ul standard de JAVA EE in fatza ochilor
Sa stii ca orice liceean se descurca si fara programare intr-un mvc framework, urmarind indicatiile de pe video tutoriale de pe youtube.
Isi mai are rostul intrebarea "parametrii de request si atribute de sesiune ? " Nope, din moment ce pentru noi servleti sunt o mare necunoscuta.
Noi si astia de aici  http://education.ora...params=p_id:188, suntem cam nebuni,si avem prea mult timp liber
din moment ce ne dedicam atata timp tehnologiilor  de baza ale JAVA EE.

Quote

pentru ca Java nu inseamna doar Java EE
Pai JAVA EE inclue JAVA SE. Cand vorbim de mediul corporate, pentru java spunem JAVA EE.Iar cunoasterea de baza a tehnologiilor JAVA EE este
obligatorie: JSP/Servlets/JSTL/EL

#2
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004

 lightpoint, on 16 martie 2017 - 11:39, said:

Sau poti sa ai 20 beton si nimeni nu se supara ca vine altcineva sau pleaca.
Yeah, right, 20 de oameni beton, noi ne limitam la 5, asa, mai necunoscatori Posted Image

 lightpoint, on 16 martie 2017 - 11:39, said:

Pai daca se simte zdravan cand pleaca unul atunci inseamna ca in realitate compania este praf de creta.
Nu, inseamna ca proiectul este foarte complex si extrem de masiv si echipa restrinsa este formata din oameni foarte capabili si foarte greu de inlocuit. Problema nu este nivelul de programator in asemenea proiecte, ci cunoasterea proiectului in sine si a cerintelor de business. Sigur ca asemenea lucruri nu se pot explica unuia care n-a avut parte de asa ceva, tre sa vezi ca sa crezi Posted Image

Ca sa pricepi mai bine, intr-un asemenea proiect si daca vine cel mai tare programator din univers, tot se uita ca boul la poarta noua si dureaza luni bune pina se prinde cum merge treaba.

Quote

Noi mergem pe filosofia ca trebuie sa avem atati developeri cat proiectul necesita , astfel incat  sarcinile sa fie egal distribuite dupa competentele lor.Asta facem noi prin Agile.Ne asiguram ca fiecare
developer nu are nici un plus dar nici in minus taskuri, ci acele taskuri sunt exact pe masura priceperii lor.Astfel Agile ne asigura distributivitatea efortului in echipa.
Si la noi e Agile, dar nu este loc de incepatori si de habarnisti care nu sint in stare sa faca macar o parsare de parametri, indiferent cita experienta exista pe hirtie si cite certificari au. Ma intreb ce dracu fac aia la joburile actuale, ce fel de task-uri de trei banane primesc de reusesc sa le si faca Posted Image

 lightpoint, on 16 martie 2017 - 11:39, said:

Este de inteles ,ca din moment ce nu stii partea de baza  a stivei de tehnologii JAVAEE, respectiv JSP/Servlets/JSTL/EL  sa incerci sa reduci functionalitatea servletului la un simplu controller dintr-unde MVC framework.
Iar un framework este format din servleti.Mai bine zis o colectie dinamica, bine organizata de servleti care pot fi inlantuiti si rearanjati in liste de executie astfel incat acestia sa
formeze noi cai  de executie si noi fluxuri de date in functie de dorintele developerului.Iar inlantuirea servletilor se face prin RequestDispatcher apelat prin clauza "include" sau prin clauza "forward".
Daca vrei de exemplu ca un servlet sa astepte dupa alt servlet sau dupa o colectie de servleti , atunci folosesti clauza "include" a RequestDispatcherului, daca vrei sa rutezi sau sa deleghezi actiunea unui
servlet catre alt servlet sau catre alta componenta (filtru/etc) atunci folosesti clauza "forward".
Intr-un framework path-urile intre servleti le creezi fie prin mapaare in fisier XML, fie prin annotari.
Deci ca o mica concluzie, tu de fapt spui (fara sa-ti dai seama) urmatoarea chestie:
Oricum, dpdv al profesionistilor, nu invoci nici un servlet, folosesti in framework (care este o colectie organizata de servleti)
Betooon, acum incepem sa ajungem la un numitor comun.
De aceea daca stii baza JAVA EE, atunci folosirea unui framework este foarte usoara.
Insa daca nu cunostii baza JAVA EE , atunci folosirea unui framework iti creaza un handicap in sensul ca te face prizonier al acelui framework iar
fara existenta frameworkului tu nu mai intelegi ce trebuie sa faci cu un request in conditiile in care ai lib-ul standard de JAVA EE in fatza ochilor
Sa stii ca orice liceean se descurca si fara programare intr-un mvc framework, urmarind indicatiile de pe video tutoriale de pe youtube.
Isi mai are rostul intrebarea "parametrii de request si atribute de sesiune ? " Nope, din moment ce pentru noi servleti sunt o mare necunoscuta.
Noi si astia de aici  http://education.ora...params=p_id:188, suntem cam nebuni,si avem prea mult timp liber
din moment ce ne dedicam atata timp tehnologiilor  de baza ale JAVA EE.
Pai JAVA EE inclue JAVA SE. Cand vorbim de mediul corporate, pentru java spunem JAVA EE.Iar cunoasterea de baza a tehnologiilor JAVA EE este
obligatorie: JSP/Servlets/JSTL/EL
Dude, faptul ca poti inlantui servleturi n-are nici o treaba cu BUSINESS LOGIC. Dincolo de toate aberatiile tale, tu HABAR N-AI ce inseamna business logic. Daca tu iti creezi aplicatia in asa fel incit business logic-ul este prins intr-o inlantuire de servelturi, mult sugces in continuare. Un proiect in care sa crosetez servleturi manual nu este chiar visul meu de programator batrin Posted Image

In concluzie, intrebarea ta, si anume "am un servlet, cand dpdv al business logicului imi invoc servletul cu RequestDispatcher clauza "forward " si cand il invoc cu RequestDispatcher clauza " include " ?" este o oligofrenie de inalta speta. Daca intrebai "care e diferenta intre include si forward la RequestDispatcher?" era altceva. Mai mult, include si forward sint METODE, nu clauze Posted Image

Framework-urile nu se folosesc pentru ca aia care le folosesc nu stiu programare, ci pentru ca maresc productivitatea si creeaza o separatie clara intre iubitele tale, servleturile, si ceea ce oamenii normali la cap numesc business logic. Motivul pentru care acele framwork-uri au fost create este tocmai faptul ca servlet + jsp = m...e, intr-o aplicatie serioasa. Sigur ca daca faci o aplicatie de pronosticuri pentru cupa mondiala, cu 3 ecrane, o sa folosesti servleturi chioare. Da chiar si atunci, tot iti separi "business logicu"  de rahatu de servlet Posted Image

Cit despre certificari, am avut si noi unu din-ala care n-a fost in stare sa faca nimic la partea practica, da era Oracle professional certified Posted Image

#3
OriginalCopy

OriginalCopy

    I'm harmful, fear me please! :))

  • Grup: Senior Members
  • Posts: 27,268
  • Înscris: 10.08.2006

 lightpoint, on 16 martie 2017 - 11:39, said:


Sau poti sa ai 20 beton si nimeni nu se supara ca vine altcineva sau pleaca.

Pai daca se simte zdravan cand pleaca unul atunci inseamna ca in realitate compania este praf de creta.

Noi mergem pe filosofia ca trebuie sa avem atati developeri cat proiectul necesita , astfel incat  sarcinile sa fie egal distribuite dupa competentele lor.Asta facem noi prin Agile.Ne asiguram ca fiecare
developer nu are nici un plus dar nici in minus taskuri, ci acele taskuri sunt exact pe masura priceperii lor.Astfel Agile ne asigura distributivitatea efortului in echipa.

Este de inteles ,ca din moment ce nu stii partea de baza  a stivei de tehnologii JAVAEE, respectiv JSP/Servlets/JSTL/EL  sa incerci sa reduci functionalitatea servletului la un simplu controller dintr-unde MVC framework.

Iar un framework este format din servleti.Mai bine zis o colectie dinamica, bine organizata de servleti care pot fi inlantuiti si rearanjati in liste de executie astfel incat acestia sa
formeze noi cai  de executie si noi fluxuri de date in functie de dorintele developerului.Iar inlantuirea servletilor se face prin RequestDispatcher apelat prin clauza "include" sau prin clauza "forward".
Daca vrei de exemplu ca un servlet sa astepte dupa alt servlet sau dupa o colectie de servleti , atunci folosesti clauza "include" a RequestDispatcherului, daca vrei sa rutezi sau sa deleghezi actiunea unui
servlet catre alt servlet sau catre alta componenta (filtru/etc) atunci folosesti clauza "forward".
Intr-un framework path-urile intre servleti le creezi fie prin mapaare in fisier XML, fie prin annotari.

Deci ca o mica concluzie, tu de fapt spui (fara sa-ti dai seama) urmatoarea chestie:
Oricum, dpdv al profesionistilor, nu invoci nici un servlet, folosesti in framework (care este o colectie organizata de servleti)
Betooon, acum incepem sa ajungem la un numitor comun.
De aceea daca stii baza JAVA EE, atunci folosirea unui framework este foarte usoara.
Insa daca nu cunostii baza JAVA EE , atunci folosirea unui framework iti creaza un handicap in sensul ca te face prizonier al acelui framework iar
fara existenta frameworkului tu nu mai intelegi ce trebuie sa faci cu un request in conditiile in care ai lib-ul standard de JAVA EE in fatza ochilor
Sa stii ca orice liceean se descurca si fara programare intr-un mvc framework, urmarind indicatiile de pe video tutoriale de pe youtube.
Isi mai are rostul intrebarea "parametrii de request si atribute de sesiune ? " Nope, din moment ce pentru noi servleti sunt o mare necunoscuta.
Noi si astia de aici  http://education.ora...params=p_id:188, suntem cam nebuni,si avem prea mult timp liber
din moment ce ne dedicam atata timp tehnologiilor  de baza ale JAVA EE.

Pai JAVA EE inclue JAVA SE. Cand vorbim de mediul corporate, pentru java spunem JAVA EE.Iar cunoasterea de baza a tehnologiilor JAVA EE este
obligatorie: JSP/Servlets/JSTL/EL

Știi ceva tehnologii, ai habar de unele chestii, dar la capitolul arhitectură trebuie să te mai coci.

#4
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017

 Mosotti, on 16 martie 2017 - 13:57, said:

Yeah, right, 20 de oameni beton, noi ne limitam la 5, asa, mai necunoscatori
Noi cam la 200.

Quote

Nu, inseamna ca proiectul este foarte complex si extrem de masiv si echipa restrinsa este formata din oameni foarte capabili si foarte greu de inlocuit.
Puteti face propriu framework de MVC ?
Problema nu este nivelul de programator in asemenea proiecte, ci cunoasterea proiectului in sine si a cerintelor de business. Sigur ca asemenea lucruri nu se pot explica unuia care n-a avut parte de asa ceva, tre sa vezi ca sa crezi

Quote

Ca sa pricepi mai bine, intr-un asemenea proiect si daca vine cel mai tare programator din univers, tot se uita ca boul la poarta noua si dureaza luni bune pina se prinde cum merge treaba.
Asta este mentalitatea bucatarului sau sudorului care a invatat din videoclipuri de pe youtube.Mai era unul pe aici ca el mare si tare cu licenta , etc si am vazut cat de tare.

Quote

Si la noi e Agile, dar nu este loc de incepatori si de habarnisti care nu sint in stare sa faca macar o parsare de parametri,
Deocamdata incepatorii la noi stiu baza tehnologiilor JAVA.

Quote

Dude, faptul ca poti inlantui servleturi n-are nici o treaba cu BUSINESS LOGIC. Dincolo de toate aberatiile tale,
tu HABAR N-AI ce inseamna business logic.
Daca tu iti creezi aplicatia in asa fel incit business logic-ul este prins intr-o inlantuire de servelturi,
mult sugces in continuare. Un proiect in care sa crosetez servleturi manual nu este chiar visul meu de programator batrin
"DUDE" ti-am aratat ce inseamna structura unui framework.
DUDE , in functie de business rules care decid business logicul iti proiectezi FRONT-END controllerul care poate fi aplicatie web in java, serviciu REST, aplicatie in JAVA SE, aplicatia JAVA SE cu interfata grafica (SWING/JAVA FX)
Dar regulile business logicului influenteza direct arhitectura front-endluui DUDE.Auzi DUDE , daca am Business Logicul de la aplicatia A si business logicul de la aplicatia B si vreau sa-mi re-folosesc acelasi componente ale front-end controllerului atunci imi fac propriul framerwork dude, in care elementele frameworkului sunt entitati singulare care fac un singur lucru si il fac bine. Si avand discretizat si impartit astfel front-controllerul, DUDE, eu pot sa-l refolosesc pentru diferite contexte de business logic. Adica cu alte cuvinte  DUDE , practic front-end controllerul meu actioneaza la randul sau ca un  REQUEST-DISPATCHER  de business logic.Ei bine dude daca front-end controllerul meu este o aplicatie Web atunci fiecare entitate este
un servlet.Si imi creea diferite cai in interiorul front-end controllerului(ca la lego) astfel incat sa-mi calibrez front-end controllerul pt Business-Logicul pe care il vreau eu, fara alte liburi sau schimbari in plus.Buhuhu...
Asta face sub capota celebrul tau framework in care lucrezi. Si asta de regula face orice framework proiectat intern.La fel ca si cele 3rd party pe care le folositi dar ca noi ne creem propriile frameworkuri.

SI apo mai este o chestie: voi nestiinfd tehnologiile de baza JAVA EE nu puteti face mentenanta la clienti care au proiecte enterprise-mamut facute in 94-95 care si acum inca functioneaza.

Quote

Mai mult, include si forward sint METODE, nu clauze
Sunt, dar in JAVAEE, o metoda poate ascunde un algoritm care la nivel de arhitectura Enterprise poate  actiona  ca o  clauza (conditie) de modificare a modului de interactiune a componentelor.

Quote

Framework-urile nu se folosesc pentru ca aia care le folosesc nu stiu programare, ci pentru ca maresc productivitatea si
Frameworkurile sunt folosite cum trebuie doar de ce care stiu ce se afla sub capota lor.Altfel orice maimutza stie sa-ti mapeze un controller cu annotari si sa mapeze
niste clase intr-un fisier de config xml, si sa foloseasca niste algoritmi de tip FACTORY  pentru a creea obiecte specifice si nu ai nevoie sa  ai experienta in domeniul respectiv.

Quote

Motivul pentru care acele framwork-uri au fost create este tocmai faptul ca servlet + jsp = m...e, intr-o aplicatie serioasa.
Frameworkurile au fost create pentru  a reduce costurile de mentenanta ale aplicatiilor, fie pentru a unifica anumite arhitecturi software, fie pentr a fi compliant pentru mai
multe arhitecturi.
Beleaua este ca un framework te face dependent de el, devi prizonierul lui, devi dependent de el iar asta corporatiilor mari nu le prea place.Indepedenta este mult mai importanta
pentru astfel de corporatii.Sunt in stare sa investeasca masiv in propriu lor framework intern decat sa depinde de solutii 3rd party.

Quote

Sigur ca daca faci o aplicatie de pronosticuri pentru cupa mondiala, cu 3 ecrane, o sa folosesti servleturi chioare.
Da chiar si atunci, tot iti separi "business logicu"  de rahatu de servlet
Cit despre certificari, am avut si noi unu din-ala care n-a fost in stare sa faca nimic la partea practica, da era Oracle professional certified
faptul ca ingnori bazele JAVA EE , o faci pe barba ta.
Dar hai sa mergem pe JAVA SE:

1)
Sa zicem ca am 500.000 de obiecte care pot fi String/Boolean/Integer/Double/ care ocupa X RAM;
Si sa ma zicem ca am niste metode care folosesc biblioteca standard de java se pentru a face cautari, si aceste ocupa Y RAM;
Ce modificari simple as putea face eu, astfel incat cele 500.000 de obiecte sa reflecte acelasi continut dar sa ocupe X/10  RAM  ?
si cu ce metode as putea inlocui metodele de cautare din biblioteca standard de SE astel incat sa ocupe Y/10 RAM ?

2) Sa zicem ca am 500.000 de obiecte care pot fi String/Boolean/Integer/Double/LocalDateTime/LocalDate.
De data asta ma interseaza  sa scriu cat mai putine liniii de cod care sa poate compara Stringuri cu Stringuri, Boolean cu Booolean, s.a.m.d
Cat linii de cod imi trebuie pentru a realiza acest lucru , si care ar fi ele ?

PS: imi place sa stau de vorba cu tine.Se vede ca esti adevarat profesionist si am ce invata de la tine.Deci te rog ai cuvantul .Cum as putea rezolva problemele  de mai sus intr-un mod foarte simplu ?.Astept rezolvarile

Edited by lightpoint, 16 March 2017 - 15:19.


#5
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017
La noi in organizatie demult suspectam  urmatoarele chestii :
https://dzone.com/ar...ameworks-making
E bine de stiut un framework  ? Da .Este insa obligatoriu ? Nu.

Edited by lightpoint, 16 March 2017 - 15:36.


#6
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004
Omule, nu te mai chinui, ai demonstrat ca nu stii ce inseamna business logic si nici ca tre separat de restul borhotului. Si nu, servleturile nu sint business logic. Cum ti-au mai zis si altii, stai mai prost cu arhitectura :lol:

Tu tragi degeaba concluzia ca io as ignora una sau alta sau n-as stii una sau alta, daca asta te face fericit, foarte bine. Eu n-am zis nicaieri ca nu stiu ce face un servlet sau sa cineva ar trebui sa-l ignore, doar am raspuns la intrebarea ta timpita.

Dar da, daca cineva vrea sa ignore servleturile COMPLET, poate sa o faca linistit, la fel cum cineva care conduce un BMW nu tre sa stie ce e sub capota. Daca e o problema, se ocupa mecanicul. De-aia in OOP exista concepte precum INCAPSULARE si ABSTRACTIZARE pentru ca sa nu-ti pese de ce dracu au facut altii inainte. Framework-ul, ca si masina, este o unealta. Principala ta preocupare ar trebui sa fie implementarea cerintelor concrete ale proiectului, cu performante maxime si efort minim. Ca sa faci asa ceva, tre sa folosesti un framework si sa nu inventezi roti

Cit despre "problemele" tale, tu insuti ai o mare problema, si anume nu te stii exprima. Pune o problema concreta, cu cerinte concrete. Input, output, exceptii, limitari, performata. Stiu ca suna simplu, da e foarte greu :lol:

#7
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004

 lightpoint, on 16 martie 2017 - 18:19, said:

Omule ti-am aratat cum business logicul poate influenta  arhitectura unui front controller, cine are urechi de auzit sa auda, restul nu ma intereseza.
Nu influenteaza deloc, business logicul nu e ceea ce crezi tu. Business logicul se ocupa de procesarea datelor, controllerul se ocupa de partea de input / validare. Partea de input n-ar trebuie sa fie dependenta de felul in care se proceseaza datele, ar trebui sa fie complet flexibila si partea de procesare n-ar trebui sa aibe habar despre cum vin datele.

Daca de exemplu creezi o aplicatie o sa vrei ca partea de business logic sa fie complet separata si partea de presentation sa poata fi configurata in fel si chip in functie de cerintele clientilor. Daca tu creezi cele doua componente interdependente, you're fucked, pentru fiecare client tre sa le schimbi pe ambele.

Oricum tu n-ar trebui sa te ocupi de facut front controllere cind exista framework-uri mult mai bune decit orice poti face tu. Evident ca asta nu se aplica la proiecte mititele unde trintesti un servlet care freaca citeva jsp-uri si gata ceaiu.


Quote

Exact, de aceea tu esti doar sofer;
Sint sofer, da macar bun. Prefer sa-mi utilizez timpul in cel mai eficace mod posibil. Nu ma intereseaza nimic din ceea ce nu folosesc, nu ma intereseaza blabla-urile si discutile inutile intre ghicshi, simpozioanele si ultimele cretinatati cacate de vreo minte creata undeva prin univers. Singurul motiv pentru care lucrez in domeniu este ca se cistiga de 10+ ori mai mult decit daca ai fi casier la Kaufland de exemplu, desi e de un infinit de ori mai greu, in sensul ca as putea invata intr-o zi sa fiu casier la Kaufland, dar un casier de la Kaufland n-ar putea sa faca niciodata ce fac io Posted Image

Singura certificare ce conteaza pentru mine este satisfactia clientului/angajatorului. Si aia sint si au fost mereu foarte foarte foarte multumiti Posted Image

Quote

Nepasarea asta  nu implica nestiinta.Nu-ti mai ascunde lipsa de cunostiinte sub principiile OOP-ului.
Lipsa de cunostinte inutile? E o filozofie de viata. I don't give a fuck. Daca trebuie sa fac ceva, atunci imi canalizez toate energiile pentru gasirea celei mai bune solutii. Zicea cineva (un bou, probabil) ca un programator tre sa stie cel putin enspe limbaje de programare. Nicidecum, un programator tre sa faca programe care sa mearga cit mai bine si sa aibe cit mai putine erori. Este absolut irelevant daca Giorgica "stie" 10 limbaje de programare si nu poate implementa nimic concret. Multi se pricep la dat din gura, design pattern-uri, SOLID si cind tre sa faca un cacat de problema banala, nix. Se aduc in discutie tot felul de chestii absolut fara nici o legatura, cum ar fi JSON, nus ce dracu au o gramada cu JSON-ul ala, chiar daca n-are nici o legatura cu problema data, ei vor sa foloseasca JSON. Caca-m-as pe el JSON Posted Image

Dar din nou, sa nu crezi ca nu am cunostinte despre cacaturile alea de servleturi, pur si simplu nu le folosesc in mod direct si nici nu intentionez sa schimb asta. Pentru tine o fi culmea extazului sa impletesti servleturi, pentru mine nu, partea de UI e cea mai banala parte dintr-o aplicatie Posted Image

Quote

Eu am zis scurt si la obiect ceea ce am avut de spus.Tu insa n-ai putut intelege.
Astept raspunsurile la JAVA SE. Hai ca poti, stiu ca poti . Hai curaj, incearca sa gandesti.N-a omorat pe nimeni pana acum ganditul.
Inca astept problema concreta, nu blabla-uri cretine
De exemplu "Ce modificari simple as putea face eu, astfel incat cele 500.000 de obiecte sa reflecte acelasi continut dar sa ocupe X/10  RAM" este fix un cacat de intrebare si raspunsul este "nici o modificare din univers nu-ti garanteaza ca obiectele respective vor ocupa x/10 din memoria initiala"
La a doua iar nu inteleg ce vrei, te referi cumva la stream? Te excita chestiile astea atit de mult?
List<Object> foundObjects = objects
.stream()
.filter(o->o.equals("boo"))
.collect(Collectors.toList());

Si la ce conteaza numarul de linii? Daca vrei poti sa pui tot programul intr-o linie
public class Test{public static void main(String[] args){System.out.println("BOO");}}


#8
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017

 Mosotti, on 16 martie 2017 - 19:49, said:

Nu influenteaza deloc, business logicul nu e ceea ce crezi tu. Business logicul se ocupa de procesarea datelor, controllerul se ocupa de partea de input / validare. Partea de input n-ar trebuie sa fie dependenta de felul in care se proceseaza datele, ar trebui sa fie complet flexibila si partea de procesare n-ar trebui sa aibe habar despre cum vin datele.
Asta este nivelul generic de segregare a partilor unei aplicatii.In acest configuratie ahitecturala, business-logicul se cupleaza prin intermediul
unei interfate si automat nu depinde de implementarile interfetei, unde acesta implementari pot fi aplicatia Web, aplicatie Desktop, bla bla.
Ei bine implementarea acesti interfete poate fi o aplicatie web.Iar aplicatia web trebuies sa fie scalabila.Matale folosesti un mvc framework.Fain.
Noi avem propriul framework.Insa mvc framework-urile  se fac( si ti-am mai zis mai sus) folosind o arhitectura de tip "lego" intre componente.Iar o astfel de arhitectura
are implementat acele mecanism al RequestDisptacherului, pt ca frameworkul tau MVC este de fapt o colectie de servletii scalabila care extind aceiasi clasa HttpServlet.
Daca nu as tine cont de modul actionare al business logicului eu n-as putea sa fac scalabil acel MVC framework.

Quote

Oricum tu n-ar trebui sa te ocupi de facut front controllere cind exista framework-uri mult mai bune decit orice poti face tu. Evident ca asta nu se aplica la proiecte mititele unde trintesti un servlet care freaca citeva jsp-uri si gata ceaiu.
Am facut aplicatii si cu spring mvc, EJB, Hibernate/JPA, cu  REST/SOAP WS, spring security,  si cu front-enduri JAVA SE care se conectau prin JNDI la business logic, sunt satul de astea pana in gat.
Marile corporatii, pe mari proiecte nu vor sa lege de astfel de frameworkuri.Nu vor sa fie dependente de ele.Ele au propriile frameworkuri dezvoltate IN-HOUSE.

Quote

Sint sofer, da macar bun. Prefer sa-mi utilizez timpul in cel mai eficace mod posibil. Nu ma intereseaza nimic din ceea ce nu folosesc, nu ma intereseaza blabla-urile si discutile inutile intre ghicshi, simpozioanele si ultimele cretinatati cacate de vreo minte creata undeva prin univers. Singurul motiv pentru care lucrez in domeniu este ca se cistiga de 10+ ori mai mult decit daca ai fi casier la Kaufland de exemplu, desi e de un infinit de ori mai greu, in sensul ca as putea invata intr-o zi sa fiu casier la Kaufland, dar un casier de la Kaufland n-ar putea sa faca niciodata ce fac io
Pe mine ma interseaza toate aceste intruniri.Noi suntem ingineri de software, noi intai facem cercetare experimentala intai si apoi le aplicam pe produsele noastre.
Din aceste considerente am observat influenta nebenefica a utilizarii excesive si frecvente al unui framework 3rd party.

Quote

Singura certificare ce conteaza pentru mine este satisfactia clientului/angajatorului. Si aia sint si au fost mereu foarte foarte foarte multumiti
Pai si la noi la fel sunt, stai linistit.Dar noi mai avem si R & D in domeniul Enterprise.

Quote

Lipsa de cunostinte inutile? E o filozofie de viata. I don't give a fuck. Daca trebuie sa fac ceva, atunci imi canalizez toate energiile pentru gasirea celei mai bune solutii. Zicea cineva (un bou, probabil) ca un programator tre sa stie cel putin enspe limbaje de programare. Nicidecum, un programator tre sa faca programe care sa mearga cit mai bine si sa aibe cit mai putine erori. Este absolut irelevant daca Giorgica "stie" 10 limbaje de programare si nu poate implementa nimic concret. Multi se pricep la dat din gura, design pattern-uri, SOLID si cind tre sa faca un cacat de problema banala, nix. Se aduc in discutie tot felul de chestii absolut fara nici o legatura, cum ar fi JSON, nus ce dracu au o gramada cu JSON-ul ala, chiar daca n-are nici o legatura cu problema data, ei vor sa foloseasca JSON. Caca-m-as pe el JSON
Nu exista informatii inutile in cercetarea software.In R&D exista doar informatii nevalorificate.

Quote

Inca astept problema concreta, nu blabla-uri cretine
De exemplu "Ce modificari simple as putea face eu, astfel incat cele 500.000 de obiecte sa reflecte acelasi continut dar sa ocupe X/10  RAM" este fix un cacat de intrebare si raspunsul este "nici o modificare din univers nu-ti garanteaza ca obiectele respective vor ocupa x/10 din memoria initiala"
Ba da. Ideea e ca String/Boolean/Integer sunt containere ale valorilor de tip  char[]/boolean/int.Adica pe langa valori mai contin si
metode de management ale acelor valori.La date putine, nu este nici o diferenta.Insa la date foarte mari de ordinul milioanelor , acele
containere de valori ocupa sute de mega de RAM ,care din punctul nostru  de vedere este spatiu ocupat degeaba.
Trecerea de la Obiecte de tipul String/Boolean/Integer/Long la primitivele corespunzatoare ne scapa de spatiul ocupat in RAM de acele containere de valori.
Dar cum gestionam primitivele ? Tinand cont ca unele  din metode din Libul Standard de java aplica regexp pt operatii de filtrare/cautare iar altele arunca exceptii(de fapt obiecte de tip exceptie), iar daca exceptia este inlantuita, atunci
la milioane de date am rupt-o in fericire cu RAM-ul.
Astfel daca am aplica un regexp pe milioanele de date am omora efectiv serverul.Si atunci ne creeam propriile metode
de cautare si filtrare pe array-uri apeland la algoritmica de liceu:
maximul unui vector,
extragerea unui pattern dintr-un vector,
jumatatea unui vector,
sortarea unui vector,
s.a.m.d
asigurandu-ne sa alegem algoritmul cel mai simplu dpdv al complexitatii acestuia.
Procedand astfel, spatiu ala de sute de RAM ocupat, se reduce la zeci de RAM, pt ca folosim doar primitive si algoritmi cat mai putin complecsi pe aceste primitive.Ta da....
Ori facand economie de 10 ori per  user la RAM , imagineaza-ti ce economii de RAM si putere de procesare se fac daca am N useri care trag milioane de date.

Quote

La a doua iar nu inteleg ce vrei, te referi cumva la stream?
Nope.Idee e ca obiectele String/Boolean/Integer/Long/LocalDateTime/LocaDate, etc implementeaza interfetele Serializable si Comparable<T>(hopa aste e un generic).Asta inseamna ca toate obiectele de mai sus au implementate metoda compareTo(T object);
Chestia imi spune ca pt toate tipurile de obiecte enuntate mai sus avem,:
(Comparable<Object>)source.compareTo((Comparable<Object>) destination) == 0;

unde source si destination sunt obiecte de acelasi tip;
Daca rezultatul  comparatiei este zero atunci obiectele sunt egale(ca valoare si ca tip)
Daca este mai mare ca zero atunci source > destination
Daca este mai mic ca zero atunci source < destination;

#9
neagu_laurentiu

neagu_laurentiu

    Guru Member

  • Grup: Senior Members
  • Posts: 40,570
  • Înscris: 30.07.2003

 lightpoint, on 20 martie 2017 - 12:01, said:

Ideea e ca String/Boolean/Integer sunt containere ale valorilor de tip  char[]/boolean/int.Adica pe langa valori mai contin si metode de management ale acelor valori.
Le-a unificat MS in C# sa nu mai existe dileme Posted Image

Edited by neagu_laurentiu, 20 March 2017 - 12:48.


#10
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017

 neagu_laurentiu, on 20 martie 2017 - 12:48, said:

Le-a unificat MS in C# sa nu mai existe dileme Posted Image
In ce sens ?

#11
neagu_laurentiu

neagu_laurentiu

    Guru Member

  • Grup: Senior Members
  • Posts: 40,570
  • Înscris: 30.07.2003
Tipurile primitive din C# sunt structuri .NET, nu-s chioare.

#12
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017

 neagu_laurentiu, on 20 martie 2017 - 14:42, said:

Tipurile primitive din C# sunt structuri .NET, nu-s chioare.
pai si in java ai astfel de structuri. Dar in .NET am acces la primitive, fara acel wrapper(acel obiect de tip .NET care infasoara primitiva) ?

Edited by lightpoint, 20 March 2017 - 14:44.


#13
neagu_laurentiu

neagu_laurentiu

    Guru Member

  • Grup: Senior Members
  • Posts: 40,570
  • Înscris: 30.07.2003
Nu. "int" din povestea ta e identic cu "Integer" in .NET.

#14
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017

 neagu_laurentiu, on 20 martie 2017 - 14:45, said:

Nu. "int" din povestea ta e identic cu "Integer" in .NET.
Ei in java int-ul ala e diferit de Integer. Este primitiva fara wrapper.Chestia asta ne permite ca pt sute de milioane de date sa facem economii mari la RAM atunci cand facem procesarea in batch-uri.(
sute de mii de linii  per batch)

Edited by lightpoint, 20 March 2017 - 14:49.


#15
neagu_laurentiu

neagu_laurentiu

    Guru Member

  • Grup: Senior Members
  • Posts: 40,570
  • Înscris: 30.07.2003
Bine, si in C# poti apela un .dll din C/C++ si faci la fel daca ai probleme de performanta.

#16
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004

 lightpoint, on 20 martie 2017 - 12:01, said:

Asta este nivelul generic de segregare a partilor unei aplicatii.In acest configuratie ahitecturala, business-logicul se cupleaza prin intermediul
unei interfate si automat nu depinde de implementarile interfetei, unde acesta implementari pot fi aplicatia Web, aplicatie Desktop, bla bla.
Ei bine implementarea acesti interfete poate fi o aplicatie web.Iar aplicatia web trebuies sa fie scalabila.Matale folosesti un mvc framework.Fain.
Noi avem propriul framework.Insa mvc framework-urile  se fac( si ti-am mai zis mai sus) folosind o arhitectura de tip "lego" intre componente.Iar o astfel de arhitectura
are implementat acele mecanism al RequestDisptacherului, pt ca frameworkul tau MVC este de fapt o colectie de servletii scalabila care extind aceiasi clasa HttpServlet.
Daca nu as tine cont de modul actionare al business logicului eu n-as putea sa fac scalabil acel MVC framework.
Evident ca framework-urile folosesc in spate servleturi, dar asta nu inseamna ca tre sa stii servleturi ca sa folosesti framework-ul respectiv. Servlet-urile te ajuta daca n-ai chef sa folosesti un framework care ascunde partea aia sau daca faci ceva simplu. Daca framework-ul vostru propriu MVC nu ascunde servleturile, inseamna ca nu asta a fost intentia celor care l-au conceput.

Motivul pentru care cineva de obicei invate servleturi este ca e mai putin probabil sa ajunga sa lucreze direct cu framework-uri

 lightpoint, on 20 martie 2017 - 12:01, said:

Am facut aplicatii si cu spring mvc, EJB, Hibernate/JPA, cu  REST/SOAP WS, spring security,  si cu front-enduri JAVA SE care se conectau prin JNDI la business logic, sunt satul de astea pana in gat.
Marile corporatii, pe mari proiecte nu vor sa lege de astfel de frameworkuri.Nu vor sa fie dependente de ele.Ele au propriile frameworkuri dezvoltate IN-HOUSE.
Da pe dracu. Exista o gramada de motive pentru care vrei sa folosesti un framework si sa nu te apuci sa faci tu unu. Sigur ca si in "marile corporatii" se mai gasesc destepti care sa vrea sa inventeze roata, nu degeaba vreo 70% din proiectele software se duc dracului...

 lightpoint, on 20 martie 2017 - 12:01, said:

Pe mine ma interseaza toate aceste intruniri.Noi suntem ingineri de software, noi intai facem cercetare experimentala intai si apoi le aplicam pe produsele noastre.
Din aceste considerente am observat influenta nebenefica a utilizarii excesive si frecvente al unui framework 3rd party.
Nu inteleg ce poate sa fie nebenefic. Il pui acolo si te apuci sa-ti faci aplicatia, nu pierzi vreme si bani facind un framework mai prost Posted Image

Ideea de framework este ideea fundamentala in dezvoltarea software a REUTILIZARII codului.

 lightpoint, on 20 martie 2017 - 12:01, said:

Pai si la noi la fel sunt, stai linistit.Dar noi mai avem si R & D in domeniul Enterprise.
Si in R&D se poat evalua exact rezultatele fiecaruia, te uiti la ce i-a cacat mintea si tragi concluzii. Hirtiile si certificatele sint fix pix. Nici macar la angajare nu conteaza, pentru ca poti sa-ti dai seama de la interviu si eventual test care e treaba, plus ca e si perioada de proba... Da cu siguranta sint o sursa minunata de venituri pentru aia care le emit...

 lightpoint, on 20 martie 2017 - 12:01, said:

Nu exista informatii inutile in cercetarea software.In R&D exista doar informatii nevalorificate.
Evident ca exista. De exemplu pun pariu ca habar n-ai de Ada, limbajul ala folosit pe la sistemele de rachete & shit si pun pariu ca nici nu intentionezi sa te perfectionezi in asa ceva, pentru ca este INUTIL PENTRU TINE.

 lightpoint, on 20 martie 2017 - 12:01, said:

Ba da. Ideea e ca String/Boolean/Integer sunt containere ale valorilor de tip  char[]/boolean/int.Adica pe langa valori mai contin si
metode de management ale acelor valori.La date putine, nu este nici o diferenta.Insa la date foarte mari de ordinul milioanelor , acele
containere de valori ocupa sute de mega de RAM ,care din punctul nostru  de vedere este spatiu ocupat degeaba.
Trecerea de la Obiecte de tipul String/Boolean/Integer/Long la primitivele corespunzatoare ne scapa de spatiul ocupat in RAM de acele containere de valori.
Sincer m-am frecat la ochi ca sa cred. Deci tu sustii ca daca am juma de milion de obiecte Integer, java aloca de juma de milion de ori memorie pentru metodele fiecarui obiect? Posted Image

Dragul meu, metodele se afla in method area, arunca o privire la specificatiile Java. Esti sigur ca n-ai luat certificarea aia cu pile? Posted Image

Deci daca ai un miliard de obiecte Integer, metodele clasei Integer vor fi acolo doar o singura data. Ar trebui ca cineva sa fie complet diliu sa implementeze un asemenea limbaj care duplica codul metodelor de un miliard de ori pentru fiecare obiect...

Ce ocupa memorie mai multa la un wrapper este faptul ca nu ai doar referinta la valoare, ca in cazul primitivei, ci ai referinta la obiect, referinta la valoare si referinta la clasa. Deci in nici un caz de 10 ori mai multa memorie...

In general nu trebuie sa folosesti wrappere, dar, de exemplu, daca vrei sa folosesti containere standard tre sa le folosesti.

Quote


Dar cum gestionam primitivele ? Tinand cont ca unele  din metode din Libul Standard de java aplica regexp pt operatii de filtrare/cautare iar altele arunca exceptii(de fapt obiecte de tip exceptie), iar daca exceptia este inlantuita, atunci
la milioane de date am rupt-o in fericire cu RAM-ul.
Astfel daca am aplica un regexp pe milioanele de date am omora efectiv serverul.Si atunci ne creeam propriile metode
de cautare si filtrare pe array-uri apeland la algoritmica de liceu:
maximul unui vector,
extragerea unui pattern dintr-un vector,
jumatatea unui vector,
sortarea unui vector,
s.a.m.d
asigurandu-ne sa alegem algoritmul cel mai simplu dpdv al complexitatii acestuia.
Procedand astfel, spatiu ala de sute de RAM ocupat, se reduce la zeci de RAM, pt ca folosim doar primitive si algoritmi cat mai putin complecsi pe aceste primitive.Ta da....
Ori facand economie de 10 ori per  user la RAM , imagineaza-ti ce economii de RAM si putere de procesare se fac daca am N useri care trag milioane de date.


Tot nu inteleg cum faceti economia de RAM schimbind din wrappere in primitive Posted Image

Io cred ca tu ai ramas cu impresia gresita ca trecerea de la wrappere la primitive a dus la scaderea memoriei de 10 ori, de fapt a fost vorba de schimbarea algoritmului, care nu mai aloca memorie aiurea in esenta lui Posted Image

Una din problemele majore la wrappere vs primitive e de fapt PERFORMANTA, nu memoria. De exemplu, un simplu test:

long start = System.currentTimeMillis();
for(long i = 0; i <= 1000000000; ++i) {
Long boo = 0L;
boo += i;
}
long end = System.currentTimeMillis();
System.out.println((end - start));
	
start = System.currentTimeMillis();
for(long i = 0; i <= 1000000000; ++i) {
long foo = 0L;
foo += i;
}
end = System.currentTimeMillis();
System.out.println((end - start));


La mine da asa:

10070
795



 lightpoint, on 20 martie 2017 - 12:01, said:

Nope.Idee e ca obiectele String/Boolean/Integer/Long/LocalDateTime/LocaDate, etc implementeaza interfetele Serializable si Comparable<T>(hopa aste e un generic).Asta inseamna ca toate obiectele de mai sus au implementate metoda compareTo(T object);
Chestia imi spune ca pt toate tipurile de obiecte enuntate mai sus avem,:
(Comparable<Object>)source.compareTo((Comparable<Object>) destination) == 0;

unde source si destination sunt obiecte de acelasi tip;
Daca rezultatul  comparatiei este zero atunci obiectele sunt egale(ca valoare si ca tip)
Daca este mai mare ca zero atunci source > destination
Daca este mai mic ca zero atunci source < destination;
Io ti-am dat intr-o linie de cod rezultatul pe tava, fara sa mai folosesti comparatori. Depinde ce vrei sa faci, de-aia am spus ca intrebarile astea generice n-au nici un rost. De-aia noi nu ne batem cimpii prea mult la interviu, ci dam o problema acasa si apoi omul se intoarce cu rezolvarea si se discuta pe seama ei. Asa iti dai seama exact ce a gindit si de ce...

#17
lightpoint

lightpoint

    Member

  • Grup: Members
  • Posts: 785
  • Înscris: 16.02.2017

 Mosotti, on 20 martie 2017 - 14:54, said:

Io ti-am dat intr-o linie de cod rezultatul pe tava, fara sa mai folosesti comparatori. Depinde ce vrei sa faci, de-aia am spus ca intrebarile astea generice n-au nici un rost. De-aia noi nu ne batem cimpii prea mult la interviu, ci dam o problema acasa si apoi omul se intoarce cu rezolvarea si se discuta pe seama ei. Asa iti dai seama exact ce a gindit si de ce...
Era vorba sa stii ( si asta doar din experienta java SE se poate cunoaste ) ca  acele wrappere implementeaza cele doua interfete, prin urmare metoda compareTo(T object) este comuna.Asa cum se poate vedea compararea si type-castingul se fac amandoua intr-o singura linie.
Since nu ma asteptam sa-ti dai seama , din moment ce pentru  java enteprise ai nevoie de un 3rd party mvc  framework ca sa "rulezi in  enterprise", ma gandesc ca pentru java SE ai nevoie de un 3rd party SE framework ca sa pricepi Posted Image
Vezi tu,  bucatarii sau zidarii care au trecut de la facaletz /trafalete direct in java enteprise nu pot pricepe niciodata o problema pe care un inginer software o ridica si asta pt ca nu au mindset-ul respectiv dezvoltat.
De aceea  corporatiile serioase de enterprise cauta absolventi cu diploma de profil.Una din cauza este acel mindset. Posted Image
Ai nevoie de un framework sau trebuie sa-ti desenez  ca sa intelegi ?   Posted Image

Edited by lightpoint, 20 March 2017 - 15:23.


#18
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004
Cind foloseam io Comparable si Comparator tu te jucai cu putza-n tzarina. Cind te vad cit esti de incintat de chestia asta cu comparatorii mor de ris :w00t:

Si cum dracu v-o venit idea sa folositi sute de milioane de obiecte Boolean pina sa va dati seama ca mai bine folositi boolean? Io asa fara diploma va ziceam sa faceti direct versiunea 2 :roflmao:

Ma, pentru unu care crede ca un obiect se aloca in memorie impreuna cu toate metodele clasei, esti prea arogant. CUM DRACU POTI SA CREZI ASA CEVA SI SA PRETINZI CA AI CERTIFICARE ORACLE????? :lol:

Citez pentru posteritate:

 lightpoint, on 20 martie 2017 - 12:01, said:

Ideea e ca String/Boolean/Integer sunt containere ale valorilor de tip  char[]/boolean/int.Adica pe langa valori mai contin si
metode de management ale acelor valori.La date putine, nu este nici o diferenta.Insa la date foarte mari de ordinul milioanelor , acele
containere de valori ocupa sute de mega de RAM ,care din punctul nostru  de vedere este spatiu ocupat degeaba.

Mai certificatule, ca sa recapitulam

1) Overheadul de la wrappere nu vine de la memoria ocupata de metode, ci de la memoria ocupata de obiectul in sine (fara metode) comparat cu primitiva
2) Spatiul ocupat de obiectele alea nu e "deajeaba", e degeaba doar in anumite cazuri, in altele fiind cit se poate de util, daca nu este nevoie de megaperformanta si memoria nu este o problema nu are rost sa pierzi timpul implementind din nou sortari
3) In momentul in care faci designul unui program care are ca cerinte procesarea a sute de milioane de date pentru nus citi jde mii de useri, nu vad cum dracu te apuci sa folosesti wrappere, mai ales dpdv al performantei.

Deci faptul ca ati schimbat din wrappere in primitive nu e o megalauda, e mai degraba un double face palm pentru ala care a facut prima implementare. Am gasit de curind un while pe un recordset care pentru fiecare rezultat crea un obiect si pe citeva dintre variabilele obiectului le initializa cu metode care faceau la rindul lor selecturi. Am inlocuit totul cu un join si merge de 100 de ori mai repede, sint io un geniu sau ala care o facut prima versiunea un diliu? :lol:

Anunturi

Chirurgia spinală minim invazivă Chirurgia spinală minim invazivă

Chirurgia spinală minim invazivă oferă pacienților oportunitatea unui tratament eficient, permițându-le o recuperare ultra rapidă și nu în ultimul rând minimizând leziunile induse chirurgical.

Echipa noastră utilizează un spectru larg de tehnici minim invazive, din care enumerăm câteva: endoscopia cu variantele ei (transnazală, transtoracică, transmusculară, etc), microscopul operator, abordurile trans tubulare și nu în ultimul rând infiltrațiile la toate nivelurile coloanei vertebrale.

www.neurohope.ro

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate