2010-01-31

Ce stim despre vitamine ?


Ce stim despre vitamine ?
- compilatie din diverse surse online, rog semnalati eventuale erori -


Lipsa vitaminelor provoaca boli
  • lipsa vitaminei C (acid ascorbic) provoca vechilor marinari scorbut, o boala care afecta printre altele gingiile si probabil a dus la imaginea piratilor stirbi
  • lipsa vitaminei B3 (niacina) obisnuia sa cauzeze populatiilor sarace "pelagra", o boala care provoca simptome de la "piele groasa" pana la simptome de specifice bolilor psihice
  • lipsa vitaminei D duce la ne-fixarea calciului in oase, facilitand osteoporoza
  • lipsa vitaminei K duce la probleme in coagularea sangelul, provocand hemoragii
  • toate vitaminele au fost identificate prin prisma contributiei lor la sanatate (de unde si denumitea de "vita")

Excesul de vitamine poate provoca si el boli
  • excesul de betacaroten (un precursor de vitamina A) provoaca colorarea pielii in orange, caderea parului, dureri la nivelul oaselor, slabiciune, iritabilitate
  • excesul de vitamina D poate provoca sete exagerata, depresie, insuficienta renala
  • vitamina K are efct contrar anticoagulantelor prescrise in unele boli de inima

Ce sunt vitaminele
?

Vitaminele sunt compusi chimici necesari organismului si usor mai complexi decat mineralele (Fier, Calciu, Fosfor). In merea majoritate vitaminele nu pot fi sintetizate de catre organism din "combustibilul" energetic obisnuit, bazat pe carbohidrati + apa (Carbon,Hidrogen,Oxigen). Pe de alta parte, reactiile de ardere au nevoie de vitamine ca si catalizatori.

Vitaminele nu se consuma direct, ele sunt mai degraba catalizatori pentru alte reactii utile organismului. Spre deosebire de minerale care se extrag din saruri destul de stabile, vitaminele se distrug foarte usor, unele prin fierbere, altele prin expunere la lumina, etc. Unele diete (exemplu vegetariana) pot fi foarte sarace in anumite vitamine daca nu se fac eforturi de diversificare.

Carenta de vitamine se manifesta dupa perioade lungi de timp (luni). In cazul vitaminelor solubile in apa (B1, B2, B5, B6, B9, B12, C, P), organismul elimina de obicei excesul peste doza zilnica necesara, dar este necesar un aport zilnic. In cazul vitaminelor (A, D, E, K) acestea se pot acumula, chiar provocand probleme daca se aduna in excess.


De unde luam vitamine ? - cateva exemple mai fericite
  • Vitamina C (acid ascorbic / E300) o gasim in ultima vreme adaugata in multe sucuri (intrucat se distruge prin pasteurizare). Se mai foloseste ca si conservant. Nu cred ca mai duce cineva lipsa acuta de vitamina C astazi.

  • Vitamina D este sintetizata de piele in urma expunerii la soare
  • Vitamina K este generata in mare parte de flora bacteriana, in afara cazurilor unor tulburari grave ale digestiei proocate de antibiotice, alcoolism
  • Vitamina A se poate obtine de exemplu din morcovi

Si daca vitaminele lipsesc ?

  • Unele vitamine sunt mai putin raspandite in alimentatie. Riscul scade la o alimentatie variata, dar si in acest caz absorbtia vitaminelor poate fi afectata de diverse probleme digestive. Hrana din timpul iernii este cunoscuta a provoca a-vitaminoze care se pare ca sunt la originea "asteniei de primavara".
  • Un supliment de vitamine poate suplini probleme in alimentatie - chiar daca este de preferat ca ele sa fie extrase din alimente. Am validat empiric ca un supliment de complex B o data pe iarna imi imbunatateste starea generala, inclusiv ca tonus psihic.

Incheiere

  • Vitaminele nu vindeca miraculos boli virale/microbiene, dar lipsa lor lasa organismul incapabil sa functioneze in parametrii normali, inclusiv in privinta luptei cu bolile.
  • Industria farmaceutica produce o gama variata de vitamine "sintetice". Vitaminele sintetice sunt identice ca si formula chimica cu vitaminele naturale (cel putin teoretic). Totusi, procesul de sinteza poate adauga compusi paraziti, izotopi mai putini uzuali, etc.
  • De multe ori pericolul lipsei vitaminelor este mai mare decat pericolul vitaminelor sintetice (pastile, efervescente, etc). Atunci cand se poate insa, este totusi recomandata o alimentatie variata sau axata pe vitamina in deficit.

"The more I say, the more I know". Republicarea articolelor este permisa cu citarea autorului

2010-01-28

Utilizare masini virtuale - vmware, virtualbox

Utilizare masini virtuale - vmware, virtualbox

Nota : Acest articol necesita cunostinte medii despre calculatoare.

Ce sunt masinile virtuale ?

Masinile virtuale (am folosit Vmware si putin Virtualbox) fac posibila rularea unui alt sistem de operare intr-o "fereastra" a sistemului de operare principal, fara a repartitiona hard-disk-ul. De exemplu pot rula un Windows Xp intr-o fereastra a Windows 7. Sau se poate rula Linux intr-o fereastra a Windows, si invers. Este ca si cum ai avea un alt calculator (virtual) pe care il poti porni/opri ca pe un program obisnuit. Am spus "intr-o fereastra" ca principiu, masina virtuala poate fi extinsa pe tot ecranul.


Cum functioneaza ?
Supportul pentru masini virtuale se instaleaza ca un program obisnuit (exemplu : Vmware, Virtualbox, etc). Dupa instalare, cateva configurari stabilesc cat din sistemul real poate imprumuta masina virtuala (memorie, disk). Masina virtuala are un bios virtual, unde poti alege de unde sa booteze, etc. Arata ca un calculator real care porneste.

Dupa pornirea masinii virtuale se poate boota de pe CD/DVD si instala sistemul de operare dorit. Pot exista mai multe masini virtuale create si chiar ruland in acelasi timp. Masinile virtuale se pot apoi sterge de pe hard-disk ca un director obisnuit cu fisiere.

Masinile virtuale functioneaza ceva mai incet dacat un sistem de operare instalat direct pe hard-disk - diferenta este mai mica la procesoare mai noi care suporta hardware virtualizare. Totusi nu se simte o diferenta notabila la utilizari obisnuite (Internet, Office, Muzica). In functie de cat de bine se intelegea virtualizarea cu placa video am reusit sa vad si filme si sa joc un joc mai vechi (Warcraft III).


La ce folosesc masinile virtuale ?

Utilizare sisteme de operare diferite fara a reinstala calculatorul
  • Odata instalat un sistem de operare (Windows, Linux), care are driverele necesare, se poate instala un program de virtualizare (Vmware, Virtualbox), se pot defini in el una sau mai multe masini virtuale iar in fiecare masina virtuala se poate instala cate un sistem de operare. Masinile virtuale vor avea discuri virtuale, care vor fi stocate ca fisiere pe disk-ul sistemului de operare principal, numit host (gazda). Sistemul de operare instalat in masina virtuala va avea impresia ca are la dispozitie un hard-disk real.
  • Masinile virtuale consuma ceva spatiu pe disk, dar consuma memorie si procesor doar daca sunt pornite. Masinile virtuale "tin minte" modificarile intre doua porniri, este ca si cum ai reporni un calculator real. Cand nu mai este necesara masina virtuala, spatiul pe disk se poate elibera usor stergand fisierele in care masina virtuala isi tine discurile virtuale.

Rulare simulatana a doua sisteme de operare
  • Sa spunem ca rulez Win7, dar am un mic program care ruleaza doar in WinXP (exista cazuri?). Pot porni un sistem WinXP in masina virtuala.
  • Sa spunem ca vreau sa invat putin Linux, dar in acelasi timp vreau sa am deschise programele obisnuite din Windows. Pot instala Linux intr-o masina virtuala care ruleaza sub sistemul Windows.
  • Pot dori sa testez un nou sistem de operare nou aparut, fara a bloca accesul la sistemul de operare instalat
  • O firma poate cumpara un calculator ceva mai puternic pe care sa existe multe masini virtuale, pe care angajatii sa faca teste in acelasi timp (conectandu-se prin retea).
  • Mi s-a intamplat sa folosesc o conexiune VPN catre birou care taia accesul la Internet. Pentru a folosi si Internet-ul local am facut conexiunea VPN din interiorul unei masini virtuale WinXP care rula peste sistemul de operare ...WinXP.
Backup foarte usor
  • Datorita faptului ca masinile virtuale sunt stocate in fisiere, backup-ul se face pur si simplu copiind directorul masinii virtuale in alta parte. Copiere se face cu masina virtuala oprita.
  • Majoritatea masinilor virtuale suporta "snapshot-uri", in care se stocheaza starea instantanee a masinii virtuale care ruleaza. Peste un timp, daca se doreste asta, masina virtuala se poate intoarce la acea stare. Acest sistem consuma mai putin spatiu decat copierea intregii masini virtuale (se memoreaza doar diferentele).
  • In cazul in care calculatorul s-a defectat sau a fost cumparat unul mai puternic, un back-up al masinii virtuale se poate utiliza pe alt calculator. Cel putin la Vmware nu vor exista probleme cu driverele diferita asa cum se intampla daca incerci sa muti un hard-disk cu Windows de pe un calculator pe altul.
  • Masina virtuala se poate opri cu programele deschise, iar la re-pornire va porni exact din starea in care a fost oprita (cu toate programele deschise).
  • O firma poate crea o masina virtuala cu tot ce este necesar unui angajat (programe specifice, conexiuni VPN multiple) si sa o distribuie tuturor celor care au nevoie. Oricine are o problema ... re-copiaza masina virtuala.

Se poate muta de pe un calculator pe altul
  • Pot de exemplu sa am acelasi sistem de operare si acasa si la serviciu. Pot instala acel sistem de operare pe un stick USB sau pe un hard-disk USB. Singura cerinta este sa existe in ambele parti instalat acelasi program de virtualizare. Atentie, masinile virtuale pe USB functioneaza destul de incet, se recomanda copierea pe hard-disk-ul local.
  • Am avut surpriza sa iau o masina virtuala de pe Windows/AMD64 si sa o mut pe Linux/Intel32 si a reusit sa continue rularea exact unde o oprisem. Probabil nu functioneaza in toate cazurile, dar o masina virtuala oprita se poate intotdeauna repornit fara probleme pe alt hardware si sistem de operare.

Testarea unor programe cu risc de a fi virusate
  • Masinile virtuale au avantajul ca ceea ce ruleaza in interior nu poate afecta sistemul gazda, in afara de dimensiunea fisierului. Un program virusat care este rulat in masina virtuala nu poate virusa sistemul gazda. Daca apar suspiciuni ca s-a instalat un virus, masina virtuala se poate intoarce la o stare salvata anterior.
  • Eu am avut surprize cu niste drivere VPN Cisco care odata instalate faceau imposibila rularea VPN Juniper. Nu am reusit in nici un fel sa fac dezinstalarea completa a driverelor, si oricum cele doua erau incompatibile. Am reusit insa sa instalez cele doua sisteme VPN separat, fiecare intr-o masina virtuala Vmware.

Distribuirea de aplicatii DEMO
  • Pe Internet se pot gasi diferite masini virtuale instalate cu diverse sisteme de operare si programe. Dureaza destul de mult un astfel de download, dar poate fi o metoda buna de a testa un anume sistem de operare.

Windows portabil
  • Se stie ca Windows (cel putin XP) nu mai porneste daca se muta hard-disk-ul in alt calculator. Am vrut sa imi fac un XP "la purtator", care sa nu depinda nici macar de existenta unui sistem de operare pe calculatorul gazda. Pe un hard-disk USB am instalat un Linux (Ubuntu) care booteaza cam pe orice hardware. In Linux am instalat Vmware-Player care porneste o masina virtuala WinXP stocata pe acelasi hard-disk. Performanta este destul de mica (din cauza USB), dar se poate lucra la nevoie. Am reusit acelasi lucru chiar si pe un mic stick USB, dar aici performanta a fost dezastruasa, chiar pe un stick rapid.


Cateva informatii care merita stiute
  • Vmware ofera niste drivere care se instaleaza in sistemul de operare virtual (vmware-tools). Aceste drivere ii permit sa foloseasca facilitati mai avansate din sistemul gazda, sporind viteza si permitand operatii precum "copy&paste" intre masina virtuala si masina gazda
  • Reteaua poate fi configurata in mod "NAT"sau "Bridge". NAT este setarea recomandata, in care sistemul virtual va primi prin DHCP un IP de la masina virtuala, iar acest IP va fi scos in Internet printr-un router virtual. In sistemul "Bridge" este ca si cum masina virtuala ar fi in acelasi switch cu masina fizica, trebuie sa ii dai IP din aceeasi clasa de IP-uri.
  • Masina virtuala nu aloca decat spatiul pe disk folosit. Se poate astfel instala un sistem virtual cu disk de 200GB care sa consume in mod real doar 2GB dintr-un disk real de 10GB. Bineinteles, daca sistemul din masina virtuala va folosi spatiul respectiv, fisierul "disk virtual" va creste pana la limita spatiului disponibil apoi va genera o eroare.
  • Masina virtuala blockeaza memoria configurata pe parcursul rularii ei. Sistemul de operare gazda trebuie sa dispuna practic de dublul memoriei de care ar avea nevoie in mod obisnuit. Se pot incerca diverse variante, de exemplu XP virtual merge ok si cu 512MB, dar cel mai bine cu 1GB (peste necesarul sistemului gazda). Doua masini virtuale rulate simultan blockeaza suma memoriei alocate lor.
  • In loc de CDROM real, unitatea virtuala de disk de poate lega direct la o imagine ISO de CD. Instalarea functioneaza chiar mai repede decat dupa CD fizic.
  • Vmware-player este gratuit, si poate rula masini virtuale create de "vmware-server". Masinile virtuale se pot modifica usor (exemplu dimensiune RAM) editand ca fisier text fisierul *.vmx.
  • Virtualbox este gratuit pentru uz personal si evaluare.
  • Vmware ascunde destul de mult detaliile hardware ale masinii gazda, Virtualbox le ascunde mai putin. Ar trebui ca performanta sa fie un pic mai mare pe Virtualbox, dar se pierde din portabilitate.
  • Se poate seta un director din sistemul gazda sa fie vazut in masina virtuala - director "share". Daca nu, se poate lucra cu directoare share-uite pe retea.
  • In functie de setare, masina virtuala vede sistemul gazda din ip-ul din aceeasi clasa (il gasiti la default gateway)


Cateva informatii mai tehnice
  • Programele rulate in masina virtuala nu sunt interpretate "instructiune cu instructiune". Instructiunile ruleaza nativ pe procesor, doar apelurile care merg spre sistemul fizic sunt inlocuite cu apeluri gestionate de masina virtuala. Astfel programele care nu lucreaza mult cu sistemele periferice (disk, video, audio, retea) pot rula aproape la aceeasi viteza ca un sistem instalat nativ.
  • Masinile virtuale pot boota si alte partitii fizice ale disk-ului real, dar este destul de periculos. Am facut "suspend" la o masina virtuala Linux, apoi am uitat si am bootat sistemul real. Bineinteles ca disk-ul era total inconsistent (multe modificari erau in memoria ... virtuala). A stat foarte mult sa repare disk-ul si a pierdut ceva fisiere.
  • Vmware si Virtualbox nu booteaza din pacate nativ de pe USB, nu exista optiune in BIOS. Ambele citesc insa informatiile de pe stick-uri USB conectate la VM. Se poate face un mic truc isa. Il gasiti aici pentru Virtualbox/Linux (merge similar si pe Windows), dar atentie mare sa nu instalati din greseala pe discul real. (update). Pe Vmware se poate face "Add hard disk", se alege "Use a physical disk" si se alege "Full disk" si numarul discului (de obicei USB este ultimul). Inca o data MARE ATENTIE, daca selectati disk-ul gresit puteti distruge datele de pe hard-disk-ul cu Windows. Chiar si asa, bootarea de pe USB nu functioneaza in toate conditiile, dar nu stiu inca ce face unele secvente de boot USB sa booteze pe o masina reala dar sa nu functioneze pe masina virtuala.
  • Am avut o problema cu adaptorul de retea vmware, se restarta la interval de 20 minute si pica VPN-ul. Solutia a fost sa cresc timpul de "lease" DHCP din setarile vmware.
  • Am descoperit ca pe noul meu laptop Asus cu Intel i5, Win7 crapa cu ecran albastru la trafic mare (peste 20Mbps), iar dezinstaland VirtualBox s-a rezolvat. Vmware merge fara probleme.(/update)


Republicarea articolelor este permisa cu citarea autorului

2010-01-24

Laptop review - Asus K52JR cu procesor Intel i5 430M



Laptop review - Asus K52JR-SX086D

Am cumparat de la Emag acest laptop cu 3000RON ("la promotie"). Mi s-a parut o superoferta sa gasesc un laptop cu procesor foarte nou (Intel i5 430M) - lansat in ianuarie 2010.

Am cautat cateva luni inainte laptopul cel mai potrivit, am scris chiar si un "Ghid de cumparare laptop". In afara de destinatiile uzuale unde se potrivea si ceva mai ieftin, m-a interesat sa faca play la filme DH (1080p) si sa aiba suport foarte bun pentru virtualizare (vmware). Lista completa a feature-urilor procesorului se afla aici.

Ca impresie generala sunt multumit de Asus K52JR (nota 8 cu minus).



Pro :
  • procesor foarte nou dual core cu Hyper-Threading (este vazut ca 4 procesoare) . Are multe facilitati noi si probabil utile precum 3MB "Smart Cache", support special HD (SSE4.1, SSE4.2) Virtualization Technology (VT-x), TurboBoost, Idle States
  • memorie din belsug (4GB) si DDR3
  • display LED, culori foarte naturale. Rezolutia 1366x768 este suficient de mare ca sa nu ai probleme cu programele si suficient de mica ca sa nu ai probleme cu citirea textului. Display-ul este glossy (lucios) dar efectul de oglinda este destul de mic.
  • iesire HDMI pentru conectare la televizor HD sau monitor mai nou (testat cu monitor DVI - cablu hdmi+adaptor)
  • tastatura de tip nou, de tip "Sony VAIO" : taste plate cu cursa mica, intre ele nu este doar aer ci ies individual printru cadru dreptunghiular. Touch-Pad mare, cu feeling placut.
  • Support Win7 "out of the box", adica dupa instalare Win7 bagi CD-ul cu care vine laptopul, pornesti programul si instaleaza drivere si programe automat (chiar da restart de cateva ori)
  • Nu face mult zgomot (cooler, hard-disk).
  • Are optiune in Bios pentru a vedea disk-ul SATA ca IDE, pentru a putea instala XP
  • Are un design sobru, placut, fara luminite enervante si culori tipatoare
  • Ecranul sta stabil in balama, iar laptopul pare construit robust
  • Eliminarea aerului se face prin lateral. In general aerul nu este foarte fierbinte, iar laptopul nu se incalzeste excesiv.
Cons :
  • In XP nu am gasit drivere pentru sunet (update: am gasit pana la urma, vezi mai jos) .Am gasit insa pentru celelalte lucruri importante (Video, Retea)
  • In Linux nu am gasit support accelerat pentru placa video ATI Radeon HD 5470. Ubuntu 9.10 suporta mod grafic ne-accelerat dar detecteaza display-ul 1024x768 in loc de 1366x768, si se vede latit. Mai caut setarea magica care sa il faca sa utilizeze rezolutia nativa macar, chiar ne-accelerat. Update : am gasit driver care se instaleaza manual, vezi la comentarii.
  • Distributii mai vechi (dar nu foarte vechi) de Linux nici nu intra in mod grafic, probabil dintr-o problema de kernel. Merg insa in mod text.
  • Mai ales pe baterie se aude un usor tiuit de la un ridicator de tensiune probabil. Sunetul este similar cu cel care se aude la unele televizoare de la "blocul de inalta tensiune". Am inteles ca multi oameni nici nu aud sunete atat de inalte, dar pe mine ma deranjeaza un pic cand este foarte liniste. Acelasi sunet il aud (mai incet) si la dispozitive gen PDA Palm, GPS, placa de retea gigabit, router wireless, etc.
  • Tasta sageata-dreapta se afla in grupul de taste numerice, ceea ce este cam ne-intuitiv.
  • Unitatea DVD intra la inceput in rezonanta, probabil pentru ca un colt sta prea aproape de carcasa. Acum nu mai face probleme.
  • Am avut niste crash-uri de Win7/64biti, de fiecare data cand copiam ceva mare la viteza foarte mare (printr-o legatura Gigabit cu un server Linux/samba). Daca copiam prin wireless (mai lent) nu aveam aceeasi problema. Cu Win7/32biti nu mai face crash. Update : cel mai probabil era de la Virtualbox.
  • Programele de demo 3D nu prea vor sa mearga pe Win7 (64 or 32 biti). Pe XP porneste GTA4/Bus Simulator 2008 Demo si merge acceptabil.
Benchmark-uri
  • Win7 performanta (64 bits) : Processor 6.7, Memory 5.9, Graphics 5.0, Gaming graphics 6.2, Disk 5.6
  • Win7 performanta (32 bits) : Processor 6.4, Memory 7.2, Graphics 5.0, Gaming graphics 6.2, Disk 5.6
  • PassMark 3D (Win6 64bits) : 3D Simple 420fps, 3D Medium 42fps, 3D Complex 25fps, 3D - DirectX10 2.93fps (copacelul se rotea cam in reluare si a dat la sfarsit si eroare de memorie ne-dezalocata). Eu nu prea joc jocuri, ce jocuri nu ar merge ?
  • Aquamark v3.0 : Score Win7/32bits : 73552 (AvgFPS: 73.552467, MinFPS: 17.224785, MaxFPS: 171.597641 )
  • Autonomie : bateria tine in jur de 2h40 pe Win7 - setat pe mod economic, dupa ce a functionat 1h40 cu browsing+wireless, estimarea arata 1h (bateria este 40%). La utilizare mai agresiva pe mod economic a durat 2h20 pana a ajuns la 7% cand a facut
    "hibernate". S-ar putea sa conteze ceva si nivelul de negru al display-ului. Aparent nu este o asa mare diferenta daca setezi procesorul sa nu urce pana la 100% din capacitate.
Recomandari, idei
  • Pentru a avea si sunet folositi Win7, de preferinta 32biti pentru a evita problema cu crash-ul. O idee pentru a avea sunet si in XP ar fi un adaptor de sunet pe USB (netestat). Update : exista driver, vezi comentarii.
  • Pe Linux incercati Ubuntu 9.10 sau mai nou. Momentan merge doar in 1024x768, dar este aceptabil lucrul 2D, face play si la filme HD. Vezi driver accelerat la comentarii.
  • Win7 il puteti instala cu hard-disk-ul SATA configurat nativ (EHCI), pentru XP trebuie setat in mod IDE.
  • Win7 32biti o sa vada doar vreo 3GB memorie, de cautat setarea PAE, desi se spune ca in Windows aduce instabilitate driverelor.
  • Iesirea HDMI are si sunet nu doar video, trebuie activata insa din setarile de sunet. Am testat pe un televizor HD-ready cu filmuletze 1080p, se vede superb. De preferat se configureaza "extend display" si se creste rezolutia la display-ul HDMI.


Concluzie : este un laptop foarte performant la un pret destul de bun. Principala lui problema este ca este foarte nou, si probabil va trece destul de mult sa apara drivere in Linux. Pe Xp probabil nu va mai face nimeni driverele lipsa. Posibil sa existe probleme speciale cu driverele existente intrucat pe sisteme hipher-threading este mai probabil sa se manifeste bug-uri subtile.

Nota : Daca nu ar avea acest tiuit i-as da nota 8, asa ii dau doar un 8 cu minus.

P.S. O sa actualizez postul in functie de ce voi mai descoperi.

2010-01-22

Ghid cumparare laptop

Dupa ce am cautat cateva luni laptopul perfect (pentru mine), nu pot spune ca sunt specialist dar ... mai stiu cate ceva.

Atunci cand cumperi un laptop il alegi bineinteles dupa niste criterii. Un criteriu este pretul, altul este performanta tehnica, altul poate fi dimensiunea, greutatea, culoarea, anumite chestii speciale care pentru unii sunt definitorii (unde are sagetile).

Pretul

Pretul constituie principala limitare in alegere. La acest moment puteti gasi (foarte aproximativ) :
  • 1.000 RON .. 1.500 RON - majoritatea netbook : mici (9-12"), simpatice, portabile, dar nu foarte performante, si ceva mai dificil de tastat pe ele (tastatura mica). Sistemele netbook nu au DVD/CD, dar la nevoie se poate atasa unul extern, pe USB. CDROM extern se poate folosi de exemplu pentru instalarea altui sistem de operare.
  • 1.500 RON .. 2.000 RON - laptopuri format mare (13-16") din generatia mai veche. Au ecran suficient de mare sa tina loc de desktop. Tastatura este comoda. Performantele sunt suficiente de obicei pentru Internet, Office, Muzica, filme obisnuite la calitate DVD si cele calitate HDTV cu rezolutie micsorata (cele mai obisnuite). Functioneaza rezonabil in Windows XP, ceva mai in "reluare" cu Vista, Windows 7, mai ales daca nu au minim 3GB RAM.




    Isi arata limitarile la procesari intensive video, jocuri 3D, grafica 3D, programe care consuma multa memorie. Jocuri 3D mai vechi pot functiona daca placa video este foarte performanta.
    Compilarea si (re)encodarea filmelor merge mai greu. Nu merge probabil de loc : captura video cu encodare simultana, play filme inalta definitie (calitate Blu-Ray), compresate. De exemplu nu merg filmele care au in nume 720p sau 1080p (numarul reprezinta rezolutia verticala).




  • 2.000 RON .. 3.000 RON - laptopuri in general destul de performante pentru majoritatea utilizarilor obisnuite. Cu putina straduinta se pot gasi laptopuri foarte performante, dar nu intotdeauna pretul mai mare inseamna performanta mai mare. Unele au autonomie foarte mare, dar viteza mica sau invers. Altele au procesor suficient de rapid dar au prea putina memorie RAM (la acest pret recomand 2-4GB).




2010-01-17

Performanta in sistemele multi-cpu si multi-core

Performanta in sistemele multi-cpu

  Articol pentru programatori in special. O prezentare foarte interesanta (engleza) se afla la final. O sa extrag cateva idei care mi se par interesante despre optimizare performanta din perspectiva hardware. Informatiile sunt relevante pentru achizitionarea procesoarelor si pentru "tuning" aplicatii software.


  Ce limiteaza viteza de procesare

  •   Procesoarele au atins o limita tehnologica pe la viteza de 3Ghz. Intr-o cuanta de timp atat de mica (1s/3.000.000.000), lumina (si orice alt semnal) poate parcurge doar aproximativ 10cm, ordinul de marime al unui procesor. Procesorul nu poate functiona mai repede pentru ca atat ii ia semnalului electric sa faca o tura prin procesor.
  • Procesorul reordoneaza executia unor instructiuni care nu depind unele de altele, pentru a putea executa mai multe operatii intr-o singura cuanta de timp, in paralel. De multe ori insa operatia urmatoare depinde de rezultatul celei precedente, deci nu se poate lansa a doua operatie pana nu se termina prima.
  •  Pentru a creste performanta, s-a inceput crearea procesoarelor multi-core, care incearca sa imparta procesarea pe mai multe unitati procesor. Din cauza interdependenti intre operatii, un program rulat pe 2 procesoare obtine de obicei mult sub dublul performante.
  • Un program care are doar un fir de executie (thread) obtine pe doua procesoare sub 10% in plus fata de a rula pe un singur procesor. Pe de alta parte se pot rula doua programe in paralel la aceeasi viteza cu a le rula pe fiecare singure pe un procesor. Este vorba de programe care consuma mult CPU fiecare, nu programe care stau deschise fara sa faca nimic.
  • Memoria RAM functioneaza cam de 100 ori mai lent decat procesorul, la fel cum Hard-Discul este mult mai lent fata de RAM. Pentru ca procesorul sa poata executa instructiuni la viteza maxima, exista cache-ul L1 care functioneaza aproximativ la viteza procesorului.
  • Cache-ul este o fereastra spre memorie. El incarca zona de memorie care este in executie, iar cat timp executia nu iese din acea zona procesorul poate functiona la viteza maxima.
  • Imediat ce executia iese din fereastra de cache, procesorul asteapta echivalentul a peste 100 de instructiuni sa se incarce o noua bucata din memorie in cache. De aceea un cache L1 mai mare inseamna o viteza mai mare de executie. Cache-ul L1 este foarte scump, deci mic. Unele procesoare au si cache L2 (de 10 ori mai lent si de 10 ori mai mare/ieftin).
  •  Exista si cache L3 care este doar de aproximativ 2 ori mai rapid decat memoria RAM, dar care ajuta sistemele multiprocesor sa nu congestioneze accesul la memoria RAM.
  •  Viteza de executie a unui program nu mai depinde atat de tare de frecventa procesorului, cat de numarul de accesari ale memoriei pe care nu le gaseste in cache. Algoritmi complexi incearca sa pre-incarce in cache memoria necesara in viitorul apropiat, totusi in multe cazuri nu reuseste.
  • Chiar si un 5% de "cache miss" (accesari ale memoriei in afara zonei cache) scade performanta drastic. In loc ca 100 operatii sa dureze 100 cuante timp, vor dura 95+5*100, deci aproape de 6 ori mai mult decat ar dura executate 100% in cache. S-ar putea ca un cache L1 mai mare sa ajute mai mult decat arata benchmark-urile, intrucat programele  benchmark sunt relativ mici, putand sa incapa complet in cache.
  • Viteza cu care ruleaza un program tine foarte mult de felul in care sunt aranjate instructiunile in memorie. Compilatoarele si masinile virtuale incearca sa ajute la aceasta operatie. Salturile in structuri mari de date si "indirectarile" produc totusi foarte multe salturi in afara zonei de memorie incarcate in cache, deci scad performanta.
  • Programarea orientata pe obiecte (C++) tinde sa genereze multe obiecte distribuite in zone de memorie ne-alaturate, deci un cod care iese mai des din cache. Programarea C foloseste in general functii mai mari, indirectari mai putine, zone de date mai compact distribuite, deci are sanse sa genereze un cod care foloseste cache-ul mai eficient.
  • Atunci cand procesorul asteapta dupa memoria RAM, procesorul va arata incarcat 100%, desi el de fapt ... sta degeaba. Este aproape inposibil de detectat impactul iesirilor din cache asupra vitezei, altfel decat prin teste cu diferite procesoare.


   Probleme de concurenta in sistemele multiprocesor

  •    Sistemele multiprocesor au cate un cache langa fiecare procesor. Sincronizarea cu memoria este un proces complex, care de multe ori blocheaza un procesor in asteptarea rezultatului altui procesor. Cache-urile "discuta" intre ele despre locatiile de memorie folosite in paralel
  • Din considerente de performanta, citirile din RAM nu se fac in aceeasi ordine cu scrierile, cel putin pe arhitectura x86/PC. Ce se garanteaza este doar ca fiecare procesor va vedea actualizat ce a scris el. Scrierile altui procesor pot ajunge in alta ordine via memorie.
  • Sa luam doua threaduri care pornesc ambele cu variabilele comune flag=0 si adresa=0. Primul thread seteaza adresa=123 si apoi semnaleaza asta punand flag=1. Este posibil ca un alt thread, pe alt procesor, sa vada flag=1 dar adresa=0 (nemodificata). In foarte scurt timp, si al doilea thread va putea vedea ca flag=1 si adresa=123. Totusi, daca al doilea thread verifica flag-ul exact dupa modificare, ajunge sa foloseasca adresa=0 (ne-initializata).
  • Pentru sincronizarea corecta a accesului la date folosite in comun de threaduri trebuie folosite lock-uri/mutexi, care elimina problema de reordonare pe multi-core. Primitivele de lock evalueaza si modifica atomic variabilele mutex, astfel ca un alt procesor nu poate citi in mijlocul operatiei. Din pacate aceasta sincronizare va bloca pentru scurt timp activitatea tuturor procesoarelor, si va inactiva informatia din cache-ul celorlalte procesoare, ceea ce duce la pierderi in performanta.

  Concluzie: devine tot mai importanta intelegerea arhitecturii hardware pentru crearea unui soft performant ca viteza. Programele viitorului trebuie sa poata fi executate pe fire de executie paralele si cu interdependente cat mai mici, pentru a putea scala pe tot mai multe cores. Frecventa procesoarelor nu va mai creste mult, doar vom avea din ce in ce mai multe procesoare impachetate intr-un cip.

A Crash Course in Modern Hardware:

http://www.infoq.com/presentations/click-crash-course-modern-hardware

2010-01-15

Ce sunt feed-urile RSS ?

Citirea stirilor prin intermediu RSS


Acest articol NU este doar pentru programatori :)

RSS inseamna "Really Simple Syndication" si este un mod mai eficient de citire a stirilor. In loc sa mergem in fiecare zi in fiecare pagina sa verificam daca a aparut ceva nou, vom gasi centralizate stirile pe scurt, urmand sa le deschidem pe cele care par interesante. Iconul specific RSS este acesta:




Multe pagini cu continut des actualizat ofera un link numit "RSS", inclusiv acest blog. Facand click pe acel link, se cere alegerea unui "cititor de feed-uri RSS". Eu folosesc "Google"(Reader), pentru ca se acceseaza direct din pagina web unde citesc emailul de pe Gmail. Este gratuit ca si Gmail.

Dupa alegerea cititorului, se cere autentificarea in contul de email (cel putin la readerul Google).

Dupa autentificare, acel link este adaugat intr-o lista de de "Subscription", in pagina http://www.google.com/reader/ (stanga jos). Fiecare utilizator google are o lista proprie de subscriptii la care primeste instiintari. Instiintarile nu vin pe email, sunt vizibile doar din pagina "Reader". De fapt in momentul intrarii in pagina programul aduna repede informatiile din fiecare pagina.

Din pagina de Gmail se poate alege oricand link-ul "Reader" pentru a ajunge la cititorul de feed-uri RSS. Pentru fiecare adresa subscrisa, se poate vedea simplu ce a aparut nou la acea adresa.

In functie de anumite setari se va afisa doar titlul si inceputul articolului. Facand click pe titlu se poate deschide articolul complet. Facand click pe restul ferestrei se va declara articolul ca "citit", astfel ca stim mereu ce este neparcurs.

Bucatile de articol au jos cateva butoane, dintre care mi se par interesant "Keep unread" (daca vrem sa citim mai tarziu) si "Like" pentru a da un feedback pozitiv articolului.

Feedback-ul "Like" este folosit de Google pentru a ordona articolele dupa relevanta (de obicei le sorteaza dupa data, cele mai noi primele). Eu personal imi doresc ca lucrurile care mi se par interesante sa fie popularizate la cat mai multi cititori, deci prefer sa dau acest click in plus atunci cand imi place un articol. Pacat ca nu exista si un "dislike".

Optiunea "Feed setings"/"Sort by Magic" poate sorta articolele tinand seama si de voturile "Like" ale altor cititori.

Folosing Google Reader urmaresc peste 30 de surse de stiri, inclusiv hotnews.ro, zf.ro, wall-street.ro si mai multe blog-uri cu trafic mic. Nu apuc sa le citesc pe toate, dar cand vreau sa le accesez am un mod simplu de a le parcurge rapid, si de obicei fara reclamele/pozele din pagina originala.

Linkurile RSS sunt oferite de obicei in doua variante, pentru articole si pentru comentarii la articole. Daca punem un comentariu la un articol, putem afla de eventuale raspunsuri abonandu-ne la feed-ul RSS de comentarii pentru acel articol.



RSS mi se pareun sistem foarte util de parcurgere a stirilor, si un prim pas spre organizarea stirilor in functie de relevanta. Pentru cei care nu aflasera deja de acest sistem, sper sa il gasiti util.

P.S. Am observat ca mai nou se foloseste foarte des un icon RSS afisat in dreapta adresei din browser. Facand click pe icon, se poate adauga respectivul site in readerul RSS. Iconul RSS arata astfel :



2010-01-14

Ne poate trage curentul ?

 S-a reactivat de curand in presa online ideea cum ca "a te trage curentul" este o legenda urbana stupida, specifica romanilor si altor popoare mai "inapoiate".

  Ma consider o persoana logica si suficient de informata. Totusi eu personal cred in pericolul curentului de aer.

  Cateva fapte general acceptate


  Cunosc faptul ca virozele respiratorii (precum gripa) sunt provocate de virusi, iar infectiile de catre bacterii. Daca importanta existentei germenilor nu poate fi negata, existenta unor factori favorizanti nu poate fi nici ea exclusa.

 Se cunoaste faptul ca anumite medii chimice toxice favorizeaza aparitia unor boli de plamani cauzate de bacterii. Mediul nu genereaza bacteriile, ci doar favorizeaza dezvoltarea lor incapacitand puterea de lupta a organismului.

 Mai stim ca temperatura corpului usor crescuta (febra) este importanta pentru a creste capacitatea de lupta a organismului impotriva virusilor si baceteriilor.

 In acelasi fel, mi se pare cel putin plauzibil ca o temperatura mai scazuta poate favoriza sau agrava unele boli.


  Eu cred ca exista 3 moduri in care curentul poate actiona negativ



  1. Temperatura locala (probabil cel mai important)

 
  Eu am observat din experienta personala ca daca o parte sensibila a corpului (gat, spate, urechi) devine mai rece decat media corpului, este posibil sa am dupa un timp de expunere spasme musculare (junghiuri).

 Curentul de aer creste viteza de evaporare a transpiratiei, producand local o scadere a temperaturii corpului. Mai ales daca restul corpului este incalzit, transpiratia continua, iar corpul nu va compensa scaderea de temperatura locala.

 Situatia nu apare daca este frig intregului corp, iar corpul pompeaza caldura si opreste transpiratia. Deci probabil imbracarea unor haine mai groase decat este nevoie agraveaza fenomenul asupra zonei expuse frigului (inclusiv din cauza curentului).

 Eu folosesc un test simplu pentru a detecta o posibila amenintare tip "curent" : ating zona cu mana.  Daca zona se simte rece, atunci trebuie sa o aduc cat mai repede la o temperatura normala. Putin masaj pentru activarea circulatiei ajunge de obicei.

  O problema stomatologica poate degenera intr-o infectie daca sistemul imunitar local este incetinit de o scadere a temperaturii locale a corpului. Stim ca bacterii (si chiar virusi) exista peste tot, este necesara doar o scadere a imunitatii pentru a se dezvolta. Unii germeni exista chiar latenti in interiorul organismului, au nevoie doar de o bresa pentru a produce o boala.

 La limita putem sa presupunem ca o scadere puternica a temperaturii unei zone a corpului (cauzata de curent) poate favoriza aparitia cheagurilor de sange, care ar indreptatii banuiala ca "curentul de aer" a avut un rol in unele accidente vasculare (precum afirma cultura rurala).


 2. Evaporarea


  Pentru nas si ochi, curentul de aer - mai ales cel foarte uscat de la aerul conditionat - duce la uscarea mucoaselor si de aici la diverse suferinte. Cel putin uscarea ochilor este susceptibila a provoca si mici dureri de cap.

  Cand am lucrat in Paris, un coleg a fost foarte surprins cand i-am spus ca este posibil ca stranutul lui repetat poate fi cauzat de curentul de aer format intre geamul deschis in dreptul lui si usa. Nu parea foarte convins, dar mi se pare o ingustime de minte sa nu accepti macar ca este plauzibila o asemenea cauzalitate. Macar pentru faptul ca in apropiere trecea suprateran metroul, la un nivel ceva mai sus decat fereastra si tot nu se poate exclude influenta curentului.


  3. Particule aero-purtate

  Microbii pot fi transportati pe distante mai lungi atunci cand exista "curenti de aer". Uneori chiar sistemul de aer conditionat poate fi pepiniera in care se multiplica (daca nu este curatat periodic). Totusi, nu despre acest pericol vreau sa atrag atentia, ci despre un posibil efect simplu, al microbilor/virusilor care sunt transportati pe calea aerului. Ei pot afecta cel mai usor nasul, gatul, ochii, plamanii.

  Este putin probabil ca acesti factori aero-purtati sa genereze durerile de spate. Durerile de spate asociate cu curentul sunt legate cred eu de procese inflamatorii, favorizate de multe ori de o temperatura mai joasa a corpului in acea zona. Bineinteles, nu orice durere de spate este legata de "curent" sau "a stat pe ceva rece".


 
Argumente din experienta pentru teoria scaderii locale a temperaturii


  In urma unei nopti cu aerul conditionat in spate am avut un junghi intercostal puternic, care m-a tinut vreo doua saptamani. In general aerul conditionat orientat direct spre mine imi produce migrene, iar a sta transpirat in curent imi da uneori spasme musculare la gat si spate.


  Totusi:

  Cand eram copil de 13-14 ani obisnuiam sa ies la ora de sport (afara)
doar in maieu si pantaloni scurti (pentru vreo 10 minute, apoi ma imbracam).  
  Desi aveam o sanatate relativ subreda, nu am racit vreodata din aceasta cauza. Explicatia este ca aveam grija sa alerg doua etaje plus doua coridoare, activand circulatia. Apoi temperatura era scazuta pe toata suprafata corpului.

  Nu am probleme daca stau in casa imbracat gros apoi ies afara. Probabil as avea probleme daca as expune frigului zone transpirate ale corpului.

  Din cand in cand am baut ceva rece dupa efort fizic, fara sa racesc la plamani sau sa ragusesc. Explicatia mea este ca de obicei expunerea la acel rece a fost foarte scurt, apoi corpul si-a reluat temperatura normala.



  Incheiere

  Ca sa folosesc o formula celebra, cred ca acest "mit" al imbolnavirii sub influenta curentului de aer este cel putin "plauzibil". Mai cred ca actiunea curentului de aer poate fi mai usor corelata cu realitatea din perspectiva scaderii locale a temperaturii, pentru a evita generalizarile inutile.

Programarea multi-threading

 Din nou un articol pentru programatori. Link-ul video din final m-a inspirat sa popularizez cateva concepte despre arhitecturi multi-threading, inclusiv cateva idei din prezentare (pentru lenesi).


  Ce sunt theadurile (pentru foarte incepatori)

  O aplicatie se executa de obicei intr-un singur process (exemplu programul Word cand il gasiti in "Task Manager"). Procesul poate contine insa mai multe fire de executie, numite threaduri. De exemplu in timpul in care se editeaza documentul, un thread separat parcurge ciclic documentul si semnaleaza erorile de tastare. Threadurile sunt ca niste procese care folosesc in comun aceeasi memorie si care sunt distruse impreuna cand se distruge procesul.

 
 De ce programare multi-threading ?

 1. Aplicatiile multi-threading pot fi distribuite pe mai multe procesoare/cores. O aplicatie single-threaded functioneaza la aceeasi viteza indiferent daca serverul are 1 procesor sau 4 procesoare (presupunem procesoarele identice). O aplicatie care imparte treaba egal pe 4 threaduri poate rula pana la de 4 ori mai repede pe un procesor modern "multicore" cu 4 cores.

 2. Chiar daca exista doar un singur procesor, unele operatii au un fir logic separat si este mai usor sa fie descrise ca threaduri (fire de executie) diferite. De exemplu un browser poate descarca (download) un fisier mare si in acelasi timp sa afiseze o pagina. Teoretic asta s-ar putea face si intr-un singur thread, dar in acest caz ar trebui ca bucata de program care afiseaza pagina sa traga cu ochiul din cand in cand si sa mai lucreze si la download. Situatia se complica cand exista mai multe actiuni care trebuiesc multiplexate. Este mai simplu ca fiecare actiune sa fie programata ca executandu-se in paralel (pe un thread) si aproape fara legatura cu celelalte.


 3. Spre deosebire de doua procese diferite, comunicarea intre doua threaduri este mult mai simpla si economica din punct de vedere al comunicatiei. Doua procese pot comunica copiind datele si trecand prin kernel-ul sistemului de operare. Exista intr-adevar si varianta cu shared-memory, dar nu este simplu de implementat.
  Doua threaduri pot folosi in comun aceleasi date fara a fi necesara copierea. Bineinteles, in acest caz trebuie gestionat cu atentie accesul concurent la date, pentru a nu folosi date incomplet modificate de catre alt thread.


  Probleme in programarea multithreading

  Este dificil sa programezi corect multi-threading. Este foarte complicat sa prevezi toate interactiunile posibile care se pot intampla intre threaduri diferite care actioneaza asupra acelorasi date. As spune chiar ca atunci cand este posibil este recomandata programarea single-thread si separarea operatiilor in procese diferite. Totusi, uneori cea mai buna solutie este un program multi-threading.



  Cateva probleme frecvente in utilizarea threadurilor


  P1: Utilizarea unor informatii incomplete (corupte)

  Pe procesoarele obisnuite, operatiile mai mari de 32biti (4 bytes) nu sunt de obicei atomice. Asta inseamna ca un alt thread poate accesa datele in mijlocul operatiei care le modifica.

  Un exemplu redus la cifre mai mici, ar insemna ca daca un thread (1) modifica o variabila din 32768 (1000000000000000) in 32767(0111111111111111), un alt thread (2) poate gasi operatia efectuata doar pe prima jumatate a numarului si sa citeasca 32512 (0111111100000000).

  Aceste "race-conditions" se intampla foarte rar, de aceea sunt foarte greu de descoperit la teste. Totusi, atunci cand se intampla pot face programul sa "crape".

 Lucrurile sunt mult mai complexe atunci cand operatiile concurente manipuleaza date mai mari. Atunci creste si probabilitatea ca evenimentul "improbabil" sa apara. Probabilitatea mai creste si cu numarul de "cores" ale sistemului. Ce nu se intampla pe 2 cores, poate deveni destul de probabil pe 4 cores.

S1: Protejarea datelor accesate concurent cu "lock-uri"

"Lock-urile" sunt apeluri prin care se blocheaza accesul la o zona de date (resursa) pana la terminarea modificarii. Accesul este protejat de o structura de date numita "mutex" (de la "mutual exclusive"). Aceasta structura spune daca resursa respectiva este blocata de altcineva (precum un bec aprins la baie).

 Totusi, in majoritatea limbajelor de programare, lock-ul nu impiedica efectiv accesul la date. Se presupune ca alt thread utilizator va verifica "mutex-ul" inainte de a incepe o modificare, va astepta pana se elibereaza si apoi va bloca la randul lui "mutex-ul". Este ca becul de la baie fara un zavor, poate functiona ok daca toti oamenii sunt suficient de atenti :)


  Ar mai fi de spus ca lock-urile se fac folosind primitive speciale ale bibliotecilor, nu se pot implementa cu simple variabile.

 Problema este ca a pune un lock face doua operatii : 1) Verific ca lock-ul nu este pus de altcineva; 2) Pun lock-ul (actualizez valoarea variabilei mutex).

  Daca lock-ul este liber la inceput, dar intre cele doua operatii alt thread verifica si el lock-ul, ambele threaduri vor crede ca resursa este ne-blocata si ambele vor pune lock-ul pe resursa, ajungand sa opereze ambele in paralel.

  Primitivele de lock se bazeaza pe operatii atomice gen "test & set", care garanteaza ca o alta verificare nu se poate face in mijlocul acestei operatii de pe alt thread (eventual alt procesor).

 De fapt o operatie de lock este destul de complexa la nivelul hardware. Procesorul care o executa trebuie sa blocheze accesul tuturor celorlalte procesoare la acea locatie de memorie (de exemplu blocheaza tot bus-ul spre memorie). Apoi informatia din cache-ul celorlalte procesoare trebuie actualizata cu noua valoare. Pe acea mica perioada de timp practic procesoarele nu pot lucra in paralel, limitand paralelismul.

  Legat de limitarea paralelismului trebuie notat ca lock-urile blocheaza executia celorlalte threaduri care doresc sa foloseasca zona de date protejata de un lock. De aceea este recomandabil ca aceste sectiuni "critice" sa fie facute cat mai mici posibil, pentru ca celelalte threaduri sa fie deblocate cat mai repede.
 
  In final as mai aminti de asteptarea "optimista" a eliberarii unui lock (spin-lock). Pornind de la ipoteza ca o sectiune protejata de un lock se termina foarte rapid, exista strategia de a verifica in bucla varibila mutex pana se elibereaza si poate fi pusa pe "lock" de catre noul thread. Aceasta asteptare  "activa" consuma ceva procesor. In mod normal, dupa o vreme threadul trece la o verificare mai putin agresiva. Oricum, este inca un argument pentru a face sectiunile critice cat mai scurte cu putinta - dar nu mai scurte ;)

 S1 rafinat

 Atunci cand se modifica date mai complexe, pentru a nu avea sectiuni critice prea mari, se poate utiliza o tehnica speciala.

 Fiecare thread care modifica o entitate complexa, creeaza o copie locala a acelor date, pe care o modifica si o "publica" celorlalte threaduri abia dupa ce modificarea este completa.

  In momentul in care datele au fost modificate complet, threadul care modifica deschide o sectiune critica (lock) si schimba referinta/pointerul de la versiunea veche la versiunea noua.

 Cat timp datele sunt in modificare (inconsistente), nu vor fi citite de catre alt thread. In acest timp, threadurile vor "vedea" versiunea veche a datelor, fara a fi blocate. De obicei acest lucru este acceptabil, cel putin cand avem un singur thread care modifica datele si mai multe care le citesc.

 Copierea datelor nu trebuie sa fie completa. Daca se construiesc structurile mari de date (arbori, hash-uri) din structuri mici imutabile (ne-modificabile) se poate crea noua structura folosind nodurile vechi plus cateva noduri modificate. Este important ca sintaza limbajului sa poata garanta ca aceste structuri nu pot fi modificate/distruse cat timp ele sunt folosite de macar un thread.

 O versiunea mai elaborata poate sincroniza citirea/scrierea mai multor threaduri asupra acelorasi date, astfel incat ele sa nu faca modificari pe baza unor informatii vechi.

 De exemplu daca mai multe threaduri adauga comenzi intr-o coada comuna, este important nu numai ca coada sa ramana coerenta, dar si sa nu se piarda vreo comanda. Daca fiecare thread copiaza versiunea curenta, incepe sa o modifice local si apoi inlocuieste versiunea comuna, apare riscul de a suprascrie o adaugare facuta de alt thread in acel timp.

  O solutie care nu blocheaza threadurile prea mult este ca "referinta" sa  contina de fapt o ierarhie de stari/versiuni consistente si sa controleze accesul concurent la acele versiuni ("managed refferences").

 Este vorba de ceva similar cu un sistem de versionare software (SCM), precum CVS. Fiecare thread poata porni ("checkout") de la ultima versiune completa a acelor date, sa o modifice local si sa publice ("commit") datele modificate.

 Daca apare un conflict de "merge" cu datele comise intre timp, atunci tranzactia va da eroare la cel care a "commis" al doilea. Acelasi sistem se foloseste in sistemele tranzactionale de baze de date (exemplu Oracle).

 Combinata cu tehnici diferite de checkout, eventual retry se poate asigura un sistem coerent de gestionare concurenta a datelor cu minim de inter-blocare a threadurilor. Intrucat se poate gresi foarte usor la gestionarea lock-urilor, este recomandabil sa se folosesca un sistem unic de acces concurent la date, de exemplu "managed refferences". Este mai probabil sa implementezi bine un sistem unic de lock-ing decat 100 de sisteme distribuite prin tot codul.


 va urma


Bonus un link la o prezentare video foarte interesanta (in engleza). Este vorba de un tip de abordare inovativa legata de asigurarea consistentei in programarea multi-threading, utilizand structuri imutabile. Conceptele prezentate mi s-au parut o reala inspiratie pentru programarea multi-threading in general, indiferent de limbaj. Prezentarea este exemplificata pe limbajul Clojure, o implementare Lisp peste masina virtuala Java : http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

2010-01-09

Semnele crizei

  Privind retrospectiv criza economica mondiala din 2009, ce semne prevestitoare am fi putut identifica ?

 Sa ne reamintim intai cum a aparut Criza :


  Criza a fost declansata de catre imprumuturile imobiliare din SUA, prin falimentul bancii de investitii Lehman Brothers, anuntat in 15 September 2008.

  Cauza principala a falimentului a constat in imprumuturile imobiliare "neperformante", adica imprumuturi pe care impumutatii nu erau in stare sa le plateasca.

  S-a descoperit ca foarte multe banci aveau probleme in a recupera banii imprumutati cu multa usurinta. Banii erau garantati cu locuinta, dar executarea foarte multor datornici prin vanzarea locuintelor a dus la scaderea puternica a pretului caselor.

  Unii datornici au descoperit ca este mai profitabil sa nu mai plateasca creditul si eventual sa cumpere o alta locuinta "ieftinita". Asta a avut un efect de bulgare de zapada, care a dus la prabusirea pretului locuintelor si cresterea numarului de datornici care nu platesc.

  Majoritatea imprumuturilor au ajuns sa fie garantate cu locuinte care valoreaza mult sub valoarea imprumutului.

  Toate calculele bancilor si fondurilor de investitii care erau bazate pe profitul acestor imprumuturi au fost date peste cap, unele au ajuns la faliment. Pentru ca falimentul unor banci mari insemna falimentul firmelor care tineau banii acolo, SUA si alte tari au "cumparat" mare parte din bancile cu probleme in schimbul unor bani care sa acopere pierderile bancilor.

  Bancile au devenit foarte atente cu oferirea de credite, intrucat nu era clar cat va scadea valoarea garantiilor. In lipsa de credite, multe firme au ajuns sa aiba probleme de finantare si chiar sa intre in faliment. Datornicii intrati in somaj nu pot plati creditele si nici nu mai pot cumpara produsele unor firme care intra in faliment. De aici porneste un cerc vicios pe care statele incearca sa il sparga pompand bani ieftini (cu dobanda mica) in banci.



  Ce putea prevesti criza ?

  Pretul imobiliarelor

  Din 1997 pana in 2003 pretul imobiliarelor in SUA s-a dublat (exprimat in aur). Era destul de probabil ca aceasta crestere se baza mult pe un efect psihologic : cumparatorii se inghesuiau sa investeasca bani in case iar vanzatorii sa construiasca si sa creasca preturile. Ambii preconizau ca preturile caselor vor creste ... la infinit.

   Pretul caselor crestea pe hartie, dar cererea este artificial marita (oamenii isi luau a doua sau a treia casa). Cand bancile au pus casele datornicilor in vanzare, oferta a depasit cererea, iar pretul caselor a scazut chiar sub valoarea de "echilibru" din 1995, ajungand la minimele din anii '80.


  Acum 5-10 ani observam cum cresc exponential preturile la locuinte in Romania. Devenise din ce in ce mai usor sa iei un credit imobiliar. Atunci mi-am spus sa mai astept vreo 2 ani, cand vor incepe bancile sa vanda ieftin casele rau-platnicilor.

  Socoteala mea a fost gresita, economia a crescut iar preturile au crescut si ele. Am cumparat pana la urma un apartament cu 740E/mp. Preturile au mai crescut vreo 3 ani pana la valori clar umflate, apoi a venit criza care le va re-aduce la valoarea de echilibru.

 Ce am vrut sa arat este ca spargerea bulei preturilor putea fi prevazuta, nimeni nu stia insa cand se va intampla. Cu cat a trecut timpul, bula s-a marit si preturile au cazut "mai de sus".


 Semne mai subtile

 Fara a avea pretentia ca am banuit macar criza ce avea sa vina, anumite evenimente m-au facut sa cred ca exista ceva putred in economie. In ultimii 5 ani mai ales am observat din diferite directii ca activitatea in marile corporatii devine din ce in ce mai ineficienta. Parca nu mai conta atat de mult ceea ce faceau cat tehnicile de marketing si advertising.

  La sfarsitul lui 2004 IBM vindea divizia de PC-uri catre Lenovo. Poate unii isi mai amintesc ca PC-urile mai erau numite si "compatibile IBM". La vremea aceea m-a dezamagit foarte tare vestea. Si astazi mi se pare un simptom al unei boli a economiei actuale.

  Un alt simptom al imbolnavirii activitatii economice mi se pare moda externalizarii unor activitati principale. Adica firma de traditie X  externalizeaza construirea produsului la firma mica y, apoi vine si pune eticheta X si o vinde. Nu mai exista o corelatie intre eticheta si calitate.

  Activitatea in multe corporatii s-a nevrozat foarte mult, nu mai conteaza oamenii care produc intr-adevar valoare, ci cei care sunt in stare sa faca artificii financiare sau pot sa paseze problema la altcineva. Dupa un timp situatia degenereaza intr-un sistem care paseaza problemele in loc sa le rezolve, si care in loc sa recompenseze valoarea recompenseaza powerpointuri.

  Multe firme practica "meta-productia" adica nu produc efectiv produse/servicii, ci doar subcontracteaza mare parte din activitati altor firme. De multe ori ele nu aduc o plus-valoare calitatii produselor.
 Aceste firme nu vor avea viata lunga dupa parerea mea. Pana la urma economia va descoperi cum sa elimine o astfel de veriga nefolositoare.


  Daca mutam discutia pe taramul financiar (locul pe unde s-a spart balonul), gasim exact acelasi lucru: entitati meta-financiare care impacheteaza produse financiare care contin alte produse financiare, pana nu mai stie nimeni exact ce este in cutie. Banci care au subcontractat vanzarea de credite unor firme care nu au nici o motivatie sa asigure bonitatea celor creditati. Manageri care fac inginerii financiare pana cand ...


  Incheiere

  Cred ca criza financiara putea fi prevazuta si prevenita, cu conditia ca factorii implicati sa foloseasca un mimin bun simt. Cred ca unele reglementari care tolereaza si chiar incurajeaza speculatiile financiare "perverse" trebuie sa fie schimbate.

  Estimarea mea este ca in urmatorii 2 ani vor mai erupe si alte probleme economice. Probabil vor apare si cateva situatii de faliment ale gigantilor care practica pe scara larga "meta-productia".

  Va fi un pic mai rau inainte sa fie mai bine. In Romania avem noroc ca nu vom cadea foarte de sus si probabil ne vor ridica mai repede.

2010-01-05

Programare Java - utilizarea exceptiilor


P.S. Acest articol este dedicat programatorilor. Articolul prezinta concluziile la care am ajuns pana acum despre utilizarea exceptiilor. La inceput prezint pe scurt concluziile, apoi urmeaza explicatii mai detaliate, inclusiv pentru incepatori.


Pe scurt : reguli pentru utilizarea exceptiilor

1. "Nu prinde exceptia daca nu stii ce decizie sa iei pe baza ei !". Daca in acel bloc de cod nu ai suficiente informatii sau nu poti efectua operatiile necesare, lasa exceptia sa se propage.

2. "Nu inghiti exceptia !". Exceptia nu trebuie prinsa intr-o bucla vida, si de obicei nu este suficient sa printezi stack-ul. Exceptia este un mesaj care cere o decizie informata. In functie de gravitate, poti face 3 lucruri cu exceptia prinsa: logare + exit, logare + continuare sau "wrap" + re-throw.

3. "Exceptia se scrie in fisierul de loguri in ultimul loc in care este prinsa !". Nu se printeaza exceptia inainte de a fi aruncata mai departe pentru a nu duplica logarea ei.

4. "Nu loga stack-ul sau tipul exceptiei daca exceptia nu cere depanarea codului !". Daca nu poti deschide fisierul de configurare, explici asta utilizatorului specificand calea completa a fisierului, nu ii printezi un stack imens cu care oricum nu poate face nimic.

5. "Fa wrap la exceptii intre layerele aplicatiei !". Pentru a nu creste exponential numarul de exceptii pe care trebuie sa le trateze layerele superioare, transforma o exceptie mai specifica intr-una mai generala. De exemplu o eroare specifica Oracle sau MySql este transformata in "PersistenceException" de catre un layer de abstractizare a accesului catre baza de date.
  Nu uita sa conservi in textul noii exceptii informatiile relevante : contextul logic in care s-a receptionat exceptia (exemplu : "while connecting to server") si cauza exceptiei primite (exemplu : "connection refused"). Pentru erori neasteptate se poate conserva stack-ul initial ca si "cause" al noii exceptii.

6. " Cand tratezi exceptia, evita sa faci operatii care ar putea sa genereze alte exceptii !". Un caz obisnuit este apelul unei "functii membru" a unui obiect de care nu esti sigur ca nu este null. Daca este null, codul de tratare a exceptiei poate genera NullPointerException, ascunzand exceptia initiala.

7. "Cand creezi o exceptie, gandeste-te ce poate face utilizatorul cu ea !". Daca crezi ca utilizatorul metodei trebuie sa prevada o actiune specifica la o anume exceptie, deriveaz-o din Exception ca sa-l obligi sa o trateze. Daca arunci exceptia ca sa anunti ca ai descoperit la executie un bug in functionarea clasei, o poti deriva din RuntimeException, pentru ca cel mai probabil utilizatorul ar da exit() oricum.

8. "Utilizatorul obisnuit al unui program profesionist nu trebuie sa vada o exceptie cu stack decat daca codul are bug-uri". Exceptiile care anunta anumite evenimente prevazute trebuie transformate in mesaj explicativ, eventual internationalizat (in limba utilizatorului). Pentru exceptiile tip "eroare de functionare" se poate afisa totusi textul(cauza) exceptiei, cu restrictia ca nu poate fi internationalizat usor fara match-uri grosolane. Se pot printa anumite exceptii cu stack intr-un fisier special de trace/log care sa poata fi folosit in depanare.

9. Incearca sa conservi in exceptia pe care o re-throw toate informatiile relevante despre contextul aparitiei ei, in textul exceptiei si dupa caz in stack/cause. Textul exceptiei poate fi completat la fiecare layer de re-throw cu informatii despre contextul exceptiei (dar scurt si la obiect). Wrap-ul exceptiei in text, fara stiva completa, este util mai ales la executii remote unde clientul poate sa nu aibe informatiile necesare decodarii stivei.

10. "Nu crea un nou tip de exceptie daca utilizatorul metodei nu poate lua o decizie diferita in functie de acel tip de exceptie". Pentru erori fatale poti face un simplu "throw new RuntimeException("asert failed : ......").


Mesajul exceptiei contine 3 informatii importante :

1. (WHAT) Tipul exceptiei. De exemplu IOException se refere la un eveniment sau eroare de input/output. RuntimeException se refera la o eroare de programare care poate apare in functionarea normala a JVM, precum NullPointerException cand incercam sa folosim o referinta care nu pointeaza spre un obiect. Tipul exceptiei este folosit in a lua decizii diferite in locul in care exceptia este tratata.

2. (WHERE) Locul in care s-a generat exceptia. Acest loc este definit de stiva ("stack"-ul) de apeluri de la main() pana la locul in care s-a generat exceptia. In Java se poate extrage inclusiv fisierul si linia de cod in care s-a aruncat exceptia. Aceasta ajuta la depanarea codului cu probleme (debugging), dar este irelevant pentru evenimente care au fost prevazute in logica programului (probleme de conexiune).

3. (WHY) Motivul care a generat exceptia. Acesta este un mic text care explica cauza exceptiei. De exemplu un java.net.ConnectException poate fi cauzat de "Connection refused" primit de la server. Motivul este de obicei trimis utilizatorului sau este folosit la depanare.
 Puterea acestui text sta tocmai in faptul ca fiind un simplu String, el poate trimite transparent prin diferite layere informatii specifice logicii unui anumit layer. De exemplu ne putem inchipui ca layerul abstract de persistenta trimite pana la utilizator exceptia: PersistenceException("mysql index file table.MYI corrupted at offset dddd"). Aplicatia nu trebuie sa cunoasca detaliile bazei de date respective, dar utilizatorul poate primi o informatie foarte exacta despre locul problemei.







Exceptiile in detaliu
(inclusiv pentru incepatori)

Cuvant inainte

Am gasit destul de greu informatii despre "best practice" in utilizarea exceptiilor. De aceea m-am gandit sa combin informatiile gasite cu ideile proprii, in acest articol.

 Voi folosi limbajul Java ca exemplu, dar multe idei se pot folosi si in alte limbaje de programare. Java forteaza in multe situatii folosirea (tratarea) exceptiilor. Alte limbaje, precum C++, ofera doar optiunea de a le folosi.

Ce sunt exceptiile ? (pentru incepatori)

  Exceptiile au aparut din nevoia de a descrie mai clar ce trebuie sa faca programul in situatii mai speciale (de unde numele de "exceptie"). De obicei exceptia exprima o abatere de la flow-ul obisnuit al programului.

Sa luam exemplul urmator, imperfect, dar functional si exemplificativ. In programul de mai jos, incerc deschiderea fisierului "cucu.txt" si citirea primei linii din el.

  Operatia ar putea esua din mai multe motive, de exemplu fisierul poate sa nu existe, sau nu am dreptul de citire asupra lui. Pentru a nu verifica la fiecare operatie daca a aparut vreo problema, creez un bloc "try" in care pun operatiile asupra fisierului. Daca va apare o eroare, functia apelata va "arunca"("throw") o exceptie, fortand terminarea blocului "try".

  La sfarsitul blocului "try" exista un bloc "catch" care se executa in cazul aparitiei unei exceptii. In cazul de fata, afisez un mesaj, printez stack-ul unde a aparut exceptia si dau "exit()" pentru ca programul nu are rost sa incerce afisarea liniei care nu a putut fi citita.


import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;


public class Test {

public static void main(String[] args) {

File file;
FileReader fileReader;
BufferedReader fileBufferedReader;
String firstLine="";
file = new File("cucu.txt");

try {

fileReader = new FileReader(file);
fileBufferedReader = new BufferedReader(fileReader);
firstLine = fileBufferedReader.readLine();

}catch(Exception e){ //Catch any exception

System.out.println("Error reading file : " + file.getAbsolutePath());

//This is just to illustrate the exception content
//for this functional exception you should print 

   //an explanatory message, without the stack
e.printStackTrace();

System.exit(-1); //Terminate the program

}

System.out.println("First line is : " + firstLine);
}

}




In cazul in care fisierul nu exista, programul va afisa:

Error reading file : /media/muzica/Java/java_work/FileTreeSearch/cucu.txt
java.io.FileNotFoundException: cucu.txt (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:137)
at java.io.FileReader.(FileReader.java:72)
at Test.main(Test.java:16)


  De fapt, Java chiar imi impune sa tratez exceptiile pe care le-ar putea genera "new FileReader(file)" si "fileBufferedReader.readLine()". Exemplul arata ca aceste cazuri se pot trata separat de firul logic al programului, fara a fi nevoit sa verifici cu un if() rezultatul fiecarei operatii.

  Atunci cand programul intalneste o situatie neobisnuita, poate "arunca" o exceptie ("throw"). Daca programul ajunge in acel punct, el va renunta la continuarea executiei obisnuite, si va muta executia la codul de "tratare" a acelei exceptii.

  Spunem ca exceptia se "propaga" prin blocurile de program apelante pana la primul bloc care "prinde" ("catch") acel tip de exceptie.

  Exceptiile constituie o facilitate puternica a limbajelor de programare, ajutand scrierea mai clara si mai simpla a algoritmilor. Cand nu sunt folosite corespunzator insa, pot sa aibe efectul contrar. O situatie des intalnita este aceea cand exceptia se propaga "neprinsa" pana in functia "main()", generand terminarea programului, precum celebra "Null pointer exception". Astfel de exceptii sunt determinate de erori de programare. Exceptia incerca sa transmita locul (stack-ul) in care s-a petrecut problema pentru a ajuta depanarea codului.

  Un lucru foarte important despre exceptii este ca ele "transporta" un mesaj de la locul in care au fost "aruncate" pana la locul in care au fost "prinse" sau pana la utilizator daca nu sunt prinse.

Exista doua tipuri mari de exceptii.

1. Exceptii generate de erori de programare  (precum "Null pointer exception") sau probleme legate de lipsa resurselor (RAM). In Java aceste erori sunt derivate din RuntimeException si nu forteaza utilizatorul sa trateze exceptia. Se presupune ca de cele mai multe ori decizia optima este propagarea pana la utilizator si terminarea programului, dar se pot crea si mecanisme de restartare a modulului cu probleme (re-creare clasa).

2. Exceptii care exprima "mesaje" despre situatii speciale, dar care nu constituie neaparat erori de programare (de exemplu un server detecteaza ca un client a inchis conexiunea). Aceste mesaje se propaga din locul in care au fost generate pana la apelantul care poate lua o decizie.

 Ce aduc in plus exceptiile fata de un "return code"
  • Pentru functiile care returneaza tipuri de date simple (exemplu int), nici o valoare nu poate fi rezervata pentru a semnala o eroare. Transformarea unui text in numar poate returna orice numar de acel tip. Nu putem rezerva o valoare pentru a semnala un input care nu reprezinta un numar. Aruncand o exceptie se poate comunica acea eroare de procesare. In cazul String se poate folosi intr-adevar valoarea null
  • Exceptia transmite si un text explicativ al erorii aparute, si chiar si stiva de executie pana la locul detectarii erorii. Codul utilizator nu trebuie sa trateze toate cazurile de eroare posibile, dar poate transmite mai departe ce problema a fost identificata, unde si motivul.
  • Exceptia nu se pierde daca nu este tratata (precum codul de return ne-preluat). O functie poate lasa sa se propage toate exceptiile de un anumit tip la un nivel superior unde se poate lua o decizie. Se evita astfel propagarea unor coduri de eroare complicate pana la locul propice tratarii.
  • Exceptiile pot constitui variante mai rapide ca executie pentru maparea mai multor situatii speciale cu blocurile lor de tratare. Daca un cod de eroare ar trebui trecut printr-un "switch", cand se arunca o exceptie se poate calcula exact locul in care ea va fi prinsa, deci controlul programului se poate da direct acolo, fara a mai face selectia in functie de codul de eroare. Aceasta selectie se poate face deja in momentul compilarii.
  •  Exceptia incapsuleaza mai multe informatii (stack, clasa, text) intr-un mod "cunoscut" de toate modulele, in sensul ca este suportat de limbaj. A implementa un sistem separat de comunicare a situatiilor speciale prin coduri de eroare ar necesita ca fiecare layer sa cunosca acel tip de obiect si sa aibe grija sa-l re-transmita pana unde poate fi procesat.

Ce NU sunt exceptiile ?
  •   Exceptiile nu sunt GOTO-uri pe care sa le folosesti pentru a iesi din bucle de procesare, pentru ca au un oarecare overhead care poate afecta performanta (crearea obiectului exceptie). Exceptiile trebuie folosite pentru ceea ce au fost create (cazuri ne-obisnuite), altfel scad si claritatea codului. 
  •  Exceptiile nu sunt un mod de a dialoga cu utilizatorul. Cu exceptia micilor programe de uz personal sau intern companiei, un program trebuie sa traduca exceptiile care fac parte din logica programului in mesaje pe intelesul utilizatorului, deci fara stack.
  •  Exceptiile nu sunt un mod de a returna un String (rezultatul unei procesari). Pentru calea nominala (normala) de executie a programului exista "return".

Actiuni posibile la tratarea exceptiilor

a) daca exceptia notifica o eroare grava de programare ("assert failed")
   - log exceptie pe nivel FATAL, cu stack
   - utilizatorul poate primi stack-ul exceptiei sau, mai elegant, un mesaj "eroare neasteptata" cu referire la log pentru mai multe informatii
   - programul se termina

b) o preconditie a functionarii programului nu este indeplinita, de exemplu nu se poate deschide fisierul de configuratie la pornirea aplicatiei
   - log pe nivel FATAL cu explicarea preconditiei, de preferinta fara stack
   - utilizatorul primeste un mesaj "friendly" despre ce lipseste, unde, si ce se recomanda pentru remedierea problemei
   - programul se termina

c) daca exceptia notifica un eveniment relativ important dar prevazut de programator (clientul s-a deconectat)
  - log pe nivel corespunzator gravitatii DEBUG, INFO, WARN, ERROR (stack-ul cel mult la ERROR)
  - utilizatorul primeste un mesaj "friendly" despre eveniment, daca este cazul. Din exceptie se va loga cel mult cauza exceptiei - exemplu "Connection refused", nu si stack-ul sau tipul clasei-exceptie. Pe utilizator nu il intereseaza unde a fost detectat evenimentul.
  - programul executa eventul actiunile specifice evenimentului (clean-up, reconectare, etc)


 Cand se face wrap la exceptii

O problema in proiectele mari este gestiunea exceptiilor "checked" care obliga la tratarea lor (in Java). Din acest motiv, multi programatori ajung sa arunce din clasele lor exceptii "unchecked", care nu obliga la tratarea lor. Ca urmare, utilizatorul bibliotecii trebuie sa verifice la fiecare apel ce exceptii posibile ar dori sa trateze.

Eu personal cred ca obligativitatea de a lua o decizie explicita in cazul exceptiilor (tratez sau dau mai departe) este un lucru bun. Pentru a nu deveni insa o corvoada, fiecare layer trebuie sa proceseze un numar redus de exceptii, specifice nivelului sau de procesare. Exceptiile de pe nivelele inferioare vor fi incapsulate (wrap) in exceptii mai generale, specifice acelui layer.

De exemplu o exceptie generata de "disk full" poate deveni o exceptie de StorageException la nivelul de jos al bazei de date, o exceptie de OracleSqlQueryException la nivelul de procesare SQL al bazei de date, o PersistenceException la nivelul abstract de persistenta, o ActorCreationException la nivelul frameworkului de bussiness logic si, in final, o CustomerCreationException la nivelul de implementare a unui CRM.

 Important este ca, pe cat posibil, layerele sa nu fie nevoite sa proceseze exceptii specifice deciziilor de la alt layer.

 Singurul lucru care este recomandat sa fie lasat sa se scurga (vezi "leaky abstraction") este textul exceptiei, care completat la fiecare layer poate crea o imagine de ansamblu a cauzei exceptiei pentru utilizator, singurul care poate intelege transversal sistemul.


 Exceptiile chained


 Atunci cand exceptiile sunt re-thrown, se poate atasa exceptia initiala la noua exceptie ca si "cause". Astfel se creeaza un lant (chain) de exceptii. Aceasta poate ajuta la depanarea unor erori de programare care se propaga prin layere de abstractie.

  Daca situatia poate fi explicata doar cu datele de pe acel layer, iar locul de unde vine este irelavant, atunci este recomandabil sa nu se pastreze stack-ul initial, deci nu este necesar sa se faca "chaining". Informatia se poate condensa eventual in textul exceptiei.
  Daca exceptia se propaga remote (RMI), este foarte recomandabil sa se pastreze doar portiunea de stack care este cunoscuta sigur de apelant, altfel clientul nu va putea prelucra exceptia.

 Stack-ul merita sa fie "chained"  doar in cazul exceptiilor care ies din bussiness-logic, semnaland posibile probleme de programare.


Concluzie

  Exceptiile constituie o facilitate puternica a limbajelor moderne de programare, facilitate care aduce avantaje doar folosita corespunzator. Folosirea productiva a exceptiilor este un subiect destul de extins, si inca suscita multe discutii contradictorii.
  Ceea ce am incercat aici a fost doar o mica ridicare de cortina asupra subiectului, ca o incitare la dialog pe aceste teme. Unele reguli pe care le-am prezentat se pot doveni ne-optime in anumite cazuri, si aici astept feed-back-ul celor interesati in sectiunea de comentarii.


Facebook