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 |
Servlet Java EE
#1
Posted 16 March 2017 - 11:39
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, Quote
sau poti sa ai 5 beton, care sa poate face oricare orice, iar cind pleaca unul, se simte zdravan. 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 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? Quote
Oricum, dpdv al profesionistilor, nu invoci nici un servlet, folosesti in framework 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 obligatorie: JSP/Servlets/JSTL/EL |
#2
Posted 16 March 2017 - 13:57
lightpoint, on 16 martie 2017 - 11:39, said:
Sau poti sa ai 20 beton si nimeni nu se supara ca vine altcineva sau pleaca. 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. 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. 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 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 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 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 |
#3
Posted 16 March 2017 - 14:26
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
Posted 16 March 2017 - 14:56
Mosotti, on 16 martie 2017 - 13:57, said:
Yeah, right, 20 de oameni beton, noi ne limitam la 5, asa, mai necunoscatori 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. 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. 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, 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 , 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 Quote
Framework-urile nu se folosesc pentru ca aia care le folosesc nu stiu programare, ci pentru ca maresc productivitatea si 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. 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 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
Posted 16 March 2017 - 15:32
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
Posted 16 March 2017 - 17:41
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
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 |
#7
Posted 16 March 2017 - 19:49
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. 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; Singura certificare ce conteaza pentru mine este satisfactia clientului/angajatorului. Si aia sint si au fost mereu foarte foarte foarte multumiti Quote Nepasarea asta nu implica nestiinta.Nu-ti mai ascunde lipsa de cunostiinte sub principiile OOP-ului. 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 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. 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
Posted 20 March 2017 - 12:01
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. 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. 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 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 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 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" 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? 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
Posted 20 March 2017 - 12:48
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. Edited by neagu_laurentiu, 20 March 2017 - 12:48. |
#10
Posted 20 March 2017 - 14:34
|
#11
Posted 20 March 2017 - 14:42
Tipurile primitive din C# sunt structuri .NET, nu-s chioare.
|
#12
Posted 20 March 2017 - 14:43
#13
Posted 20 March 2017 - 14:45
Nu. "int" din povestea ta e identic cu "Integer" in .NET.
|
#14
Posted 20 March 2017 - 14:47
neagu_laurentiu, on 20 martie 2017 - 14:45, said:
Nu. "int" din povestea ta e identic cu "Integer" in .NET. sute de mii de linii per batch) Edited by lightpoint, 20 March 2017 - 14:49. |
#15
Posted 20 March 2017 - 14:52
Bine, si in C# poti apela un .dll din C/C++ si faci la fel daca ai probleme de performanta.
|
|
#16
Posted 20 March 2017 - 14:54
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. 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. 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. 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. lightpoint, on 20 martie 2017 - 12:01, said:
Nu exista informatii inutile in cercetarea software.In R&D exista doar informatii nevalorificate. 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. Dragul meu, metodele se afla in method area, arunca o privire la specificatiile Java. Esti sigur ca n-ai luat certificarea aia cu pile? 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 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 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; |
#17
Posted 20 March 2017 - 15:14
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... 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 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. Ai nevoie de un framework sau trebuie sa-ti desenez ca sa intelegi ? Edited by lightpoint, 20 March 2017 - 15:23. |
#18
Posted 20 March 2017 - 16:32
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
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 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????? 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? |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users