marți, septembrie 21, 2010

IBM Lenovo ThinkPad T60

Chiar daca sunt aproape total dedicat dezvoltarii de soft, trebuie sa recunosc ca in final tot la o masina fizica ajungem si deci este foarte important unde dezvoltam aplicatiile nostre (in fapt si masina pe care lucram influenteaza productivitatea noastra - pentru ca aplicatia Java ruleaza intr-o masina virtual care este instalata peste un sistem de operare care sta instalat in final pe o masina fizica). Incerc in acest post sa fac un review pentru cel mai bun calculator cu care am avut ocazia sa lucrez IBM(Lenovo) ThinkPad T60.

De-a lungul timplui am avut ocazia sa lucrez pe o multitudine de sisteme desktop/laptop atat acasa cat si la serviciu. Trebuie sa recunosc ca nimic nu m-a impresionat precum ultima masina pe care am avut-o in dotare: ThinkPad T60. Pe ea apareau atat siglele Lenovo cat si IBM – se pare ca dupa de IBM a externalizat partea de hardware spre Lenova le-a mai permis sa foloseasca logo-ul IBM pentru cativa ani (acum toate masinile mai noi din seria ThinkPad au doar sigla Lenovo). ThinkPad T60 este o masina pe care am simtit-o cu adevarat a indeplini majoritatea pretentiilor mele ca functionalitate si design in ceea ce fac in viata de zi cu zi – dezvoltarea de aplicatii. . Cred ca foarte greu m-ar putea convinge cinava ca un alt laptop este mai bun – pur si simplu am simtit ca este o masina foarte, foarte bine facuta.

Clasa T este clasa de laptopuri ThinkPad pentru categoria business – se poate simti asta din liniile drepte ale carcasei fara a pune la socoteala performantele interne ale masinii. Este foarte compact fara nici un fel de infloritura in partea de design - asa cum au din nefericire mai toate calculatoarele destinate utilizatorilor obisnuiti. T60 are o tastatura perfecta – de negasit la o alta masina, functioneaza fara sa produca zgomot aproape deloc, are o carcasa plata si cu linii drepte si fara inflexiuni la atingere si foarte rezistenta, baterie extinsa tine foarte mult, are balamale din otel care functioneaza impecabil – acestea sant cateva din caracteristicile externe ale masinii.

Referitor la performantele interne ale masinii – pare a fi facut pentru programare, multimedia sau orice implica procesare. Cateva dotari pe care le poate avea un T60. Procesor: Intel Mobile Core 2 Duo T5600 2x1.83GHz 2MB L2 cache 64biti. Eu am avut la dispozitie 3GB DDR2 PC6400 800MHz (permite 4M memorie). Perfomante la randare video prin placa video: ATi Mobility Radeon X1400 512MB vRam. Celerometer: hardul este monitorizat de un dispozitiv special - accelerometer - care, in functie de pozitia laptopului si de miscarile sesizate, opreste temporar hard disk-ul pentru a il proteja pe acesta (si implicit informatia de pe el) de eventualele socuri mecanice.

Uitandu-ma pe magazinul firmei producatoare am observant ca Lenovo promoveaza in present alte laptopuri din clasa T: T410 si T510. Nu stiu daca se mai pot achizitional T60/T61 noi - cele vechi (second hand) sunt pana in 500$ pe ebay.com si alte site-uri. Ce nu-mi place la T410 este hub-ul de 3 porturi USB care ii da un aspect neplacut pe latura stanga. La T510 nu-mi place restrangerea tastaturii pentru a face loc difuzoarelor in lateral (este mult mai pronuntata decat la T410). De asemenea in review-uri se pare ca sunt problem cu tastatuta la ambele modele – se produc inflexiuni ale carcasei la atingerea tastelor.

Ma voi referi la cateva aspecte exterioare (bune si mai putin bune) pe care le-am observat in ultimii doi ani la T60 (nu sunt neaparat cele mai importante dar pe mine m-au incantat/dezamagit):

Avantaje:
  • ThinkVantage – foarte usor de folosit in administrarea masinii – detectarea retelelor wireless e foarte intuitiva (accesss connection)
  • Butoanele multimedia foarte bine asezate si foarte intuitive
  • Fara zgomot la racire – caracteristica aceasta nu am mai intalnit-o la alte sisteme
  • ThinkLight – luminarea tastaturii pe timp de noapte
  • Se deschide perfect la 180 de grade
Dezavantaje:
  • touchpad and UltraNav buttons sunt putin prea jos si pot fi atinse din greseala daca nu lucrezi la masa
Lucruri interesante:
  • Water resistant – foarte interesant a fost un caz in care unul din colegii mei a varsat suc si si-a stricat tastatura (sucul nu e ca apa)
  • Luminozitate crescuta – am avut ocazia sa-l compare cu un T61 si surprinzator T61 nu permitea acelasi nivel de luminozitate (alti colegi aveau T61 in dotare)
Prezentare video:

miercuri, septembrie 15, 2010

Unelte utile

O lista de unelte care le consider utile (majoritatea sunt gratuite) in orice mediu de lucru - la final am pus cateva specifice programarii (in Java). Am sa incerc sa intretin lista in timp.

Acest post este un test - editarea lui s-a facut printr-un mai trimis la o adresa de email - o facilitate a blogger.com.


  • Eclipse
  • Hermes JMS
  • SoapUI
  • Navicat (MySQL)

--
Cristian Olaru
weblog: http://olaru.blogspot.com
mobile: 0743163039

marți, septembrie 14, 2010

Clean Code

Clean Code este o carte scrisa de Robert C. Martin - care incearca sa surprinda experienta lui in scrierea de cod, experienta care se intinde pe cateva decenii (in carte se remarca cum regulile s-au schimbat de-a lungul timpului odata cu evolutia limbajelor de programare). Am incercat sa citesc cartea (versiunea fizica) dar nu am avut timp decat pentru primele 5 capitole si sa le rasfoiesc pe celelate in una din saptamanile de vacanta din acest an - am remarcat cu ocazia asta cat de putin timp avem sa citim in mod clasic.

In aceasta carte totul este de bun simt si ne poate salva de cosmarul debugingului continuu - cateodata ma gandesc ca printre programatori sunt unuii (cei care fac mentenanta) care nu fac altceva decat sa caute in gunoaie (codul vechi). Din cate imi dau seama a aplica regulile din Clean Code impreuna cu TDD (Test Driven Development) reprezinta cea mai buna metoda de a creste calitetea interna a produselor software - a le face valoroase pe termen lung din perspectiva dezvoltarii ulterioare/mentenantei.

Clean code pleaca de la urmatoarea premiza: cu siguranta codul pe care il scriem astazi va fi citit de catre cineva (toti speram ca nu noi) in viitor. De acea claritatea lui este foarte importanta. A fi usor de citit implica si a fi usor de modificat. Daca dezvoltarea unui proiect dureaza pana intr-un an, metinera lui (mentenance) va dura mai multi ani. Aceasta implica fixare de bug-uri, adaugare de mici feature-uri etc, care implica interactiuni cu codul respectiv. Desigur se poate face orice in debugger unde se poate vedea absolut orice. Dar este mult mai complicat decat a lucra cu un cod clar care exprima de la sine pentru ce a fost scris - intr-un fel exprima businessul implementat.

Primul accent pus in carte este pe numele pe care le vom da claselor, metodelor, campurilor care compun aplicatiile noastre. Ele trebuie sa exprime de la sine scopul si contextul in care sunt folosite. Nu trebuie sa ne zgarcim cu lungimea pe care o va avea numele lor - cel mai important este ca ele sa fie cat se poate de expresive si clare. Codul trebuie schimbat si modificat pana indeplineste criteriile de calitate stabilite de noi - nu trebuie sa ne fie frica sa intervenim de oricate ori este nevoie (este o practica in metodologiile de agile de a partaja codul intre toti membrii echipei si a permite tuturor sa il modifice cu incredere)

Surprinzator sau nu in capitolul dedicat comentariilor suntem sfatuiti sa nu le folosim deloc - doar in anumite situatii. Idea de a pune un comentariu care sa dubleze codul comentat nu este o idee buna - la o urmatoare interventie asupra codului comentariul poate deveni desincronizat fata de cod. Acest lucru nu poate introduce decat confuzie - codul trebuie sa exprime de la sine ceea ce implementeaza. Pentru aceasta trebuie sa exprime intentia noastra in asa maniera incat comentariile sa fie de prisos.

Un aspet foarte important este modul in care scriem metodele (care dau functionalitatea claselor). Autorul ne propune metafora unui ziar (newspaper) in care stirile nu sunt prezentate toate in intregime pe prima pagina. Pe prima pagina ni se prezinta titlul si un rezumat urmand o trimitere la urmatoarea pagina unde este intreg continutul. Trebuie sa distingem astfel intre nivelurile de abstractizare dintr-o metoda si sa nu le amestecam. Asa vom avea pentru fiecare functonalitate implementata un arbore de metode care abstractizeaza pe niveluri diferite functionalitatea. Metodele care se refera la un acelari aspect de domeniu vor fi pastrate impreuna - intr-o aceasi unitate de compilare. Int-o metoda trebuie sa faca un singur lucru - daca vrem sa facem si altceva o putem face intr-o alta metoda pe care o vom apele.

Testele unitare/integrare trebuie sa ghideze dezvoltarea - in fapt codul pe care il scriem o sa fie mai ingrijit daca o sa facem teste pentru el pentru ca este dificil sa testam un cod complicat (e greu de exemplu sa introducem multe mock objects daca avem prea multe dependinte in metoda noastra, e greu sa facem prea multe assert-uri daca metoda noastra face mai multe lucruri). Testele trebuie sa fie punctul de executie pentru orice functionalitate nou pa care o introducem in aplicatie (nu trebuie sa rulam toata aplicatia pentru asta si sa folosim logging pentru a vedea ca ce am scris merge). Teoretic deployerea aplicatiei ar trebui sa o facem foarte rar, la final - dupa ce am dezvoltat local ghidati de teste unitare/integrare. De asemenea sugereaza sa folosim teste (unitare/integrare) si pentru a ne acomoda cu noile librarii pe care vrem sa le introducem in proiect.

Clean code este un coplement la idea de stil de codare sau cea de conventii de nume:

  • stil de codare - reprezinta un set consistent de reguli de sintaxa care trebuie respectate de intreaga echipa pentru coerenta codului. Se cunosc o serie de astfel de codari - Eclipse, Sun(Oracle), Apache; ele pot fi setate la nivel de IDE pentru a oferi coerenta in cod
  • conventii de nume - un set de cosistent de reguli pentru denumirile care se folosesc intr-o aplicatie pentru clase, metode, campuri - spre exemplu sufixarea anumitor categorii de clase (XyzService, XyzAction, XyzDAO)
In carte sunt enumerate si unele principii stiute de programare carora treuie sa le acordam atentia cuvenita: Open Closed Principle, Single Responsibility Principle si Law of Demeter.