Vroiam să scriu articolul ăsta în weekend, dar am fost prea ocupat să dau cu capul de-o problemă întâlnită mult prea des. De multe ori sunt pus în situaţia să estimez durata unui proiect şi să-mi pun singur deadline-ul. Din reflex/obişnuinţă sau din cauze subconştiente, mă ia gura pe dinainte şi nu de puţine ori setez deadline-urile în zilele de luni.

Foarte proastă alegere. De ce? Pentru că în majoritatea cazurilor, am pierdut o parte din weekend (sau chiar tot weekend-ul) lucrând. La fel de prost aleasă e şi ziua de vineri pentru că dacă nu termin la timp, voi lucra în weekend pentru a fi totul gata până luni dimineaţa.

Şi totuşi, chiar dacă pare foarte evident, nu mi-am dat seama de lucrul ăsta până nu am citit cartea de care vorbeam într-un articol anterior.

Ok, revenind... ce am zis mai sus nu e valabil doar la deadline-uri ci la orice obiectiv intermediar din ciclul unui proiect. Ca project manager, dacă setezi un obiectiv pentru luni sau vineri, oferi timp echipei să repare/finalizeze lucrurile în weekend. Problema cu astfel de abordări, pe lângă oboseală, e faptul că pierzi oarecum controlul şi nu poţi să ştii cât anume s-a muncit în timpul săptămânii şi cât în weekend. Iar din acest motiv, e posibil să faci estimări greşite în viitor, formând un cerc vicios care poate întârzia mult un proiect.

Bun, şi dacă nu e clară concluzia, data viitoare când negociezi/planifici un deadline/obiectiv, încearcă să-l stabileşti la mijlocul săptămânii. Sigur, acest lucru nu garantează succesul, dar va reduce drastic munca din timpul weekend-ului, astfel că se poate determina progresul proiectului într-un mod mult mai realist.

Multă lume se plânge de lipsa locurilor de parcare, dar la foarte puţini le pasă!

De ce zic asta? Pentru că am văzut destui oameni parcând fără să se gândească la alţii. Da, unii parchează pe două locuri doar pentru a-şi putea deschide larg uşile, unii parchează la un metru de bordură, încurcând circulaţia, alţii blochează total intrarea în parcare. Şi câte şi mai câte.

Data viitoare când parchezi, gândeşte-te şi la alţii. Gândeşte-te că dacă parchezi cu jumate de metru mai în faţă, poate mai încape cineva în spatele tău. Bineînţeles, nu zice nimeni să parchezi milimetric faţă de alte maşini, dar încearcă să te încadrezi în nişte limite de bun simţ. Eu întotdeauna încerc!

Ieri, la birou, a reuşit un „vecin” să mă enerveze şi să mă ameninţe că-mi sparge roţile dacă mai parchez în faţa garajului său. Atenţie! Nu i-am blocat niciodată garajul, poate să intre şi să iasă din garaj, chiar destul de lejer aş zice eu. Dar nu! El este deranjat de maşina mea, parcată la o distanţă acceptabilă. Adică... WTF? Nu poate să intre direct în garaj, ci mai trebe să mişte puţin de volan?

N-am stat să mă cert cu el (şi acuma parcă-mi pare rău) ci am căutat un alt loc de parcare. Însă săptămâna viitoare probabil nu voi găsi alt loc de parcare şi-o să parchez tot acolo.

(Sper că nu) Va urma...

...în cazul meu, a fost pavată de către David Alen cu a sa carte Getting Things Done (GTD).

Am cumpărat cartea în urmă cu aproximativ o lună, iar din copertă vă puteţi da probabil seama care este subiectul principal. Despre carte se pot scrie multe (şi probabil o voi face, în viitor), dar momentan vreau să mă opresc asupra unei singure probleme (şi rezolvarea dată de carte, bineînţeles): email-ul.

Nu primesc foarte multe email-uri într-o zi, dar majoritatea lor necesită o acţiune, fie că e vorba de un simplu răspuns, fie ceva mai complex. Până nu demult, ţineam toate mail-urile în Inbox (plus câteva directoare) şi nu de puţine ori mi s-a întamplat să uit să răspund la un mail pentru că efectiv se pierdea în multitudinea de mesaje.

De vreo două-trei saptămâni lucrul ăsta nu mi se mai întamplă, iar soluţia e surprinzător de simplă. Ca prim pas, se creează doua directoare @ACTION şi @WAITING FOR. Am folosit caracterul @ în numele directoarelor doar pentru a fi afişate primele, înaintea celorlalte directoare. Apoi, toate mesajele din Inbox care necesită un răspuns (sau o acţiune oarecare), sunt mutate în @ACTION. Restul mesajelor din Inbox sunt mutate într-un director nou numit Archive. În @WAITING FOR sunt puse mesajele care au nevoie de o acţiune, dar care acţiune nu poate fi făcută imediat, ci... aşa cum îi spune şi numele, se aşteaptă după ceva.

Ok, în momentul de faţă Inbox-ul trebuie să fie zero, iar acţiunile ce trebuie făcute sunt clar delimitate. Când un nou mail soseşte, trebuie doar să mă hotărăsc dacă:

1. răspund pe loc (în cazul în care durează mai puţin de 2 minute)
2. mut mail-ul in @ACTION sau în @WAITING FOR pentru procesare ulterioară
3. email-ul nu are nevoie de nici o acţiune, deci îl mut în Archive

Astfel, ştiu tot timpul ce anume a rămas nefinalizat. Bineînţeles, după ce prelucrez un email din @ACTION, îl mut in Archive.

E incredibil cât de mult contează o asemenea tehnică „rudimentară”. Nu-i aşa că-ţi vine să te întrebi „cum de nu m-am gândit eu la treaba asta”?

Pentru cei îngropaţi în mormane de email-uri, sper să vă fie de folos!

Ieri am fost pe la mall (Polus) pentru diverse cumpărături. Printre altele, Raluca a vrut să-şi cumpere ciorapi, aşa că am intrat la standul Mondex unde am fost foarte surprins să văd un Ubuntu 6.06 LTS pe computerul de la casă.

Felicitări Mondex şi în special felicitări firmei care a implementat (şi promovat) soluţia de gestiune magazin având linux la bază!

...să vizitaţi neapărat Plitvice Lakes (se citeşte „Plitviţe”). Pozele de mai jos sunt de ajuns pentru a vă convinge, iar alte cuvinte pentru a descrie ce e acolo sunt de prisos. Totuşi vă spun că Plitvička jezera(denumirea în croată) este o rezervaţie naturală, patrimoniu Unesco, formată din 16 lacuri dispuse în terase.

Ok, şi dacă aţi ajuns cu cititul până aici, aflaţi că am vizitat şi capitala Croaţiei, Zagreb. Oraşul nu are atracţii turistice, poate doar catedrala din pozele de mai jos, dar este un oraş curat, aranjat şi cu multe parcuri. O adevărată plăcere să te plimbi prin el, deşi multe clădiri au căzut pradă graffiti-ului. În centrul oraşului se găseşte chiar şi o grădină botanică. De fapt, o mini-gradină botanică, deoarece nu cred că e nici 1/8 din grădina din Cluj.

Şi acum, pozele:

În ultimele 2 luni cred ca am fost de vreo 5-6 ori la dentist. Nu pentru probleme majore, ci... o carie aici, una dincolo, etc. Ieri, când am ieşit de la dentist, m-am gândit că ar fi un subiect bun pentru blog :)

De ce merge lumea la dentist doar când se instalează durerea? De ce nu merge tot la 6 luni aşa cum e normal?

1. Din lipsă de bani? O simplă consultaţie nu costă foarte mult.
2. De frică? Din nou, o carie descoperită la o consultaţie e reparată (aproape) fără dureri.
3. Din neştiinţă? Nu cred.
4. Din pură ignoranţă pentru propria sănătare? BINGO!

Câţi dinţi ar fi fost salvaţi de controale la 6 luni? Câţi bani s-ar fi economisit? Câţi pensionari ar avea dinţi în loc de proteze?

Scriind acest articol, am deschis calendarul (Google Calendar) şi mi-am notat ca peste 6 luni să ma duc iar la un control.

Când ai fost ultima dată la dentist?

Sau „don't break the chain” dacă e s-o dăm în englezisme.

În ultima vreme (ultimul an şi ceva) numărul lucrurilor şi al problemele la care trebuie să fac faţă zi de zi a crescut continuu. Nu e vorba doar de project management ci şi de alte lucuri mărunte (probleme cu maşina, facturi, tot felul de acte, impozite, angajări/concedieri, etc) care se adună şi-ţi mănâncă timpul liber. Toate astea, în detrimentul sănătăţii.

De vreo 6 luni am început să citesc tot felul de site-uri despre productivitate, dezvoltare personală, managementul timpului, metode de motivare, etc, dorind să fiu mai organizat, mai productiv şi cu mai mult timp liber!

Îmi amintesc foarte clar sfatul dat de Jerry Seinfeld în acest articol, citit cu destul de mult timp în urmă, sfat care până azi nu l-am pus deloc în practică.

Pe scurt, trebuie să-ţi propui să faci un lucru zi de zi, fără întrerupere. Cu cât îl faci mai mult, cu atât vei vedea rezultatele investiţiei tale şi vei avea din ce în ce mai multe motive să continui. E ca un lanţ.

Având în vedere (la propriu!) burta şi kilogramele în plus adunate în ultima perioadă, astăzi am pus prima verigă într-un lanţ: să fac exerciţii fizice zilnic, cel puţin 10 minute. Ştiu, e puţin dar e un început.

Teoria e foarte faină, să vedem cum stăm cu practica!

Deschizându-mi RSS reader-ul ajung pe slashdot.org unde găsesc link-uri spre mai multe pagini cu idei de păcăleli. Distrându-mă de ce vedeam pe acolo, am ajuns la pagina asta şi pe loc mi-a încolţit o idee asemănătoare. Aşa că m-am pus pe treaba, farsa având ca ţintă un client pe care-l cunosc bine şi ştiu că nu se supără (sau cel puţin aşa sper).

Pe scurt, vreau să inversez toate link-urile de pe un „site”, având acces la codul sursă, bineînteles. Adică un link se transformă în knil nu. Restul textului de pe site rămâne neschimbat iar URL-urile funcţionează în continuare. Am pus site între ghilimele deoarece nu e vorba de un site cu mii de useri online ci e vorba de un backend la care au acces 5-6 persoane.

Soluţia tehnică se bazează pe funcţionalitatea de output buffering pe care o oferă PHP-ul. Funcţia de mai jos este un callback pentru ob_start();

[code lang="php"]function link_reverse($buffer){
  if (preg_match_all("|(.*)|U", $buffer, $regs, PREG_PATTERN_ORDER)){
    for ($i = 0; $i < count($regs[1]); $i++){
      $text = $regs[1][$i];
      if (!eregi("^[a-z0-9\.\ \-]*$", $text)){
        //nu avem doar un simplu text in interiorul ancorei, ignoram
        continue;
      }
      $reverse = "";
      for($j = strlen($text) - 1; $j >= 0; $j--){
        $reverse .= $text[$j];
      }
      $buffer = str_replace(">" . $text . "<", ">" . $reverse . "<", $buffer);
    }
  }
  return $buffer;
}[/code]

Aveţi grijă mâine. Noapte bună!

Continuând seria despre project management, încep azi cu alt citat (de data aceasta tradus/adaptat) din cartea menţionată anterior, adăugând încă un motiv la afirmaţia că mulţi programatori sunt supra-optimişti:

De cele mai multe ori, oamenii (dintr-o echipă) se gândesc la cât de multe pot să facă, planificând astfel întregul proiect cu gândul la cât de mult pot să lucreze. Un lucru nu tocmai bun, deoarece ar trebui să se gândească la cât de puţin lucrează de fapt.

Din lungul şir de greşeli, probabil greşeala asta am făcut-o de cele mai multe ori, efectul fiind în cel mai „bun” caz multe nopţi nedormite, iar în cel mai rău caz vă imaginaţi voi...

Cred că e un lucru evident faptul că dintr-un program de 8 ore pe zi, nu se lucrează 8 ore. Ai pauză de masă, ai pauză de cafea/ţigară, mai ai o sedinţă, un telefon, etc. Ajungi să lucrezi doar 4-5 ore pe zi. Dacă mai citeşti un email, o ştire, nişte RSS-uri, forumuri, bancuri trimise de colegi, situaţia e clară iar productivitate tinde spre zero. Dar despre asta o să vorbesc într-un articol viitor.

Şi totuşi, e greu să treci peste modul de gândire „cât de mult”. Ştii că nu lucrezi 8 ore pe zi, dar îţi planifici proiectele ca şi cum ai lucra 8 ore non-stop. Multiplică asta cu numărul de oameni din echipă ca să vezi dimensiunea dezastrului ce te aşteaptă.

I love deadlines. I like the whooshing sound they make as they fly by. (Douglas Adams)

Deşi am câţiva ani de experienţă în spate (a se citi câţiva ani de greşeli) uneori mai fac greşeala asta şi nu-mi vine să cred. Analizând situaţia în timp, am identificat 3 motive:

1. La început mă supra-estimam. În naivitatea mea, chiar credeam că pot lucra 8 ore pe zi non-stop, la productivitate maximă. Oricât de genial(ă) eşti, lucrul ăsta e imposibil de atins.
2. După un timp am ajuns la concluzia evidentă că ziua de lucru nu are 8 ore, dar parcă nu eram conştient de acest fapt. Asta e un fel de „nu vezi pădurea din cauza copacilor”. Recunoaşterea şi conştientizarea e primul pas spre „vindecare”.
3. Am un client nou, vreau să-l impresionez şi-i promit „luna de pe cer”.

Toate astea duc la o muncă enormă peste program care pe o perioadă îndelungată nu e tocmai sănătoasă. Iar dacă îţi faci un raport între banii ceruţi pe proiect şi munca depusă îţi dai seama că sclavii o duceau mai bine.

Ţine seama de toate astea când planifici următorul proiect, când promiţi rezolvarea unui task şi în special când semnezi un contract!

Folosesc SVN de multă vreme şi îşi face treaba bine. Dar, din când în când primeam erori de genul:

svn: Connection closed unexpectedly

urmate de

svn: Berkeley DB error for filesystem '/path/to/repo/db' while opening environment:
svn: Permission denied

şi altele asemănătoare. Până azi, reparam erorile cu un mic script:

svnadmin recover /path/to/repo/
chown -R svn.svn /path/to/repo/
chmod -R g+w /path/to/repo/

În ultimul timp însă, frecvenţa erorilor s-a înmulţit şi a devenit insuportabil să faci un update sau commit.

Aşa că... am început să caut o soluţie mai bună decât scriptul meu. Căutările au început de la documentaţia oficială unde, căutând după Berkeley DB am aflat că există un alt layer disponibil pentru stocarea datelor, layer care m-ar scăpa de acele erori. Astfel, am început migrarea către FSFS(layer-ul de care vorbeam) şi după încă două minute de citit documentaţia, am creat următorul script:

cp -R -p /path/to/repo/ /path/to/backup/repo/ #inainte de toate, facem un backup
svnadmin dump /path/to/repo/ > /tmp/repo_dump
rm -rf /path/to/repo/
svnadmin create /path/to/repo/ --fs-type fsfs #facem un repo nou, cu FSFS
svnadmin load /path/to/repo/ < /tmp/repo_dump
rm -rf /tmp/repo_dump

După alte câteva minute de aşteptare (repo mare), am obţinut ce vroiam plus o reducere a spaţiului utilizat pe disc cu aprox ~35% (irelevant, dar merită menţionat :P ). Acuma nu-mi rămâne de făcut decât să repet aceeaşi chestie de vreo 5 ori, pentru toate proiectele.

Ps: FSFS e setat ca layer de stocare implicit începând cu Subversion versiunea 1.2 (versiunea actuală a ajuns cu numărătoarea la 1.4).