Plăcerea de a scrie cod de calitate

Plăcerea de a scrie cod de calitate mi-a fost insuflată de doi oameni pe care îi respect foarte mult și sunt tare recunoscător că am avut ocazia să lucrez alături de ei. Pe amândoi i-am considerat mentori și modele în perioada în care am lucrat la Zitec. Cei doi sunt Ionuț VODĂ și Lucian DAIA. Ambii fac parte din echipa de conducere unde Ionuț este CTO, iar Lucian este Chief Software Engineer.

Amândoi au standarde înalte de calitate pe care le pun în practică așa că am luat decizia să îi urmez și să le ascult sfaturile. A fost o decizie inspirată pentru că după ce am început să mă preocup de calitatea codului munca mea a căpătat o nouă dimensiune. Am început să mă bucur atât de rezultatul muncii cât și de procesul de a ajunge la soluție într-un mod elegant.

Lucian mi-a făcut cunoștința cu PHP MessDetector un tool de analiză statică pe cod. Se întâmpla prin anul 2011 când am început să lucrez pe unul din proiectele pe care el îl conducea. A avut mare răbdare să îmi explice conceptele și ce înseamnă fiecare indicator. Apoi ne-am chinuit împreună să îl facem să meargă. Foarte puțin mai conta ora de încheiere a programului pentru că eram tare curios să văd rezultatele. L-am rulat pe toate proiectele pe care le făcusem până la momentul respectiv. Am găsit variabile nefolosite, clase foarte lungi și metode greu de înțeles datorită numărului mare de puncte de decizie.

Tot Lucian mi-a prezentat conceptul de refactorizare și am lucrat împreună să optimizăm un script care prelucra date foarte multe extrase din AppStore. Am rescris codul pentru a fi mai ușor de înțeles și de extins. Am optimizat interogările în baza de date pentru a obține o viteză cât mai bună pentru utilizatori. Mi-a recomandat cartea Code Complete pe care m-am grăbit să o descarc și am citit-o cu mare interes.

Cu Ionuț am început să lucrez tot în 2011. El avea un stil diferit. Fiind implicat în mai multe proiecte și activități își gestiona timpul într-un mod foarte eficient așa că majoritatea conversațiilor le purtam pe email. Realiza analize foarte riguroase asupra codului pe care îl scriam și era foarte ferm cu modificările pe care le cerea. Stilul direct combinat cu cel directiv îl făcea să pară rece și de multe ori provoca frustrare celor cu care interacționa. Am reușit să depășesc acest mod de comunicare și să văd experiența ca pe una de învățare. Și cu adevărat am avut multe de învățat, iar atunci când am scris cod bun nu a ezitat să mă felicite atât privat cât și public printr-un email către conducere. Pe măsură ce am lucrat mai mult împreună și am început să mergem împreună la client aveam conversații foarte interesante despre principii de arhitectură și design patterns. De la el am primit recomandarea să citesc Head First Design Patterns și Design Patterns: Elements of Reusable Object-Oriented Software.

La rândul meu urmăresc să transmit mai departe ce am învățat când am văzut că există dorință și deschidere pentru a obține rezultate. Am petrecut niște sâmbete frumoase la birou împreună cu George ȚUȚUIANU să facem o analiză despre evoluția codului pe un an de zile pe proiectul în care eram implicați și am observat trendul ascendent al evoluției indicatorilor. Ne-am ambiționat și l-am făcut să scadă chiar dacă lucram la o integrare complexă cu presiunea deadline-ului imediat după sărbătorile de iarnă. Asta pentru că dacă îți dorești cu adevărat se poate.

calitate

Acum PHP Mess Detector e integrat în majoritatea mediilor de dezvoltare și pentru Code Review există o grămadă de soluții care permit inspectarea codului și adăugarea cu ușurință de sugestii de îmbunătățire. Totuși cred că interesul și dorința de a scrie cod de calitate nu vine de la unelte sau reguli impuse. Vine din setea de cunoaștere, dorința de a învăța și din interacțiunea cu oameni care sunt un exemplu prin orientarea lor către calitate.

Scriț cod frumos! Se merită!

Dezvoltarea primului produs software – minimul utilizabil

Am povestit în postarea anterioară despre cum am început ca angajat într-o companie de software și contextul în care am ajuns să dezvolt primul produs software.

Compania se numește PIT Software și dezvoltă soluții pentru industria Ho.Re.Ca. La momentul respectiv produsul principal era Pitos® POS o soluție desktop dedicată restaurantelor. Extinderea portofoliului cu un client important a venit cu necesitatea de a dezvolta cât mai repede o soluție pentru a gestiona comenzile la domiciliu.

Timpul era foarte limitat și pentru a câștiga contractul era important să ne mișcăm rapid. Am avut la dispoziție aproximativ 3 săptămâni pentru a veni cu o variantă funcțională. Opțiunile erau să dezvoltăm un modul nou în soluția existentă sau să dezvoltăm un nou produs. Fiindcă era vorba de o aplicație complexă cu o durată lungă de învățare și ne având cunoștințele necesare pentru a o extinde am ales varianta de a porni cu noua aplicație de la zero.

De vreme ce resursele erau limitate cea mai importantă parte a fost să definim un minim utilizabil. În literatură și în practică de cele mai multe ori acest lucru se referă la a defini un MVP (https://en.wikipedia.org/wiki/Minimum_viable_product). Desigur că la momentul respectiv nu aveam habar de această terminologie. Știam doar că trebuie să lucrăm cât mai repede pentru a oferi o soluție.

Experiența proprie în dezvoltarea de produse software – începutul

Mi-am început cariera de programator web ca angajat în August 2007 când m-am angajat la PIT Software companie ce dezvoltă soluții pentru Ho.Re.Ca

Dezvoltasem deja un portofoliu de proiecte proprii folosind tehnologiile web (HTML, CSS, PHP, MySQL și JavaScript) așa că am devenit productiv încă din prima zi de muncă.

Așa tare m-am entuziasmat de oportunitate încât m-am dus acasă, mi-am luat unitatea centrala și am început să lucrez la primul program pentru ei. Aveau nevoie urgent să deblocheze un proiect pentru un client foarte important care avea un lanț de cafenele și restaurante în Buzău. Din portofoliu lipsea o aplicație pentru gestionarea comenzilor cu livrare la domiciliu. Am schițat câteva idei împreună cu Adrian Poenaru și Ovidiu Roșu și m-am apucat de treabă. După prima zi de muncă aveam o interfață în HTML. După 3 săptămâni am făcut prima instalare de Pitos Delivery.

Situația în 2007 se prezenta astfel

  • dezvoltarea se concentra pe aplicațiile desktop
  • foarte puține locații aveau conexiune la internet
  • PHP trecea de la versiunea 4 la versiunea 5

Limitările de la momentul respectiv și natura aplicației ce presupunea comunicarea cu casa de marcat și imprimantele m-au forțat să am o abordare hibridă desktop/web. Am optat pentru a înstala pe calculatorul respectiv un server web care rula aplicația scrisă în PHP și am dezvoltat o interfață în C# care se folosea de componenta de browser pentru a randa paginile. Asta a dus la o restricție de a folosi exclusiv Internet Explorer 7 ca navigator web. Mozilla era mult mai capabil la momentul respectiv decât IE7, dar dat fiind limitarea am dus chinuri groaznice să adaptez anumite comportamente diferite pe cele două browsere.

Web-ul se bazează pe operații de Request și Response între client și server. Încărcarea conținutului unui website se face prin navigarea pe link-uri. Fiind vorba de o aplicație a trebuit să ofer o experiență cât mai fluidă de utilizare care se obținea cu greu dacă aș fi folosit refresh la fiecare acțiune. Pentru a depăși aceatstă problemă m-am orientat către request-uri asincrone folosind JavaScript (AJAX). Așa s-a născut prima mea aplicație web. Ceea ce se numește în prezent Single Page Application (SPA). Deci mare hipstereală din partea mea la vremea respectivă. Am făcut SPA-uri înainte să fie cool 😉

Cu toate limitările setup-ul mi-a permis să obțin o productivitate încredibilă în comparație cu ceilalți colegi care dezvoltau aplicații desktop. Flexibilitatea limbajului HTML îmi permitea să adaptez foare ușor înterfețele. PHP lucrează foarte bine cu MySQL și structurile de date le gestionam ușor folosind array-uri (vectori). Pe lângă asta a contribuit și faptului că eram sunt un workaholic.

Cum am dezvoltat preocuparea pentru metodele Agile?

Primul contact cu terminologia Agile l-am avut în 2010 când m-am angajat la Zitec. Se folosea termenul de Sprint pentru a defini intervale de câte două săptămâni la care se urmărea lansarea în producție de noi funcționalități sau rezolvări de defecte. În prima echipă din care am făcut parte am lucrat alături de Andreea PALU în rolul de QA și Ștefan STOICA în rol de coordonator. Zitec dezvoltase o metodologie proprie bazată pe Scrum, dar diferită prin faptul că era orientată către proces. Acest mod de organizare făcea atmosfera să fie foarte predictibilă atât pentru noi ca echipă, cât și pentru client.

Al doilea termen agile cu care am făcut cunoștință a fost Daily Scrum. Se întâmpla undeva pe la mijlocul anului 2011 când am început să lucrez pe un proiect coordonat de Lucian DAIA. El mi-a scris pe Yahoo Messenger cu propunerea să ne vedem a doua zi la Daily Scrum. L-am rugat să îmi explice termenul pentru că nu îmi era cunoscut. Mi-a trimis o referință. Așa am început întâlnirile zilnice care s-au dovedit foarte utile pentru sincronizare și schimb de experiență.

Când am demarat lucrul la un nou proiect, la începutul anului 2012, am propus să folosim aceiași metodă de sincronizare zilnică. Colegii au considerat că nu avem nevoie de o astfel de întâlnire pentru că lucrurile sunt clare și le putem discuta pe email sau prin tichete. Proiectul era condus de Ionuț VODĂ și in echipă am fost eu, Cătălin ROTARIU, Bogdan UNGUREANU și Tiberiu POPOVICI.

Pe măsură ce avansam cu proiectul și termenul limită se apropia de final situația în echipă a început să fie tensionată, iar comunicarea pe email s-a dovedit a fi insuficientă. Ba chiar dăunătoare în momentul în care am primit un email a cărui titlu era scris în întregime cu litere mari.

Așa am început întâlnirile matinale cu Tiberiu POPOVICI de la care am avut foarte multe de învățat despre tainele JavaScript-ului. Situația s-a ameliorat și în vara anului respectiv am reușit să livrăm proiectul fără întârzieri foarte mari.

În toamna anului 2012 început primul proiect pe care l-am coordonat. Din echipă au făcut parte Andreea PALU, Alin ROMAN, Bogdan GHERVAN, Bogdan GRIGORE și Bogdan UNGUREANU.

În iunie 2013 am participat la un curs ce l-a avut ca trainer pe Florian IVAN. Setea de cunoaștere era mare. Aveam deja două echipe pe care le coordonam și eram în curs de a o prelua pe a treia. Când mai rămânea timp mai întrețineam și câteva mici proiecte pe care codasem în trecut. Am căutat să absorb cât mai multă informație din cele două zile de curs și am urmărit să aplic cât mai multe din cele învățate.

Note de la cursul lui Florian IVAN
Note de la cursul lui Florian IVAN
Agile Mindset
Agile Mindset

Nevoia de organizare era foarte mare pentru că făceam față cu greu la presiunea pe fiecare proiect. Forțat de împrejurime am învățat să deleg cât mai multă responsabilitate către echipe. Uneori  delegam fără să mă asigur că am transferat cunoștințele necesare ceea ce a condus inevitabil la frustrări și perioade tensionate. Dar am trecut cu bine peste ele. Mereu am căutat să creez o atmosferă pozitivă în echipă bazată pe colaborare și îmbunătățire continuă.

Imediat după cursul cu Florian mi-am propus să împărtășesc din informații cu echipele. Așa că am organizat câte o mini sesiune de training la mine acasă în care am dezbătut valorile și principiile agile. Apoi am făcut o a doua sesiune la Vlad ȘTEFANESCU acasă unde am discutat cum să punem în practică acele principii.

Pregătind materialele pentru curs
Pregătind materialele pentru curs

Am început să facem estimările în echipă la care contribuiau inclusiv colegii de pe testare. Fapt care mira pe mulți de cum poate un “tester” să estimeze durata de dezvoltare. Am perseverat cu această practică și s-a dovedit a fi foarte utilă datorită conversațiilor ce aveau loc și a perspectivelor diferite.

estimări în echipă
Estimări realizate în echipa Servskills

În timp am început să organizăm ședințele de Review la care am invitat clienții și ședințele de Retrospectivă în care discutam despre cum a mers sprint-ul și număram câte “features” de nota 10 am livrat. Schimbările ne-au adus un plus de productivitate, am îmbunătățit relația cu clienții și atmosfera în echipă era pozitivă. Au rămas limitările de resurse și presiunea continuă de a livra specifice mediului IT, dar am reușit să devenim mai predictibili și să ne organizăm mai bine munca.

Efortul depus a fost apreciat așa că în toamna anului 2013 am fost promovat la funcția de coordonator al departamentului de soluții custom și am căpătat statutul de partener în Zitec. Pe lângă asta am căpătat reputația de motivator al echipelor după cum se vede în broșura de prezentare 🙂

motivation-eduard-budacu

Anul 2014 a fost unul de aprofundare și de definire a cunoștințelor despre agile. Preocupările mele au fost de a populariza rezultatele obținute în cadrul celorlalte echipe și de a răspândi bunele practici. Am început să organizez prezentări și să particip la ședințele celorlalte echipe. Am lucrat la experimentarea unui nou model de estimare bazat pe Story Points pe care îl comparam cu cel existent de estimare în ore. Am citit cărți și articole cu care să îmbunătățim metoda de dezvoltare. M-am implicat alături de Marius BĂLTEANU și Cristi PENA pentru a redefini fluxul de lucru și pentru a implementa un nou tool de project management.

În primăvară l-am întâlnit la sală pe domn profesor Ion IVAN. Dânsul m-a întrebat despre preocupările mele actuale. I-am povestit despre agile și am început să schimbăm idei despre lucrul iterativ și incremental. M-a îndrumat să finalizez lucrarea de master, lucru pe care amânam să îl fac pentru că îmi pierdusem total interesul pentru ce însemnă o bucată de hârtie pe care scrie diplomă.

Așa am ajuns să mă apuc de lucrare după ce domn profesor m-a ajutat să definesc un titlu pentru lucrare și mi-a explicat metodologia de a scrie o lucrare de master într-un mod eficient. Partea cea mai dificilă a fost structurarea cuprinsului și identificarea bibliografiei care a durat aproape 3 luni. Apoi după spusele domnului profesor lucrarea s-a scris singură în 3 zile în care m-am baricadat într-o pensiune din Bușteni. Au mai fost câteva nopți nedormite în care am definitivat lucrare și uite așa m-am făcut cu o poză nouă în colecția de diplome.

Aici se încheie prima parte din călătoria mea agilă. O poveste cu amintiri, momente și mai ales oameni alături de care am lucrat cu mult drag.

Directia de cercetare 2016 – 2020: lectii invățate după prima încercare

Inainte sa ma inscriu la doctorat, domn profesor Ion Ivan imi spunea “agile nu este suficient, trebuie sa mai adaugi ceva”.

Prima incercare a fost de a adauga Knowledge Mangement, rezultand tema “Knowledge Management in echipe agile de dezvoltare software”. Conceptul este foarte interesant si vine ca o completare perfecta a practicilor de project management folosite in dezvoltare software. Din pacate prima experienta a fost un esec. Nu am reusit sa-mi definesc foarte bine tema si sa o prezint corespunzator in fata comisiei. Totusi a fost un esec din care am invatat enorm.

Prima lectie invatata a fost ca este extrem de importanta relatia cu conducatorul de doctorat si comisia de indrumare. Definirea directiei de cercetare, potrivirea intereselor si stabilirea unui stil de lucru sunt foarte importante pentru succes.

A doua lectie invatata si o reconfirmare a experientelor din facultate s/master e ca exista o ruptura enorma intre mediul academic si mediul de business. M-am simtit ca intr-o lume paralela de ceea ce se intampla in practica.

A treia lectie invatata a fost ca “agile nu este suficient”. Nici pentru cercetare si nici pentru companiile de dezvoltare software.

A patra lectie invatata a fost ca directia de cercetare trebuie sa fie suficient de abstracta pentru a permite generarea de idei originale si suficient de concreta pentru a genera solutii si rezultate. Asa ca mi-am definit un nou concept care sa rezume directia de cercetare pentru urmatorii ani: “m-commerce science”. E o directie pe care ma incadrez mult mai natural datorita experientei de a contrui solutii de business ca dezvoltator, team leader si consultant. E un domeniu actual, cu probleme concrete in practica pe care sa le identific si sa le rezolv dezvoltand solutii si produse software.

Probabil ca cea mai importanta lectie pe care am invatat-o e ca nu am nevoie de un anumit cadru pentru a face cercetare. Fac deja asta prin modul sitematic in care lucrez, prin perseverenta de care dau dovada, prin entuziasmul si curiozitatea cu care abordez problemele. Mi-am dorit mult sa contribui la imbunatatirea mediului de studiu pentru studenti si am crezut ca prin activitatea mea pot sa aduc schimbari pozitive in timpul si dupa doctorat. M-am simtit extraordinar la cateva cursuri pe care le-am predat si asta imi da energie si dorinta sa continuu studiul si sa impartasesc rezultatele pe care le obtin.

 

 

Data Science – explorare

Weekendul asta am dedicat timp sa studiez despre Data Science. Sunt la nivelul introductiv in care ma prind de cateva concepta de baza, construiesc o bibliografie, adun resurse si  observ daca e cu adevarat un domeniu ce imi face placere sa il studiez pe teremen lung. Pana acum sunt incantat chiar daca imi dau seama ca multe din cunostintele necesare imi lipsesc.

Citesc Data Science for Business de Foster Provost, Tom Fawcett. Am ajuns la capitolul 6 – Similarity, Neighbors, and Clusters. Cartea e bine strucutata si nu abunda in elemente tehnice care sa imi provoace confuzie. Imi place cum imbina partea teoretica cu partea practica. As zice ca gradul de intelegere e undeva pe la 40 – 50% din ce citesc.

In paralel rasfoiesc o carte mai veche “Statistica Teoretica si Economica” scrisa in 1996.  Aici gradul de intelegere e considerabil redus. De multe ori ma gandesc “What the fuck did I just read?”, dar acest proces ma ajuta sa prind termenii in limba romana.

Azi am urmarit un interviu cu Clare Corthell. O metoda buna pentru a gasi inspiratie si de a afla din provocarile si parcursul altora.

O alta resursa faina pe care o rasfoiesc e o colectie de link-uri, carti, seturi de date de pe github numita Awesome DataScience – https://github.com/okulbilisim/awesome-datascience

Primul meu script in R

Anul trecut am cochetat cu subiectul Data Science si mi-a starnit o mare curiozitate. Vlad Masek mi-a prezentat limbajul R si cateva concepte de baza. Mi-am propus ca anul acesta sa aprofundez. Sunt foarte entuziasmat pentru ca azi am realizat primul meu script in R.

Inainte de a trece la subiect adaug definitii pentru termenul data science

Wikipedia:

Data Science is an interdisciplinary field about processes and systems to extract knowledge or insights from data in various forms, either structured or unstructured,[1][2] which is a continuation of some of the data analysis fields such as statistics, data mining, and predictive analytics, similar to Knowledge Discovery in Databases (KDD).

Iar in cartea “Data Science for Dummies” termenul este prezentat ca:

the practice of using computational methods to derive valuable and actionable insights from raw datasets

In termeni practici, data science presupune existenta unei probleme/nevoi, disponibilitatea unui set de date si construirea unei solutii folosind instrumente de analiza a datelor.

Am inceput un nou proiect de coaching agile si nevoia de la care am pornit este de a aveea o vedere de ansamblu asupra produsului dezvoltat. Pe langa discutiile face-to-face cu membrii echipei, ma familiarilez cu istoricul proiectului urmarind tichetele din JIRA. De obicei fac acest lucru manual, petrecand cateva ore urmarind patternuri in titlul tichetelor, citind comentarii si urmarind evolutia sprinturilor. De data asta, mi-am dorit sa fac aceasta analiza folosind abordari data science. Am inceput cu un script simplu pentru care sunt disponibile multe tutoriale online: generarea unui worldcloud. Am reusit sa aflu care sunt cuvintele cu frecventa mare si care sunt temele ce se repeta in cadrul proiectului. O analiza care mi-ar fi luat zile bune avand in vedere ca sunt peste 6000 de tichete.

Scriptul este disponibil aici: jira-export

Resurse:
– https://www.datacamp.com/community/tutorials/r-data-import-tutorial
– https://www.youtube.com/watch?v=lRTerj8fdY0

Strategia de cercetare si dezvoltare 2014 – 2020 – research.ro

Un alt capitol la care, surpriza, nu stam extraordinar in Romania este cercetarea si dezvoltarea. Comparativ cu restul statelor din Europa avem un numar extrem de redus de cercetatori, colaborarea intre industrie si mediul academic lasa de dorit si avem cea mai slaba cotatie cand vine vorba de inovatie.

O umbra de speranta aduce “Strategia nationala de cercetare, dezvoltare si inovare 2014 – 2020” in care sunt prezentate o serie de masuri ce urmaresc sa reduca acest deficit. Le-am extras pe cele care mi-au atras atentia.

Sectorul IT are un potential foarte mare de inovare. Asta daca renuntam sa vindem ore in care executam pentru altii si incepem sa dezvoltam propriile idei. Simt un vibe bun. Avem startup-uri care apar, oameni care pleaca din fabricutele de soft, comunitati, meetup-uri si mult entuziasm. Sper sa ne tina entuziasmul, sa avem putere de munca, energie si creativitate.

 

Adoptarea procedurilor pentru deducerile fiscale de 50% asociate cheltuielilor CD.

Adoptarea legii invenţiilor de serviciu într-o formă care încurajează inovarea în sectorul privat şi, în mod special, localizarea activităţilor CDI în România. p15

TEHNOLOGIA INFORMAŢIEI ŞI A COMUNICAŢIILOR, SPAŢIU ȘI SECURITATE. Domeniul este unul dintre cele mai dinamice din ţară. Industria este sprijinită de experienţa antreprenorială acumulată în ultimele decenii, de calitatea ridicată a învăţământului superior şi a cercetării academice din disciplinele tehnice relevante, precum şi de prezenţa unor companii multinaţionale importante. Dezvoltarea de software, de tehnologii pentru internetul viitorului și calculul de înaltă performanță, joacă un rol central în rezolvarea marilor probleme societale. Dezvoltarea de aplicații spațiale dedicate și/sau integrate, tehnologiile şi infrastructurile spațiale, misiunile spaţiale proprii şi internaționale, reprezintă elemente cheie pentru creșterea competitivității în activități economice și 18 sociale. Securitatea societală se bazează pe dezvoltarea de tehnologii, produse, capacităţi de cercetare şi sisteme pentru securitate locală şi regională, protecţia infrastructurilor şi serviciilor critice, “intelligence’’, securitate cibernetică, securitatea internă şi a cetăţeanului, managementul situaţiilor de urgenţă şi al crizelor de securitate, precum și pentru combaterea terorismului, ameninţărilor transfrontaliere, crimei organizate, traficului ilegal, toate acestea pe fondul dezvoltării culturii de securitate. p17-18

 

Reglementarea şi organizarea doctoratului industrial pentru a creşte corelarea formării resurselor umane cu nevoile mediului economic. p20

http://www.research.ro/uploads/politici-cd/strategia-cdi-2014-2020/strategia-cdi-2020_-proiect-hg.pdf

http://ec.europa.eu/research/innovation-union/pdf/state-of-the-union/2014/countries/romania.pdf

http://ec.europa.eu/growth/industry/innovation/facts-figures/scoreboards/files/ius-2015_en.pdf