Issue 26/August 2014 - Today Software Magazine by Today Software Magazine

Nr. 26 • August 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM

T O D A Y S O F T WA R E MAG A Z I NE

Să vorbim despre Swift rtea a II-a

Întreținerea la zi a sistemelor Linux – Pa

Limbajul Hack TYPO3 Neos Informație structurată - aplicare Agile Poveşti de succes la finalul How to Web MVP Academy Standardele deschise – o miză pentru România

Provocări în promovarea internă Cadrul analizei de business (I) Folosirea serviciilor de tip cloud nu e lipsită de riscuri juridice Securizarea Codului Opensource (III) BBST - Un curs practic despre Testare Software

6 Standardele deschise – o miză pentru România Daniel Homorodean

10 Poveşti de succes la finalul How to Web MVP Academy Irina Scarlat

12 Noi modele de educație pentru pasionații de tehnologie: bootcamp-ul Simplon Roxana Rugină

15 SEETEST 2014 Irina Scarlat

16 Aplicaţie IT în SAP prezentată la ‘IT Conference on SAP technologies 2014’- Cluj Horea Rațiu

18 Informație structurată aplicare Agile Bogdan Mureșan

21 Întreținerea la zi a sistemelor Linux (II) Sorin Pânca

26 Să vorbim despre Swift Valentin Filip

28 Limbajul Hack Radu Murzea

30 Clean Code Naming Radu Vunvulea

32 TYPO3 Neos Schimbând ecosistemul sistemelor de administrare a conţinutului Tomiță Militaru

34 Provocări în promovarea internă Monica Soare

36 Cadrul analizei de business (I) Ioana Armean

38 Securizarea Codului Opensource (III) Raghudeep Kannavara

41 BBST -Un curs practic despre Testare Software Alexandru Rotaru și Ru Cindrea

44 Folosirea serviciilor de tip cloud nu e lipsită de riscuri juridice Claudia Jelea

editorial

Ovidiu Măţan

ovidiu.matan@todaysoftmag.com Editor-in-chief Today Software Magazine

ansarea acestui număr este o ocazie de a anunța realizarea unei competiții pentru startup-uri în cadrul IT Days, 25-26 noiembrie 2014. Aceasta va consta într-o serie de pitch-uri a startup-urilor, a căror durată de prezentare trebuie să se încadreze în limitele a două minute. Cei interesați sunt rugați să trimită o scurtă descriere și un link la site/produs la adresa startups@itdays.ro. Alături de proiectele de cercetare, pitch-urile startup-urilor s-au bucurat de un real succes în prima ediție a IT Days iar în acest an vom avea un juriu și chiar un premiu pentru câștigător. Evenimentul de lansare a numărului 26 este realizat cu sprijinul Primăriei ClujNapoca care ne-a pus la dispoziție clădirea renovată a vechiului Casino din Cluj-Napoca. Acesta este un spațiu inedit, aproape de public, despre care am descoperit că se poate închiria gratuit de către cei interesați pentru activități culturale. Ediția din această lună se deschide cu un articol dedicat importanței standardelor deschise pentru România. Rezultatul implementării acestei strategii ar fi utilizarea gratuită a documentelor publice și crearea unor baze de cooperare între diferite instituții care să faciliteze valorificarea acestor documente. Continuăm cu o trecere în revistă a startup-urilor care au terminat programul de accelerare How To Web MVP Academy, de unde vom reveni în numerele următoare cu mai multe detalii. Educația în IT a fost de altfel întotdeauna un subiect de interes pentru că avem atât de multă nevoie de specialiști. Simplon este un program intensiv, gratuit ce se adresează celor ce vor să învețe să programeze, să creeze un site și poate chiar să își lanseze propriul startup. Toate aceste teme sunt abordate în articole pe care le puteți găsi în prima parte a acestui număr. În ceea ce privește articolele tehnice, acest număr oferă partea a doua a articolului Întreținerea la zi a sistemelor Linux, după care urmează un prim articol general despre noul limbaj de programare introdus de către Apple, Swift. O prezentare a limbajului definit de Facebook, Hack, se numără de asemenea printre subiectele abordate. Importanța convențiilor în ceea ce privește numele folosite în codul nostru este demonstrată în Clean Code - Naming . Un alt articol este dedicat Typo3: TYPO3 Neos - Schimbând ecosistemul sistemelor de administrare a conţinutului. Încheiem seria articolelor tehnice cu un articol despre alternativa la certificarea ISTQB din sfera testării și anume: BBST -Un curs practic despre Testare Software. Din aria de management, HR și cerințe menționăm Informație structurată - aplicare Agile, un articol ce prezintă avantajele certificării PMP și modul în care se pot folosi aceste informații și procese într-un mediu pur Agile. O provocare destul de des întâlnită în marile companii este promovarea unei persoane interne pe o poziție de management față de angajarea uneia noi. De asemenea, un alt articol care completează această problematică a promovării este cel cu titlul Provocări în promovarea internă. Încheiem această inventariere a articolelor cu Cadrul analizei de business, care propune o schemă a foarte utilă a acestui proces. Vă dorim o lectură plăcută !!!

Ovidiu Măţan

Fondator al Today Software Magazine

nr. 26/august, 2014 | www.todaysoftmag.ro

Redacţia Today Software Magazine Fondator / Editor în chief: Ovidiu Mățan ovidiu.matan@todaysoftmag.com Editor (startups și interviuri): Marius Mornea marius.mornea@todaysoftmag.com Graphic designer: Dan Hădărău dan.hadarau@todaysoftmag.com

Lista autorilor Roxana Rugină

roxana.rugina@gmail.com CEO & co-founder @ Simplon Romania

Daniel Homorodean

daniel.homorodean@clujit.ro Membru în Consiliul Director @ Cluj IT Cluster

Radu Vunvulea

Monica Soare

Senior Software Engineer @iQuest

Manager @ Artwin

Bogdan Mureșan

Sorin Pânca

Director of Engineering @ 3Pillar Global

Senior Systems Administrator @ Yardi România

Ru Cindrea

Alexandru Rotaru

Managing Partner @ Altom Consulting

Tomiță Militaru

Valentin Filip Valentin.Filip@tss-yonder.com

Senior Web Developer @ Arxia

Cluster Manager & Team Lead on Innovation @ Yonder

Claudia Jelea

Ioana Armean

Radu.Vunvulea@iquestgroup.com

monica.soare@artwinconsulting.ro

bogdan.muresan@3pillarglobal.com

sorin.panca@yardi.com

Reviewer: Tavi Bolog tavi.bolog@todaysoftmag.com Reviewer: Adrian Lupei adrian.lupei@todaysoftmag.com

ru.cindrea@altom.ro

alex.rotaru@altom.ro

Contabil : Delia Coman delia.coman@todaysoftmag.com Produs de

Today Software Solutions SRL str. Plopilor, nr. 75/77 Cluj-Napoca, Cluj, Romania contact@todaysoftmag.com www.todaysoftmag.ro www.facebook.com/todaysoftmag twitter.com/todaysoftmag ISSN 2284 – 6352

tmilitaru@arxia.com

claudia.jelea@jlaw.ro Avocat & Consilier in domeniul marcilor @ Jlaw

ioanaa@imprezzio.com Business Analyst @ Imprezzio Global

Raghudeep Kannavara

Irina Scarlat

Security Researcher, Software and Services Group @Intel USA

PR Manager @ How to Web & TechHub Bucharest

Horea Rațiu

Radu Murzea

Director Departament SAP @ .msg systems Romania

PHP Developer @ Pentalog

raghudeep.kannavara@intel.com

horea.ratiu@msg-systems.com

irina.scarlat@howtoweb.co

rmurzea@pentalog.fr

Copyright Today Software Magazine Reproducerea parțială sau totală a articolelor din revista Today Software Magazine fără acordul redacției este strict interzisă. www.todaysoftmag.ro www.todaysoftmag.com

www.todaysoftmag.ro | nr. 26/august, 2014

analiză

Standardele deschise – o miză pentru România

cum câteva săptămâni, în 22 iulie, guvernul britanic a luat o decizie pe care mulţi au catalogat-o drept istorică: standardul ODF ( Open Document Format) a devenit obligatoriu pentru partajarea sau colaborarea pe documente guvernamentale. ODF va fi standardul pentru schimbul de documente de tip text sau spreadsheet între departamentele instituţiilor publice britanice, dar şi cu cetăţenii şi furnizorii, eliberând astfel toţi jucătorii de nevoia de a cumpăra şi folosi software proprietar pentru a accesa documente. De acum, orice software cumpărat de instituţiile guvernamentale britanice trebuie să fie compatibil cu ODF. Pentru UK acesta este doar un pas integrat1 în efortul susţinut în ultimii ani de a ajunge să aibă un guvern “mai deschis, mai transparent”, care să asigure accesul facil al cetăţenilor la serviciile publice şi la informaţia de interes public. În acest efort susţinut se înscrie promovarea datelor deschise şi a standardelor deschise2, politicile britanice în acest sens fiind bine structurate şi transparente, încă din 2010. Documentul manifest “Open Standards Principles”3 începe cu o declaraţie clară: “IT-ul guvernamental trebuie să fie deschis - deschis către oamenii şi organizaţiile care folosesc serviciile noastre şi deschis spre orice furnizor, indiferent de mărimea sa. Toate instituţiile guvernamentale trebuie să adere la aceste principii”. Vom vedea în continuare ce sunt standardele şi formatele deschise, de ce sunt ele importante şi cum putem beneficia de pe urma lor.

are grade diferite de stricteţe. Majoritatea este de acord că un Standard este Deschis dacă este disponibil public şi poate fi adoptat şi implementat fără costuri. IETF şi ITU-T consideră un standard ca fiind deschis chiar dacă există costuri de licenţiere a patentelor, cu conditia ca ele să fie “rezonabile şi nediscriminatorii”, dar poziţia organizaţiilor open source şi a multor guverne este mai tranşantă: standardul este deschis dacă fără nici un cost poate fi adoptat, implementat şi extins. Standardele deschise joacă un rol esenţial în politicile guvernamentale ale ţărilor dezvoltate, deoarece prin folosirea lor se asigură interoperabilitatea între sisteme şi între instituţii şi accesul liber la informaţie, fără necesitatea unor costuri suplimentare de licenţiere. Tocmai pentru a elimina ambiguitatea şi interpretarea arbitrară a definiţiei standardelor deschise, majoritatea guvernelor Ce sunt Standardele Deschise ? au definit clar, prin normative, Standardul Deschis. Toate specifică De-a lungul timpului, o serie de organizaţii sau guverne au faptul că standardul trebuie să fie gratis, unele ( Africa de Sud s.a. încercat să dea o definiţie proprie a conceptului de Open Standard. ) chiar specificând că standardul “trebuie să fie întreţinut de către În funcţie de compoziţia şi de interesul acestor entităţi, definiţia o organizaţie ne-comercială”. Caracterul extensibil al standardului 1 www.gov.uk/government/news/open-document-formats-selected-to-meet-user-needs este explicit precizat în multe cazuri - aspect important, pentru 2 www.gov.uk/government/publications/open-standards-for-government că unele standarde sunt deschise pentru utilizare, dar nu permit 3 www.gov.uk/government/uploads/system/uploads/attachment_data/file/78892/Open- extinderea lor decât după ce cumperi acest drept. Deocamdată, Standards-Principles-FINAL.pdf România nu a adoptat o definiţie a standardului deschis, dar acest

Young spirit Mature organization A shared vision Join our journey! www.fortech.ro

nr. 26/august, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE

lucru va fi necesar, tocmai pentru că nu există o definiţie „universală” general acceptată şi nu ne putem aștepta ca în viitorul apropiat să existe, datorită intereselor economice ale diverşilor jucători din piaţă. Şi totuşi, dincolo de politici, ne întrebăm cum ne afectează sau cum ne ajută Standardele Deschise ? Ele sunt deja peste tot în viaţa noastră, în multe domenii. GSM-ul ne uşurează comunicarea telefonică, TCP şi IP ne permit să accesăm informaţia prin internet, SMTP să schimbăm mesaje, PCI şi USB ne lasă să conectăm echipamentele. Din pleiada de standarde deschise cu care interacţionăm în diverse feluri şi care ne fac, sau ne pot face viaţa mai uşoară, formatele deschise sunt un subset important.

Ce sunt Formatele Deschise ?

Formatele deschise se aplică fişierelor, sunt deci specificaţii pentru stocarea digitală a datelor. Definiţiile standardelor deschise li se aplică direct, dar multe organizaţii şi instituţii au adus precizări suplimentare: • “Formatul este dezvoltat printr-un proces cu vizibilitate publică, gestionat de comunitate” ( Sun Microsystems) • “Formatul este independent de platformă, citibil de către maşini şi disponibil fără restricţii” ( Guvernul UK) • “Formatul e bazat pe un standard deschis, dezvoltat de o comunitate deschisă,[...], e documentat complet şi disponibil public” ( Commonwealth of Massachusetts) Formatele deschise fac parte din viaţa şi din activitatea noastră, le folosim permanent atât la serviciu cât şi acasă. Iată câteva dintre ele: GIF, JPEG 2000, PNG, SVG HTML, XHTML, UTF-8/UTF-16, ePub, Postscript Office Open XML ( OOXML ) Open Document Format ( ODF ) PDF ( partial, doar subsets) gzip, tar, ZIP CSS, CSV,JSON, RSS, XML

De ce ne trebuie standarde deschise ?

Deja majoritatea acţiunilor noastre au o componentă digitală, care în relaţie cu statul şi cu instituţiile sale, centrale sau locale, își dovedește importanța, fie că ne plătim impozitele, că depunem o declaraţie sau că solicităm un cazier judiciar. Este anacronic şi teribil de frustrant ca în ziua de azi să primeşti o hârtie tipărită de la o instituţie ca să o plimbi în cealaltă parte a oraşului pentru ca un funcţionar să introducă aceleaşi date manual într-o aplicaţie, citindu-le de pe foaie. Pentru eficienţa sistemului şi pentru calitatea vieţii noastre, asigurarea interoperabilităţii între sistemele

instituţiilor publice este esențială. În toate politicile guvernamentale ale ţărilor dezvoltate, standardele şi mai ales formatele deschise au două obiective majore: • asigurarea interoperabilităţii între instituţii, • asigurarea accesului cetăţeanului, organizaţiilor şi operatorilor economici la informaţia publică, gratis şi fără costuri ascunse ( licenţieri de programe). Desigur, eficientizarea costurilor este şi ea un motiv important, considerând că standardele deschise pot fi implementate şi de către aplicaţii care nu necesită costuri de licenţiere ( cel mai simplu exemplu fiind cazul formatelor documentare - Open Office/Libre Office versus Microsoft Office ) Accesul la datele deschise ( Open Data), publicate într-o formă procesabilă automat ( de către aplicaţii ), bazată pe formate deschise, este nu doar o politică normală pentru a asigura informarea cetăţeanului, ci are şi o miză economică uriaşă. Conform studiilor McKinsey4, prin folosirea datelor deschise se vor pute genera peste 3 trilioane de dolari anual !

Batalia OOXML vs ODF

Office Open XML ( OOXML, OpenXML) este un format bazat pe XML şi arhivat (zipped), folosit pentru descrierea formatelor documentare ( spreadsheets, presentations, word processing documents, charts ) dezvoltat de Microsoft, standardizat de Ecma, ISO si IEC ( ECMA-376, ISO/IEC 29500 ). Open Document Format (ODF) este de asemenea un format XML, dezvoltat de către comitetul tehnic al OASIS, publicat ulterior şi ca standard ISO/IEC, bazat pe specificaţia OpenOffice.org XML realizată iniţial de către Sun Microsystems. În ultimii ani Microsoft a fost pus în corzi în mod repetat de către guvernele diverselor ţări, în bătălii precum cea care a avut loc în UK în această primăvară. Gigantul din Redmond a reuşit să oprească, sau mai bine zis să amâne tranşări ferme în favoarea ODF, dar bătălia mondială continuă acerb şi precedentul britanic va avea probabil consecinţe dramatice. Pentru alegerea dintre ODF şi OOXML, standardul dezvoltat şi susţinut de Microsoft, se aduc de obicei argumente tehnice, însă toată lumea ştie că miza economică uriaşă este cea care dictează: eliberarea guvernelor de dependenţa faţă de produsele Microsoft are potențialul de a crea economii substanţiale, deşi are şi costuri evidente. Vă puteţi închipui o Românie în care toţi funcţionarii publici să lucreze cu Open Office, pe calculatoare cu platforme Linux ? Cam greu, aşa-i ? Dar în multe regiuni ale lumii, acest lucru deja se întâmplă. Suita Office a Microsoft a rămas permanent în urma 4 w w w . m c k i n s e y . c o m / i n s i g h t s / b u s i n e s s _ t e c h n o l o g y / open_data_unlocking_innovation_and_performance_with_liquid_information

www.todaysoftmag.ro | nr. 26/august, 2014

analiză Standardele deschise – o miză pentru România standardelor deschise, având un defazaj chiar şi faţă de propriul standard OOXML. Compatibilizarea întârziată cu ODF 1.2 a fost anunţată cu tam-tam în 2012, însă în mod real ea nu este asigurată nici acum. Este puţin probabil ca acest lucru să se datoreze incompetenţei tehnicienilor Microsoft, ci mai degrabă unei politici asumate strategic, de a descuraja folosirea formatelor ODF în MS Office. Frustrarea celui care deschide în Word un fişier ODT complex creat în Open Office constituie un argument bun pentru Microsoft de a discredita folosirea pe scara largă a suitelor office gratuite. În ce priveşte argumentele tehnice, ele se referă la mai multe aspecte, dintre care: • conform specificaţiei standardelor, ODF poate reprezenta complet documentele OOXML, pe când reciproca nu este valabilă. • implementarea standardului OOXML în MS Office nu este completă. • implementarea în MS Office include elemente proprietare, non-standard. Argumentele legate de controlul standardului sunt şi ele importante: • organizațiile OASIS ( pentru ODF) şi Ecma ( pentru OOXML) au politici diferite faţă de membri. În Ecma nu poţi fi membru ca individ, iar publicul nu are acces la comunicarea internă ( mailing lists, agendele și minutele întâlnirilor) dreptul de a extinde standardul OOXML nu este acoperit de licenţă, permițând Microsoft să acţioneze legal împotriva celui care extinde sau derivă standardul. Acest lucru prezintă risc pentru dezvoltatorii de aplicaţii complexe pentru procesarea conţinutului documentar, în cazul în care definesc, de exemplu, tag-uri noi. Viitorul acestei dispute se anunţă interesant. În mod sigur Microsoft poate să rezolve toate problemele aduse ca argumente împotriva OOXML, dacă doreşte acest lucru. Până atunci, precedentul britanic îl face şi mai vulnerabil.

Standardele deschise în România

Știm că sunt multe aspecte la care România trebuie să lucreze, astfel încât instituţiile publice să fie mai eficiente şi interacţiunea între ele şi cetăţean sau mediul privat să fie mai prietenoasă. Deşi este uşor să ne scuzăm că există lucruri mai importante de realizat decât standardele deschise, politicile publice trebuie să fie cât mai complete şi mai coerente. Ne arde mai tare ca informaţia să fie publicată şi accesibilă, în orice formă, iar formatul ei ne doare mai puţin, deocamdată, până când realizăm importanţa procesării şi reutilizării acestei informaţii. În noua formă propusă a Strategiei Naţionale pentru Agenda Digitală, MCSI menţionează în repetate rânduri importanţa şi nevoia interoperabilităţii între instituţii, “utilizarea standardelor şi modelelor de referinţă”, declarându-şi interesul pentru “promovarea unor standarde mai înalte” astfel încât “utilizând standardele deschise, informaţiile administrate de sisteme să fie disponibile în format stabil, public, independent de furnizor”. Toate aceste menţiuni rămân şi riscă să rămână doar vorbe goale, iar interoperabilitatea o iluzie, în lipsa unui angajament coerent, asumat, bazat pe o definiţie explicită a noţiunii de standard deschis şi a unui set de principii care să guverneze implementarea sistemelor şi publicarea informaţiilor.

nr. 26/august, 2014 | www.todaysoftmag.ro

Cluj IT Cluster şi standardele deschise

Pentru Clusterul Cluj IT este foarte importantă promovarea bunelor practici şi a standardelor în industria IT, cu avantaje semnificative în toate sectoarele de activitate şi în special în mediul public. Open Data, accesibilitatea web, open source sau open standards fac natural obiectul interesului nostru pentru a construi o Românie mai eficientă, mai transparentă şi mai conectată cu restul lumii. De aceea, am stabilit un dialog direct cu MCSI şi cu alte instituţii, pentru a ajuta la instituirea unor politici sănătoase şi sustenabile, în care standardele deschise joacă un rol important. Sper ca într-un viitor nu prea îndepărtat standardele deschise să nu mai fie doar un concept exotic, ci o realitate care să ne facă tuturor viaţa mai uşoară. Daniel Homorodean

daniel.homorodean@clujit.ro Membru în Consiliul Director @ Cluj IT Cluster

TODAY SOFTWARE MAGAZINE

www.todaysoftmag.ro | nr. 26/august, 2014

eveniment

Poveşti de succes la finalul How to Web MVP Academy

ucurești, 23 iulie 2014 – How to Web MVP Academy, programul de pre-accelerare adresat startup-urilor din Europa Centrală şi de Est, s-a încheiat marţi, 22 iulie, cu Demo Day. În cadrul evenimentului, echipele finaliste au prezentat în faţa audienţei rezultatele a două luni de muncă intensă, workshop-uri şi sesiuni de mentorat, şi au demarat discuţii pentru a obţine o investiţie sau pentru a fi admise într-un program de accelerare european. Prima ediţie How to Web MVP Academy a avut loc în perioada 2 iunie – 22 iulie la TechHub Bucharest şi a adus împreună 14 startup-uri cu potenţial din regiune. Dezvoltat în parteneriat cu Microsoft, Romtelecom şi Cosmote cu sprijinul Bitdefender, Raiffeisen Bank, Hub:raum şi TechHub Bucharest, programul a susţinut echipele finaliste în eforturile lor de dezvoltare şi le-a învăţat cum să construiască produse de succes la scară globală.

Pe lângă componenta educaţională, finaliştii MVP Academy au avut acces la spaţiul de co-working oferit de TechHub Bucharest, precum şi la comunitatea profesioniştilor în tehnologie la nivel regional, şi au beneficiat de workshop-uri, mentorat şi conexiuni cu investitori de tip angel, programe de accelerare şi fonduri de investiţii early stage. Pe parcursul programului, echipele How to Web MVP Academy au avut ocazia să participe la workshop-uri practice susţinute de specialişti consacraţi la nivel internaţional printre care se numără Jon Bradford (Managing Director TechStars London), Alex Barrera (Fondator şi Editor Tech.eu şi Chief WOWness Officer Press 42), Daniela Neumann (Scrum Master/ Change Management idealo internet GmbH), Paul Renaud (Executive Coach) sau Maria Diaconu (Fondator & CEO Mozaic Works). Astfel, acestea au învăţat mai multe

despre cum să dezvolte un startup de succes la scară globală, cum să facă networking cu clienţii şi partenerii de afaceri sau cum să îşi spună povestea şi să îşi prezinte produsul în faţa potenţialilor investitori. Mai mult, startup-urile finaliste au acumulat noţiuni esenţiale de business legate de product management, indicatorii pe care trebuie să îi urmărească, metodologiile agile, dezvoltarea echipei şi a comunităţii, SEO, sau aspectele legale pe care trebuie să le ia în considerare. În plus, cele 14 echipe finaliste au beneficiat de sesiuni de mentorat 1 la 1 cu peste 40 de experţi şi profesionişti care le-au oferit feedback şi recomandări din propriile experienţe. Printre mentorii primei ediţii a How to Web MVP Academy se numără Ivan Brezak Brkan (Editor şi Fondator Netokracija), Alex Negrea (Fondator DocTrackr), Florin Talpeş (Fondator şi CEO Bitdefender), Olaf Lausen (Chief of Staff & Business Development Director Romtelecom and Cosmote Romania), Zoli Herczeg (Business Evangelist Microsoft România), Dragoş Ilinca (Co-Fondator şi VP Marketing UberVU), Gabriel Coarnă (Arhitect Evernote Clearly), Bobby Voicu şi Cristi Badea (Co-Fondatori Mavenhut) sau Luka Sucic (Business Development Manager & Evangelist Hub:raum). „Astfel de colaborări sunt esenţiale pentru Romtelecom şi COSMOTE România şi le considerăm parteneriate mutual benefice care susţin eforturile noastre continue de a încuraja antreprenorii să ne devină parteneri pentru a câştiga împreună. Din acest motiv consider că programul How to Web MVP Academy are toate şansele să devină un model de bune practici deoarece facilitează accesul la cunoştinţe de calitate

nr. 26/august, 2014 | www.todaysoftmag.ro

şi networking, ajutând astfel toate părţile implicate”, a declarat Olaf Lausen, Chief of Staff & Business Development Director Romtelecom și Cosmote Romania. Programul de pre-accelerare How to Web MVP Academy s-a încheiat marţi, 22 iulie, cu Demo Day, eveniment în cadrul căruia echipele finaliste şi-au prezentat produsele şi progresul înregistrat în faţa audienţei formate din investitori de tip angel, reprezentanţi ai programelor de accelerare la nivel european şi al fondurilor de investiţii early stage, antreprenori, profesionişti consacraţi în domeniul tehnologiei şi jurnalişti. Seara a debutat cu un mesaj din partea lui Bobby Voicu (Co-Fondator Mavenhut) care a vorbit despre cum arată viaţa unui startup după participarea la un program de accelerare. „Trebuie să recunosc că nu vă invidiez pentru poziţia în care vă aflaţi astăzi – în urmă cu trei ani am fost şi eu în locul vostru. Şi ce e greu de-abia acum începe! Învăţaţi din această călătorie! Statisticile arată că doar 3 din cele 14 echipe de astăzi vor mai exista după 1 an. Creaţi-vă reţeaua, cunoaşteţi oameni relevanţi pentru voi, câştigaţi încrederea potenţialilor investitori! Şi sper că ne vom întâlni la anul şi îmi veţi spune cu mândrie că vă număraţi printre cei care aţi învins statisticile”, i-a sfătuit Bobby pe participanţii How to Web MVP Academy. Ulterior, echipele finaliste şi-au învins emoţiile şi au urcat pe scena cinematografului Elvira Popescu pentru a-şi prezenta produsele şi a demonstra ce au învăţat de-a lungul programului. Cele 13 startup-uri care au prezentat în faţa audienţei sunt: 1. Axo Suits – exoschelete cu putere mare 2. Bravatar – motor de recomandări bazate pe stilul de viaţă al utilizatorului 3. Complement – software care pune în

TODAY SOFTWARE MAGAZINE

valoare rezultatele educaţionale 4. Drimm.in – platformă care monitorizează activitatea utilizatorilor în social media, salvează interesele acestora şi le transformă în activităţi care pot fi duse la îndeplinere 5. Fittter – aplicaţie mobilă care oferă utilizatorilor o experienţă personalizată de antrenament punându-i în legătură directă cu studiourile de fitness şi antrenorii 6. Gloria Food – sistem de comenzi online gratuit care permite restaurantelor să interacţioneze în mod direct cu clienţii acestora 7. Hickery – music player web şi mobil care permite utilizatorilor să interacţioneze între ei şi să asculte muzică în funcţie de preferinţele exprimate pe social media 8. Inovolt – sistem de monitorizare pentru reţeaua electrică 9. Lifebox – aplicaţie mobile care permite utilizatorilor să creeze albume de fotografii comune cu prietenii acestora şi să genereze astfel amintiri comune 10. Pocketo – startup hardware care construieşte dispozitive conectate la

internet 11. Qalendra – platformă de călătorii care permite persoanelor dornice de aventură să descopere noi oportunităţi şi să îşi realizeze propriul calendar 12. StudyMentors – platformă online care pune în legătură tinerii care îşi doresc să aplice la studii în străinătate cu studenţii şi absolvenţii universităţilor europene 13. Wallet Buzz – aplicaţie care conectează retailerii cu utilizatorii de telefoane inteligente şi le transmite acestora din urmă reclame şi conţinut în funcţie de locaţie Demo Day s-a încheiat cu un cocktail în cadrul căruia echipele finaliste au avut ocazia să facă networking şi să continue discuţiile cu persoanele din audienţă interesate în mod direct de produsele pe care le dezvoltă. În plus, în zilele care urmează acestea vor participa la întâlniri 1 la 1 cu programele de accelerare şi investitorii/ fondurile de investiţii interesate să le ofere finanţări şi/sau să îi susţină în continuare în eforturile lor de scalare. „Suntem mândri de modul în care au evoluat echipele How to Web MVP Academy pe toată durata programului. Au fost 2 luni intense în care au învăţat cum să creeze produse şi să dezvolte afaceri sustenabile şi au cunoscut oameni care îi vor ajuta să meargă la următorul nivel. Am adaptat în permanenţă activităţile din

program pentru a răspunde nevoilor specifice ale fiecărei echipe, iar rezultatele au fost pe măsura aşteptărilor. Startup-urile finaliste au înregistrat progrese semnificative, iar astăzi ştiu care sunt paşii pe care trebuie să îi parcurgă şi au potenţialul de a primi investiţii ulterioare sau de a fi admise în programe de accelerare. Nimic din toate acestea nu ar fi fost posibil fără implicarea mentorilor locali şi regionali şi a partenerilor care au investit timp şi resurse şi au împărtăşit echipelor propriile experienţe. Prima ediţie How to Web MVP Academy a fost nu în ultimul rând o experienţă de învăţare pentru noi ca echipă. Simţim că am învăţat lecţii valoroase alături de startup-urile din program şi suntem convinşi că vom face o treaba şi mai bună la următoarele ediţii”, a declarat Monica Obogeanu, Program Manager How to Web MVP Academy. Mediatizarea How to Web MVP Academy a fost asigurată de Goal Europe, Netokracija, IT Dogadjadi, Digjitale, Entrepreneur.bg, Newtrend.bg, Adevărul Tech, Forbes România, Wall-Street.ro, Business Cover, Manager Express, Business Woman, Market Watch, Ctrl-D, PC World, Computer World, Gadget Trends, Today Software Magazine, Agora, Yoda.ro, Incont.ro, România Liberă, Zelist Monitor, Comunicatedepresa.ro, Thehack.biz, Games Arena şi Times New Roman.

Irina Scarlat

irina.scarlat@howtoweb.co PR Manager @ How to Web & TechHub Bucharest

www.todaysoftmag.ro | nr. 26/august, 2014

business

Noi modele de educație pentru pasionații de tehnologie: bootcamp-ul Simplon

a bootcamp-ul Simplon s-au înscris deja peste 60 de tineri extrem de motivați și creativi care vor și pot face mai mult decât ceea ce fac astăzi. Cineva care nu a făcut facultate pentru că trebuia să se angajeze că să se poată susține financiar vrea să intre în bootcamp pentru că-și dorește să devină un Elon Musk al României. O altă candidată a lucrat ca operator baze de date. De când a aflat de Simplon și-a dat demisia și a plecat cu Work & Travel ca să adune bani pentru cele 6 luni în care dorește să-nvețe cod ca să-și dezvolte ideile de aplicații pe care le are de mult timp. Imaginați-vă ce ar putea face un grup de oameni cu idei fantastice și cu dorința de a învăța dacă s-ar aduna timp de 6 luni într-o tabără de creație și programare. Tabăra aceasta există la Cluj și își va deschide porțile din toamnă la Simplon.

Un mediu de dezvoltare pentru geek și creativi

Când am aflat de Simplon, locuiam în Franța de 2 ani și jumătate. Tot de atâta timp îmi căutăm și un job. În România eram PR Manager într-o agenție de publicitate din București când m-am hotărât să plec la Paris unde puteam să-mi continui studiile cu un al doilea Master în Industrii Creative. Cu experiență de cinci ani și trei limbi pe care le vorbeam, nu credeam că CV-ul meu va ajunge atât de des printre spam-urile managerilor de HR. Când reușeam să ajung la un interviu mi se spunea că sunt fie supracalificată, fie mi se propunea un alt post decât cel pentru care

aplicasem. Mi-am dat seama că ceea ce caut nu este neapărat un job, ci un anumit mediu de lucru: cu oameni deschiși la minte și cu ambiții mari, creativi, geek, pasionați de tehnologie, mediul digital și inovație. Îmi aduc aminte că a doua zi după ce-am terminat Masterul la Universitatea Paris 8, mi-am făcut PFA și am pornit la vânătoare de clienți prin spațiile de co-working și fab lab-urile pariziene. Un freelancer trebuia să știe să facă de toate: de la marketing, vânzări până la project management și programare. Cunoștințele de HTML și CSS contau printre miile de candidați, așă c-am început să iau cursuri de programare pe Cursera, o platformă de e-learning. Între timp ideile de aplicații pe care doream să le dezvolt umpleau paginile carnețelelor personale cu schițe și modele de business. După o iarnă lungă și plină de căutări, am văzut un master de Inteligență Artificială. Cu toate nopțile petrecute

nr. 26/august, 2014 | www.todaysoftmag.ro

ascultând conferințe ale profesorilor de la MIT mă gândeam că dacă se dă examen din teorie, voi lua o notă de trecere. Din păcate, la celalt capăt al telefonului primit de la secretariatul Masterelor de Informatică și Calculatoare, nu erau vești bune. Cu nici una din diplomele mele nu mă încadram la candidații eligibili.

Coding Bootcamp-ul adus din Franța în România

În vara lui 2013 am fost acceptată în prima promoție Simplon.co alături de alți 29 de candidați care urmau să învețe Ruby on Rails pentru a deveni web-antreprenori în 6 luni. Eram 14 naționalități cu vârste cuprinse între 18 și 55 de ani, de la PHDuri și până la tineri fără BAC. În cele 6 luni la Simplon am simțit pentru prima oară că mi-am găsit locul și că pot face orice. Am lucrat la foarte multe proiecte pentru că simțeam că merită și preferam să merg în weekend la Simplon mai degrabă decât la Musée du Louvre. Era un mediu stimulant, eram apreciată pentru ceea ce făceam și încurajată să devin mai bună în fiecare zi. Când le-am spus colegilor că aș vrea să dezvolt Simplon în România, îmi doream să mă întorc cu un proiect frumos acasă prin care să dau mai departe tot ceea ce am învățat. Nu mă gândeam că totul se va întâmpla atât de rapid. Structura Simplon era însă pregătită pentru replicare, iar fondatorii Simplon mereu deschiși la noi destinații și provocări. Filiale se vor deschide în curând și în Tunisia, Brazilia,

TODAY SOFTWARE MAGAZINE

Maroc. România a fost însă prima destinație pentru Simplon în străinătate. Țara noastră beneficiază de o recunoaștere globală pentru capacitățile programatorilor români. Când toată lumea caută specialiști în noile tehnologii, Simplon își propune să dezvolte un pool de talente de acest gen la Cluj. În ianuarie am creat o filială Simplon în România pentru care am primit o susținere de la Orange din Franța. În parteneriat cu Cluj Cowork și Ruby Tribe am lansat bootcamp-ul care va începe din toamnă. Simplon România este o filială locală, iar Simplon.co, un start-up francez de succes, lansat în aprilie 2013. Conceptul inovator din punct de vedere social al Simplon.co a fost premiat chiar de Președintele Franței că fiind una dintre inițiativele cu cel mai mare impact social al anului în Franța. Cu Simplon România există șanse mari să dezvoltăm cât mai multe comunități de practici și învațare socială conectate la o rețea globală. Pentru educația specializată în tehnologii avansate cum ar fi cloud computing și connected objects, nu există profesori universitari momentan. Ceea ce își propune Simplon este să faciliteze accesul la noile tehnologii și transferul de know-how de la specialiști către noua generație, într-un timp cât mai scurt.

Statele Unite și l-a adaptat la piața europeană. Știm că în Europa, crearea locurilor de muncă este una dintre cele mai mari probleme actuale. Pe de altă parte în IT există o cerere foarte mare de noi talente. Un training cu profesioniști experimentați costă între 4000 și 15000 de dolari în SUA. Pentru cei care vin din medii modeste, șansele de a-și finanța trainingul pe cont propriu ar fi foarte mici. Aici intervine Simplon. Noi căutăm acei parteneri care vor să susțină inovația, formarea noilor talente sau care au nevoie resurse umane bine pregătite, gata să integreze o echipă de dezvoltatori web în 6 luni. Cu ajutorul lor, oferim un bootcamp gratuit celor care vor să învețe practic cum se dezvoltă aplicațiile web și proiecte/startup-uri. Înscrierile pentru programul de training intensiv de 6 luni în domeniul dezvoltării web și al antreprenoriatului social sunt deschise până pe data de 20

august. Simplon România caută în continuare candidați. Programul se adresează în special persoanelor subreprezentate în mediul digital și care au nevoie de trainiguri speciale pentru a fi integrate pe piața muncii. Dacă ești specializat într-un domeniu și nu îți găsești job sau vrei să înveți dezvoltare web, singur e mai dificil să găsești o soluție. La Simplon poți să-ți pui în valoare pasiunile, folosind tehnologia pentru a-ți dezvolta aptitudinile care sunt la mare căutare pe piața muncii.

Skill-uri necesare pentru viitor

Nevoia de personal calificat, cu experiență de lucru în medii de lucru dinamice, tehnologii și framework-uri de ultima oră este incredibil de mare. În același timp capacitatea locurilor la facultățile tehnice este limitată, iar pe cealaltă parte, avem mii de tineri absolvenți în comunicare, marketing, geografie care nu-și găsesc de lucru.

Noile tehnologii se schimbă foarte rapid. Pentru a dezvolta soluții inovatoare, Simplon caută și formează un profil special de developer

Ideea de la care a pornit Simplon a fost aceea de aduce la un loc toți pasionații de tehnologie care sunt dornici să învețe cod pentru a schimba lumea. Practic, Simplon a preluat formatul bootcamp-urilor din www.todaysoftmag.ro | nr. 26/august, 2014

startups

Noi oferim un training intensiv bazat pe cunoștințe practice și metode de învățare rapidă a limbajelor de programare. Cursanții sunt încurajați să se implice în cât mai multe proiecte pentru a-și dezvolta capacitățile de lucru, a testa și a alege ceea ce li se potrivește mai bine. În cele 6 luni pot dezvolta mai mult în front-end sau back-end. Nu se pun note și nu se fac evaluări ca la școală. Github este cel mai bun prieten al nostru. Acolo vedem câte linii de cod a scris fiecare și contribuția lor la proiecte. Cunoșt ințe dob ândite în ur ma training-ului: • tehnologii web avansate și limbaje moderne: HTML & CSS, Ruby on Rails, JavaScript. • instrumente de lucru precum Github, Agile Development, Test Driven Development . • noțiuni de product development și user experience/UX design. • metode de dezvoltare tip agile și tehnici de „lean startup” pentru afaceri. • folosirea platformelor online de management eficient al proiectelor web și al echipei. • tehnici de vânzare și marketing al serviciilor și produselor tehnologice. Dincolo de competențele practice, rolul nostru e de a pregăti generația viitoare cu skill-urile necesare pentru a crea tehnologia de care avem nevoie. Bootcamp-ul

Simplon e unic și din perspectiva pe care o oferă cursanților asupra tehnologiei. Selecționând candidați cu pregătire în domenii foarte diferite, dar având toți aceeași motivație mare, Simplon dezvoltă o comunitate de talente interdisciplinare care fac schimb de idei și de competențe lor pentru crea noi tehnologii. La final, codul este doar un pretext. Ce e important pe lângă capacitatea de a scrie și citi cod, este mindset-ul de învingător, gândirea logică și orientată spre rezolvarea problemelor complexe.

Pe lângă bootcamp și programul de incubare dedicat antreprenorilor, Simplon organizează evenimente, ateliere pentru copii, workshop-uri pentru fete și femei sau angajații din companii care vor sa învețe programare sau să afle care sunt cele mai noi tehnologii și tendințe în inovație. Mai multe despre Simplon România puteți afla pe site-ul ro.simplon.co

Un partener pentru cei care caută talente și investesc în inovație, educație și antreprenoriat social

Într-un singur an, Simplon.co a oferit traininguri pentru 305 de adulți și 417 copii din Franța, generând peste 100 de evenimente și 13 hackathon-uri. Scopul activităților noastre în România este de a aduce diversitate și inovație în domeniul IT prin dezvoltarea unei comunități de talente creative, pasionate de tehnologie și antreprenoriat. Tehnologia este prezentă în toate domeniile de activitate: educație, transporturi, sănătate, turism, începând din laboratoare și până în buzunarele noastre. Suntem aproape dependenți de smartphone-uri iar în curând ne vom controla casa la distanță cu ajutorul lor. De aceea credem că ar fi bine să și înțelegem cum poate fi controlată tehnologia și nu doar să o folosim.

nr. 26/august, 2014 | www.todaysoftmag.ro

Roxana Rugină

roxana.rugina@gmail.com CEO & co-founder @ Simplon Romania

eveniment

TODAY SOFTWARE MAGAZINE

Cea de a treia ediţie a conferinţei de testare de software din Europa de Sud-Est (SEETEST 2014)

ucureşti, 4 august 2014. În 25 şi 26 septembrie, Hotel Crowne Plaza găzduieşte cea de a treia ediţie a conferinţei de testare de software din Europa de Sud-Est (SEETEST 2014), organizată de South East European Testing Board în colaborare cu Asociaţia Patronală a Industriei de Software şi Servicii (ANIS) şi Quality House. Biletele early bird sunt disponibile până la data de 31 august şi pot fi achiziţionate online la http://seetest.org/index.php?page=registration. SEETEST 2014 este singura conferinţă din Europa de Sud-Est despre testarea şi managementul calităţii software-ului. În prima zi a evenimentului, participanţii vor avea ocazia să vadă tutoriale susţinute de experţi recunoscuţi din industrie, care vor aborda subiecte precum principiile testării agile, excelenţa centrelor de testare, abilităţi soft pentru testeri, TMMi, încărcare & performanţă sau principiile de bază ale testării de aplicaţii mobile. Cea de a doua zi a evenimentului este dedicată discursurilor susţinute de executivi de top din industria internaţională de testare de software. Tot în această zi vor avea loc prezentări ale lucrărilor membrilor comunităţii inginerilor de calitate. Pe toată durata conferinţei va fi organizată o expoziţie care va oferi companiilor internaţionale din domeniul calităţii software-ului şansa de a-şi prezenta instrumentele folosite şi serviciile în faţa audienţei. Mai mult, un examen ISTQB Certified Tester Foundation va avea loc în timpul evenimentului şi va fi oferit de

South East European Testing Board. Printre subiectele care vor fi abordate în cadrul SEETEST 2014 se numără testarea de software, tehnici şi design al testării, managementul proceselor de testare, testarea bazată pe risc, îmbunătăţirea proceselor de testare, performanţa testării, testare agile, testare în securitate, testare mobile sau automatizarea testării. Aceste subiecte vor fi aduse în discuţie de lideri consacraţi din industrie. Printre invitaţii care au confirmat prezenţa la SEETEST 2014 se numără Rex Black (software engineer, antreprenor şi autor în domeniul testării software, USA), Erik van Veenendaal (expert în testare recunoscut la nivel internaţional, Olanda), Graham Bath (autor, Germania), Geoff Thompson (senior test management consultant, Marea Britanie), Yaron Tsubery (Director QA & Testing Manager Comverse, Israel) sau Vipul Kocher (Preşedinte al Indian Testing Board şi Co-Preşedinte al PT PureTesting, India). C ele două ediţii anterioare ale

conferinţei de testare de Software din Europa de Sud-Est (SEETEST) au avut loc în Sofia, Bulgaria, în 2008 şi 2009 şi au reunit peste 250 de vizitatori. SEETEST 2014 va aduce împreună aproximativ 300 de participanţi care vor avea şansa de a vedea 6 tutoriale de o jumătate de zi organizate în 3 sesiuni paralele şi 14 prezentări. Preţul unui bilet la conferinţă este de 350 EUR şi include intrarea la toate sesiunile conferinţei, tutoriale, prezentări şi expoziţie, documentele suport, mesele de prânz şi pauzele de cafea, precum şi intrarea la evenimentul social care va fi organizat pe data de 25 septembrie. Diferite variante de bilete sunt disponibile la preţuri mai mici pentru cei care doresc să participe doar la anumite părţi ale SEETEST 2014. Mai multe informaţii despre bilete şi preţurile acestora sunt disponibile online la http://seetest.org/index.php?page=visitors Biletele early bird oferă o reducere de 20% faţă de preţul integral şi sunt disponibile până la data de 31 august. Grupurile de peste 5 persoane, membrii organizaţiilor partenere, studenţii şi partenerii ISTQB beneficiază de o reducere de 10% disponibilă după încheierea perioadei early bird. Biletele la SEETEST 2014 sunt disponibile online la http://seetest.org/index. php?page=registration.

Irina Scarlat

irina.scarlat@howtoweb.co PR Manager @ How to Web & TechHub Bucharest

www.todaysoftmag.ro | nr. 26/august, 2014

eveniment

Aplicaţie IT în SAP, dezvoltată de msg systems România, prezentată la ‘IT Conference on SAP technologies 2014’- Cluj şi la inscom 2014

sg systems România a dezvoltat în Cluj-Napoca, un produs IT bazat pe ultimele tehnologii propuse de SAP. Proiectul demarat exclusiv la Cluj, în materie de coordonare tehnică şi implementare, a presupus extinderea flexibilităţii unor produse deja existente şi apreciate de către clienţii branşei asigurări-reasigurări, din portofoliul msg systems: Munich Re, Viena Insurance Group, GenRe, AIG, Volkswagen Bank, Achmea, Nationale Niederlande, Samsung Life Insurance. Aplicaţia IT a fost gândită de către architecţi cu experienţă în SAP, în colaborare cu consultanţi business ai branşei asigurări – reasigurări. Dezvoltarea software propriu-zisă a fost făcută de către o echipă de nouă programatori SAP. Prototipul rezultat a fost foarte apreciat în cadrul grupului msg trecand cu succes și primele prezentări live în faţa clienţilor. În prezent, se discută cu aceştia dezvoltarea de functionalităţi noi specifice cerinţelor lor actuale. Rezultatul final urmează a fi prezentat pentru prima data în Cluj, în cadrul celei de-a doua ediţii a conferinţei IT pe tehnologii SAP din 4 septembrie 2014. Conferinţa organizată de msg systems Romania în Cluj se adresează tuturor programatorilor familiarizaţi cu aplicaţiile enterprise și în special celor cu înclinaţii spre tehnologiile SAP. Cuvintele cheie ale conferinţei de la Cluj Napoca sunt business rules, enterprise user experience, reporting & analytics, iar pentru cei tehnici: SAP HANA, SAP Fiori, UI5. Înscrierea la “Conferinţa IT bazată pe tehnologii SAP – ediţia 2” este deja deschisă. Toţi cei care doresc să ia parte la acest eveniment sunt rugaţi să trimită un e-mail cu confirmarea de participare la adresa: info-events@msg-systems.com. Mai mult, aplicaţia dezvoltată de msg systems România la Cluj va fi prezentată că şi head-line inovativ în cadrul inscom 2014, conferinţă cu teme exclusive de asigurări şi reasigurări, care se va desfăşura în Germania, în prezența CEOs ai celor mai mari companii din acest domeniu din întreaga lume.

nr. 26/august, 2014 | www.todaysoftmag.ro

Horea Rațiu

horea.ratiu@msg-systems.com Director Departament SAP @ .msg systems Romania

comunități

TODAY SOFTWARE MAGAZINE

Comunităţi IT

u toate că multă lume este în concediu, vă invităm să participați la evenimentele care vor avea loc în lunile august si septembrie. Today Software Magazine vă propune Lansarea numărului 26 / august a revistei TSM, IT Conference on SAP și Design Patterns Class. Toate acestea sunt gratuite, se anunță să fie interesante și cu multe lucruri de învățat.

Transylvania Java User Group Comunitate dedicată tehnologiilor Java. Website: www.transylvania-jug.org Data înfiinţării: 15.05.2008 / Nr. Membri: 585 / Nr. Evenimente: 46 Comunitatea TSM Comunitate construită în jurul revistei Today Software Magazine. Website: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmag Data înfiinţării: 06.02.2012 /Nr. Membri: 1671/Nr. Evenimente: 21 Cluj Business Analysts Comunitate dedicată analizei de business Website: www.meetup.com/Business-Analysts-Cluj Data înfiinţării: 10.07.2013 / Nr. Membri: 80 / Nr. Evenimente: 8 Cluj Mobile Developers Comunitate dedicată tehnologiilor mobile Website: www.meetup.com/Cluj-Mobile-Developers Data înfiinţării: 05.08.2011 / Nr. Membri: 221 / Nr. Evenimente: 14 The Cluj Napoca Agile Software Meetup Group Comunitate dedicată metodelor Agile de dezvoltare software. Website: www.agileworks.ro Data înfiinţării: 04.10.2010 / Nr. Membri: 440 / Nr. Evenimente: 81 Cluj Semantic WEB Meetup Comunitate dedicată tehnologiilor semantice. Website: www.meetup.com/Cluj-Semantic-WEB Data înfiinţării: 08.05.2010 / Nr. Membri: 187/ Nr. Evenimente: 28 Romanian Association for Better Software Comunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare. Website: www.rabs.ro Data înfiinţării: 10.02.2011 / Nr. Membri: 246/ Nr. Evenimente: 14 Tabăra de testare Un proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri. Website: www.meetup.com/Tabara-de-Testare-Cluj/ Data înfiinţării: 15.01.2012 / Nr. Membri: 337/ Nr. Evenimente: 32

Calendar August 12 (Cluj) Lansarea numărului 26 a Today Software Magazine (Cluj) www.todaysoftmag.ro August 18-23 (Cluj) MoodleMoot Romania 2014 it-events.ro/events/moodlemoot-romania-2014-18-23-august-cluj-napoca/ August 21 (Iași) Mastering Requirements meetup.com/Tabara-de-Testare-Iasi/events/181662022/ August 21 (Cluj) #13 PM Meetup - Risk Management meetup.com/PMI-Romania-Cluj-Nap o ca-Projec tManagement-Meetup-Group /events/194808502 August 27 (București) Bucharest FP #3 — Haskell Types and QuickCheck meetup.com/bucharestfp/events/198339372 August 29 (Oradea) Startup Weekend Oradea oradea.startupweekend.org Septembrie 4 (Cluj) IT Conference on SAP - recomandat de TSM http://www.msg-systems.ro/agenda_sap.0.html Septembrie 8 (Cluj) Design Patterns Master Class - recomandat de TSM codecamp-cluj-sept2014.eventbrite.com Septembrie 16-17 (Cluj) Service Delivery Innovation Summit (London, UK) serviceinnovationevent.com Septembrie 24 (Târgu Mureș) Lansarea numărului 27 TSM alături de Cluj IT Cluster www.todaysoftmag.ro

www.todaysoftmag.ro | nr. 26/august, 2014

management

programare

Informație structurată - aplicare Agile

anagementul este într-o continuă evoluție. Noi framework-uri, noi metodologii sunt inventate, reinventate și adaptate pentru a satisface nevoile unei piețe foarte dinamice. De fiecare dată când apare ceva nou, la început luptăm împotriva schimbării pentru ca mai apoi, după ce câțiva temerari demonstrează valoarea noului concept suntem gata să-l adoptăm drept noua noastră religie. La fel s-a întâmplat în cazul Waterfall și Scrum și la fel se întâmplă în ultima vreme cu Kanban. Bogdan Mureșan

bogdan.muresan@3pillarglobal.com Director of Engineering @ 3Pillar Global

nr. 26/august, 2014 | www.todaysoftmag.ro

Business-urile evoluează într-un ritm amețitor iar framework-urile ce permit o adaptare rapidă și o lansare rapidă pe piață au fost grupate în ceea ce se numește conceptul Agile, cea mai în vogă și cea mai folosită sintaxă din domeniul IT din ultimii ani. Cu toate aceste framework-uri ce se învărt în jurul nostru managerii pot cădea rapid într-o stare de automulțmire uitând bazele și esența a ceea ce înseamnă management de proiect. Bazele managementului de proiect sunt bine definite, bine structurate și, în opinia mea, în ciuda a ceea ce crede multă lume, a cunoaște și a evolua pe baza unor cunoștințe structurate nu contravine deloc cu regulie jocului Agile. Din contră, aceste cunoștințe pot fi adaptate, devenind o unealtă puternică atunci când vrem să jonglăm cu framework-urile de genul Scrum, Kanban etc. . Ca și mulți alții din acest domeniu, evoluția mea spre management de proiect a trecut prin mai multe stadii, începând ca programator, mai apoi conducănd echipe din punct de vedere tehnic, pentru ca mai apoi să mă îndrept spre managementul de proiect. Am avut noroc să urmez un curs de management de proiect, dar cel mai mult am învățat în ‘focul luptei’. Absolut

normal, procesul nu a fost unul liniar ci a fost unul cu suișuri și coborâșuri.Dar cu siguranță acelea au fost momentele care au dat roade mai târziu. Încetul cu încetul au început să apară așa numitele momente de conștientizare a experienței. Odata ce începem să fim tot mai siguri pe noi și să caștigăm tot mai multă experiență, căutăm o certificare care să ne ajute în noul nostru obiectiv. Acela a fost momentul pentru mine în care am devenit tot mai interesat de ceea ce înseamnă PMI și PMP. Ca să fim bine înțeleși, intenția mea nu e de a face reclamă celor de la PMI, încă nu am aplicat pentru a-mi lua certificarea. Este ceva ce vreau să fac anul acesta. Până în acest moment am participat la orele de curs necesare pentru a mă putea înscrie pentru examen. M-am hotărât să scriu acest articol deoarece atât în timpul orelor de curs cât și în multe alte discuții legate de certificarea PMP am auzit multe dezbateri dacă această teorie se aplică sau nu în proiectele Agile. După cum ați observat probabil chiar din primele rânduri, părerea mea este că acele cunoștințe necesare obținerii certificării PMP sunt un bun de mare preț (și obligatoriu în același timp) pentru orice manager de proiect ce se învârte în lumea Agile.

programare Certificarea PMI îți oferă informații structurate într-un anumit fel, o mulțime de documentație, o cale clară despre cum se gestionează un proiect de la începuturi și până la terminarea sa (și nu doar în industria IT). Principiile pe care se bazează sunt prinse într-o carte destul de voluminoasă numită PMBok. În același timp Agile nu prea ne obligă la tone de documentație, nu are legatură cu o cale și reguli bătute în piatră, dar obiectivul e același: terminarea cu succes a unui proiect. Voi justifica această opinie făcând o paralelă cu Scrum-ul pentru că cea mai mare parte din experiența mea cu framework-uri Agile merge înspre Scrum. Scrum-ul definește niște roluri printre care regăsim cel puțin unul care nu are legătură cu teoriile generale de project management și anume rolul de Scrum Master. Scrum Master-ul este un fel de super erou care are putere deplină asupra procesului și care trebuie să rezolve toate impedimentele astfel încât echipa să-și poată face treaba. Dacă ne luăm după manual, el deține drepturi depline asupra procesului dar nu are autoritate asupra echipei. Unele companii au rezolvat acest aspect folosind manageri de linie împreună cu Scrum Master-ii, alte companii au rezolvat acest aspect combinând rolul de Scrum Master cu cel de manager de linie (caz în care rolul de Scrum Master se identifică cu cel de manager de proiect). Nu există rețeta ideală, dar important este să se potrivească în contextul respectiv. Oricare ar fi contexul și rolurile, persoana care controlează procesul trebuie sa știe ce face. La fel și cu persoana care are responsabilitate asupra echipei. Pentru aceasta și nu numai, bazele managementului de proiect sunt foarte

TODAY SOFTWARE MAGAZINE importante. Structura PMBok-ului se bazează (cel puțin în ultima ediție, deoarece și PMI evoluează în continuare) pe 47 de procese. Acestea sunt grupate în 5 grupuri și 10 arii de cunoștințe. Pentru a fi în conformitate cu cerințele PMI trebuie să lucrăm cu structura care se potrivește în acest peisaj. Aici apare și dilema: învățând acest mod structurat de face lucrurile, avem vreun beneficiu în viața de zi cu zi din proiectele mele Agile? Normal că avem (zic eu). Să începem cu cele 5 grupe de procese: Inițierea, Planificarea, Executarea, Monitorizarea și Controlul și Închiderea. Practic ne referim la ciclul normal de viață al unui proiect. Orice proiect trebuie să aibă un început. Nu putem să începem din mijlocul lui, trebuie să existe o fază inițială. Chiar și atunci când suntem în situația nu chiar de dorit de a continua munca începută de alții (situație de nedorit în mare parte din cauza ego-ului nostru deoarece ne simțim mult mai împliniți atunci când începem un proiect de la zero și-l ducem la linia de sosire; situație care de altfel e o oportunitate perfectă să dăm vina pe vechea ehipă de fiecare dată când apar probleme sau erori din momentul în care-l preluăm până la sfârșitul lui). Indiferent de framework-ul folosit pentru a duce la bun sfârșit proiectul, în faza de inițiere trebuie să identificăm stakeholderii. Iată că încep să apară părțile comune. Pentru a urma principiile din PMBok, în faza de planificare stabilim regulile jocului și definim cum vom face totul de la începutul până la sfârșitul proiectului, urmând a actualiza unele informații pe măsură ce înaintăm. Ca adepți ai metodologiei Agile

nu planificăm totul de la început, dar recurgem la planificări pe tot parcursul proiectului în bucățele mai mici. Dacă suntem adepți ai Scrum-ului ne vom planifica iterațiile, ne vom planifica munca de zi cu zi si nu numai. Executarea, monitorizarea și controlul se referă la munca efectivă necesară pentru a termina proiectul. Ce face un manager de proiect sau un Scrum Master? Același lucru: gestionează munca în sine, comunicarea,stakeholder-ii, procesul de testare, riscurile, adică toate palierele unui proiect. Așa cum afirmam mai sus, pe lângă cele 5 grupuri de proces, PMBok organizează informația în 10 arii de cunoștințe. Deși nu intenționez să le prezint integral, ar fi interesant de observat cum se mapează câteva din ele peste ceea ce se întâmplă în lumea Scrum-ului. Grupul magic al celor 3 (timp, scop, cost) rămâne esența a ceea ce facem. Dacă în lumea structurată a PMI-ului estimăm ceea ce vom face încă de la început când lucrăm cu Scrum facem același lucru dar în părți mai mici. Când planificăm o iterație ținem cont de aceeași parametri principali: scopul (care vine din backlog-ul prioritizat), scop pe care îl ajustăm în funcție de velocitate (velocitatea depinde bineînțeles de echipă care împreună cu alte date de intrare se traduce în cost). Trebuie să realizăm acest scop într-un timp bine definit dat de lungimea iterației. Foarte asemănător cu modul în care creăm WBS-ul realizăm și spargerea story-urilor în task-uri. Dacă ne gandim la un proiect care este manageriat după regulile PMI ca referință (proiectele conduse după metoda Waterfall se mulează perfect pe această structură) putem să vedem

Our core competencies include:

Product Strategy

Product Development

Product Support

3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world. Our oﬀerings are business focused, they drive real, tangible value.

www.3pillarglobal.com

www.todaysoftmag.ro | nr. 26/august, 2014

management Informație structurată - aplicare Agile fiecare iterație în parte ca o reprezentare în miniatură a referinței: bine organizată, bine planificată și bine definită în timp. O altă arie importantă din cele 10 este managementul riscului. În amândouă situațiile este un proces perpetuu. Evaluăm riscul după priceperea noastră și ca să fim eficienți trebuie să cunoaștem cel puțin bazele. Există câteva tehnici care ne vor ajuta să identificăm riscurile. Trebuie să știm care riscuri sunt mai importante, care au impactul mai mare și să definim care vor avea nevoie de acțiuni din partea noastră. Putem face un plan pentru a evita anumite riscuri, pentru a transfera către o terță parte anumite riscuri. Ce este important este să știm opțiunile noastre pentru a deveni mai eficienți. Aceasta nu depinde de framework-ul cu care lucrăm (Scrum, Kanban). De asemenea, realizăm ca informația structurată, bazele, esența, nu sunt deloc departe de lumea Agile. Ca Scrum Master-i gestionăm procesul și vom face tot posibil pentru a înlătura impedimentele din calea echipei. Câteodată aceste impedimente se referă la nevoia integrării cu un serviciu oferit de altcineva. Câteodată poate fi ceva simplu precum achiziționarea unui set de controale, câteodată poate fi ceva mai complicat precum integrarea cu un provider pentru suport on-line pentru produsul nostru. Ceea ce trebuie să știm în calitate de Scrum Master-i este cum să facem managementul achiziților. Trebuie să știm cum să definim regulile pentru selectarea vendorului și cum să realizăm contractul cu vendorul.

Dacă ținând cont de teorie Scrum Master-ul nu are autoritate asupra echipei, acest lucru nu înseamnă că în echipă nu pot apărea conflicte. Nu înseamnă că nu vor exista persoane demotivate în echipă. Managementul resurselor umane ne învață să gestionăm astfel de situații. Toată lumea a auzit de piramida nevoilor lui Maslow, dar mai sunt multe teorii care ne pot ajuta. Un minim de cunoștințe despre această arie ne va da posibilitatea să ne adaptăm la context și să alegem soluția potrivită în funcție de situație. Nu este nevoie să intru în toate detaliile fiecărei arii de cunoaștere dar dacă am face o analiză și mai detaliată, am constata că acele cunoștințe care ne ajută să gestionăm un proiect respectând calea PMI, se aplică și în framework-urile Agile. Evoluția noastră ca manageri nu ar trebui să se oprească la primul framework care funcționează. Cu cât știm mai multe, cu atât putem acționa mai eficient deoarece nu vorbim de lucruri bătute în piatră ci vorbim de adaptare. Vom putea să ne adaptăm, să mixăm și să folosim ceea ce știm pentru a crește eficiența lucrului făcut de noi. Esența poate să vină structurată în multe metodologii (PMI, PRINCE2 etc.). Framework-urile Agile nu ar trebui să ne îndepărteze de informația organizată. Chiar mai mult de atât aceste frameworkuri ne dau posibilitatea de a jongla cu această informație cum vrem noi, ne dau posibilitatea să fim acei rebeli care nu fac o analiză de risc doar în momentele bine stabilite de la început ci realizează această analiză și ad-hoc dacă simt ei că trebuie.

nr. 26/august, 2014 | www.todaysoftmag.ro

Depinde doar de noi cum aranjăm piesele acestui puzzle uriaș și cum ne jucăm cu el. Cu cât știm mai multe, cu atât mai multe sunt posibilitățile. Mai multe posibilităti de unde să alegem înseamnă automat și mai multe șanse de succes, dar câteodată și de eșec. Dar nu vom ști niciodată ce pierdem dacă nu vom continua să evoluăm.

programare

Întreținerea la zi a sistemelor Linux – Partea a II-a

cest articol are ca subiect sistemul de stocare care se pretează cel mai bine într-un centru de calcul. Înainte de a prezenta considerațiile privitoare la selecția sistemului de fișiere pentru un centru de calcul, vom realiza o scurtă clasificare și istorie a sistemelor de fișiere.

Sorin Pânca

sorin.panca@yardi.com Senior Systems Administrator @ Yardi România

Sistemele de fișiere se împart în două categorii, în funcție de localizarea lor: A. Sisteme de fișiere locale - de obicei aceste sisteme rezidă pe un dispozitiv local: i. disc dur cu platane (HDD); ii. memorie NAND ce poate fi conectată la sistem prin interfața SATA sau SAS (caz în care se numește SSD), sau prin interfața USB (caz în care se numește „stick USB” sau „pen drive”); iii. disc optic (CD/DVD/BlueRay); iv. R AID - mai multe medii de stocare identice compun un mediu de stocare mai voluminos și/sau care oferă redundanță la nivel de bloc de date (data block); v. me mor ie R AM c u ac umu l ator, conectată la interfața PCIe; vi. memristor (nelansat încă).

Memorie și Periferice. Între Periferice, mediul de stocare a evoluat de la un mediu de pe care se poate doar citi la un mediu pe care sistemul poate să și scrie.

Evoluția sistemelor de stocare locale a fost în linii mari următoarea: • carduri perforate (permiteau doar citire, scrierea se făcea manual); • benzi magnetice; • discuri cu platan (cu diametre de ordinul metrilor); • dischete flexibile de 5,25”; • dischete flexibile de 2,5” (cu capacități de 850 kO, utilizând o singură față; 1,44 MO, utilizând ambele fețe; 2,88 MO, utilizând ambele fețe și o densitate mare a datelor); • discuri dure de 3,5”; B. Sisteme de fișiere pe rețea (nu le • restul de medii, enumerate mai sus. voi enumera pe toate, ci voi da doar câteva exemple, în ordinea evoluției, pentru a ilustra A urmat revoluția rețelelor, când a apărut arhitecturile și conceptele ce le au în comun și nevoia de a transfera fișiere fără a duce fizic care stau la baza funcționării lor): un suport de date (discheta) de la un sistem i. cu punct de acces unic, pe modelul la altul, în special în scopul comunicării în client - server: CIFS (cunoscut ca My timp real. Network Places în Windows), NFS, FTP, Astfel a apărut ideea de „model server rsync, IMAP, scp, WebDAV, etc.; - client” în care un sistem care deținea o ii. de tip cluster cu replicare la nivel resursă (de exemplu un fișier) putea să o de bloc de date: DRBD, Microsoft DFS, pună la dispoziția altor sisteme folosind un GlusterFS; limbaj de comunicare (protocol) printr-un iii. de tip cluster cu replicare la nivel de canal de comunicație (rețeaua); acest sistem fișier: Lustre, Ceph, MooseFS, XtreemFS. joacă rolul de „server” (sau servitor, pentru că servește resurse). Un sistem de calcul care Istoric, calculatoarele erau sisteme izo- are nevoie de o resursă (clientul) ce se găsește late a căror arhitectură consta în: Procesor, pe un alt sistem, poate contacta sistemul www.todaysoftmag.ro | nr. 26/august, 2014

programare Întreținerea la zi a sistemelor Linux – Partea a II-a de la distanță (serverul) prin canalul de comunicație (rețeaua), folosind un limbaj de comunicare (protocolul) pe care ambele sisteme îl înțeleg (exemple de protocoale: FTP sau HTTP sau IMAP din enumerarea de mai sus; „P” în aceste nume provine de la cuvântul „protocol”). O teorie frumoasă. Problemele practice întâmpinate în scenariul de mai sus sunt următoarele (în cazul în care acestora li se găsesc soluții, rezolvarea lor este notată cu R) : • doi clienți vor să actualizeze aceeași resursă deodată (R: sistemele de fișiere de rețea implementează blocarea resurselor); • prea mulți clienți doresc aceeași resursă, epuizând capacitatea de servire a serverului (R: RAID0, RAID10, SSD, memorie RAM cu acumulator, sisteme de fișiere de rețea de tip b și c); • spațiul de stocare al serverului se epuizează (R: sisteme de stocare de rețea de tip c - care sunt extensibile); • serverul devine indisponibil datorită unei pane de curent (R: UPS); • adaptorul de rețea al serverului se defectează în timpul unui transfer sau al mai multor transferuri simultane, având ca efect coruperea datelor transferate sau trunchierea lor (R: mai multe adaptoare de rețea agregate); • sincronizarea între mai multe servere trebuie să se facă instant pentru toată cantitatea de date (R: sisteme de fișiere de rețea de tip b sau c); • fiecare client dorește să caute prin toate datele stocate și căutarea să se termine în mai puțin de o secundă (R: Full Text Search DB); • datele stocate pe server sunt vechi, deoarece serverul face parte dintr-un lanț de servere care trebuie să se sincronizeze, iar sincronizarea are loc doar la un anumit interval (R: sisteme de stocare de rețea de tipul c); • datele stocate pe server se corup sau se pierd, deoarece se defectează mediul local de stocare al serverului (R: RAID(1,5,6,10), sisteme de stocare de rețea de tip b sau c); • serverul devine indisponibil, deoarece se defectează o componentă importantă: placa de bază, procesorul, memoria, sursa de alimentare (R: sisteme de stocare de rețea de tip b sau c); • unele date au nevoie de redundanță mai mare decât altele (R: sisteme de stocare de rețea de tipul c); • erori umane (rm -rf /home /var; știți voi la ce (sau cine) mă refer).

Din lista de mai sus se observă că cel mai mic multiplu comun când vine vorba despre reziliență la „catastrofe” este tipul de stocare pe rețea „c” - cu acest tip de stocare rezolvăm cele mai multe probleme. În ceea ce privește protecția datelor, companiile care vând soluții de stocare s-au axat pe stocarea locală și au creat matrici de discuri (RAID = Redundant Array of Inexpensive Disks) în diferite formații: i. RAID0 - nu oferă protecția datelor, în schimb oferă spațiu și viteză: fișierele sunt fragmentate în blocuri de date (de cca 4 până la 64 kO) care sunt împărțite relativ egal pe toate mediile de stocare din matrice, astfel încât atât la scriere cât și la citire, fragmentele de fișier sunt procesate în paralel. ii. RAID1 - oferă protecția datelor prin înscrierea lor pe toate mediile de stocare componente ale matricii; scrierea durează la fel ca și când ar fi pe un singur mediu, în schimb citirea este mai înceată deoarece se citesc datele de pe toate mediile componente și sunt comparate pentru a oferi sistemului varianta corectă; varianta corectă, în cazul în care nu există quorum se stabilește prin viteza de răspuns a mediului: mediile defecte răspund mai încet sau deloc; dacă datele recepționate nu diferă între medii, iar timpul de răspuns e comparabil, mediile se consideră „sănătoase”. iii. RAID5 - oferă protecția datelor prin calculul unei sume de control; viteză mai scăzută atât la citire cât și la scriere în comparație cu un singur mediu iv. RAID6 - oferă protecția datelor prin calculul a două sume de control; viteză mai scăzută decât RAID5 v. RAID10 - este o combinație între RAID1 și RAID0: mai multe perechi de discuri în configurație de replicare (RAID1) sunt înlănțuite pentru a oferi spațiu și viteză (RAID0) vi. RAID50 - căutați pe Internet. Aceste soluții oferă o oarecare protecție câteodată, altădată viteză, dar nu rezolvă probleme ce pot apărea la alte componente ale sistemului: procesor, memorie, placă de bază, placă de rețea, dorința imperioasă a administratorului de a opri sistemul, etc. . Prima soluție de a oferi disponibilitate sporită (high availability) a serverelor de fișiere a fost aceea de a crea RAID1 prin rețea. Astfel a apărut DRBD, care simulează un mediu de stocare ce are ca motor discurile locale a două servere pereche. Aceste două servere țin fișierele sincronizate, pot accesa sistemul de fișiere simulat și îl

nr. 26/august, 2014 | www.todaysoftmag.ro

pot pune la dispoziția clienților din rețea folosind un protocol standard (CIFS, NFS, rsync, etc.). Pentru a obține disponibilitate sporită, sistemul de fișiere e accesat prin rețea printr-o „adresă IP de serviciu”, care e mutată de pe un server pe celălalt manual sau automat. Astfel un server este considerat „activ”, iar celălalt e „în așteptare”. Problema este că sistemul de fișiere poate fi extins anevoios: se oprește câte un server, se mărește spațiul pe primul, se copiază datele de pe al doilea, se mărește spațiul pe al doilea, se recreează replicarea. O altă problemă este costul: pentru a obține o „instanță server” disponibilă pentru client se dublează capacitatea de calcul, cu costurile aferente, fără a se obține un beneficiu continuu. Beneficiul apare doar în momentul când unul din servere devine inoperabil, ceea ce practic reprezintă aproximativ 0% din durata de viață a sistemului. În unele cazuri aceste costuri sunt justificate (când datele și accesul neîntrerupt la ele este vital - de exemplu la sistemele de menținere a vieții). Aceeași problemă o au toate sistemele care replică datele la nivel de bloc. De asemenea, faptul că replică la nivel de bloc de date înseamnă că spațiul pe care îl va utiliza trebuie prealocat, ceea ce conduce la un management ineficient din partea administratorului: cât spațiu să se aloce, achiziția de servere noi, identice, care să ofere suficient spațiu de la început (nu se pot folosi servere care deja există în centrul de calcul), timp de indisponibilitate a sistemului (până când este reconfigurat spațiul de stocare și este reinstalat serverul). Dacă se reconfigurează un server mai vechi, intervine și migrarea vechilor date în altă parte. (În încheierea introducerii doresc să fac o paranteză la adresa capitalismului și a consumerismului: mulți programatori și administratori de sisteme se plâng de faptul că firma la care lucrează le face viața grea încercând să folosească servere vechi, deja existente, în loc să investească bani în utilaje noi, de ultimă oră. Aceasta denotă o lene sau o inabilitate a administratorului sau programatorului în a face planurile necesare pentru reutilizarea sistemelor sau pentru optimizarea codului. Bineînțeles, cu bani oricine poate face orice. Arta adevărată e să poți obține profit cu cea mai mică investiție posibilă. Cu cât profitul este mai mare, cu atât angajații, nu companii externe, care vând sisteme noi, programe sau consultanță se bucură de acel profit. De aceea, Google, Facebook și alte firme de succes nu doar că își scriu propriile programe și folosesc programe

TODAY SOFTWARE MAGAZINE gratuite, ci își și proiectează sistemele fizice și centrele de calcul și le comandă direct la producătorii originali de echipamente din China (OEM - Original Equipment Manufacturers). Cu cât munca unui angajat poate fi externalizată (outsourced) mai ușor, cu atât valorează mai puțin. Valoarea unei companii constă în calitatea muncii angajaților ei, care se măsoară în profit minus cheltuială, nicidecum în bunurile pe care le achiziționează. Altfel, o companie poate avea activitățile total externalizate și ar deveni fond de investiții.)

Sistemul de fișiere de rețea

Deși în urma unui vot noi folosim momentan GlusterFS, voi prezenta o soluție pe care am testat-o timp de 3 ani: MooseFS. În articolul trecut menționam faptul că am început să folosim XtreemFS. Arhitectura acelui sistem de fișiere părea la prima vedere una interesantă, fără nici un punct de slăbiciune la catastrofe (no single point of failure). Între timp am aflat că nu este suficient de extensibil în ceea ce-i privește componentele - serviciul de replici și metadate (MRC) și servicul director (DIR), iar autorii doresc să îl distribuie doar ca binar în viitor, ceea ce este ortogonal cu principiile enunțate la sfârșitul introducerii. Inițial am studiat toate variantele de sisteme de fișiere de rețea, documentâdu-mă din experiențele altora și înțelegând funcționarea teoretică a fiecărui sistem de fișiere în parte. Ca urmare a acestui proces, am ales pentru intenția de testare practică două sisteme: Lustre și MooseFS. Când un arhitect al infrastructurii decide asupra tehnologiei ce se va folosi în companie, mare parte a timpului trebuie petrecută

asupra documentației și stabilirii de liste pro și contra pentru fiecare soluție, atât din punct de vedere tehnic (observând exact facilitățile oferite), cât și din punct de vedere al costurilor financiare și de timp de implementare. În ceea ce privește vechimea pe piață și popularitatea soluției, acestea sunt subiecte critice care trebuie dezbătute atent pentru a nu trage concluzii greșite. Un sistem care există de mult timp pe piață este categoric mai popular decât un sistem mai nou, deoarece a avut timp să fie adoptat cât încă cel nou nu exista. Pentru a face o comparație corectă, echitabilă, trebuie să se calculeze o statistică estimată pentru noul sistem pentru același număr de ani pe care îl are sistemul vechi, la rata de adopție (creștere) comparată pentru perioada de viață a sistemului nou. De exemplu, dacă ar fi să comparăm GlusterFS și MooseFS, am face următorul calcul. Presupunând că GlusterFS este de zece ani pe piață, iar MooseFS de doi ani, privim la rata de creștere a MooseFS în primii doi ani și estimăm creșterea pentru următorii zce ani folosind rata din primii doi ani. Apoi comparăm creșterea MooseFS estimată pe zece ani cu cea existentă pe zece ani a GlusterFS. Un sistem nou care este distribuit gratuit nu apare pentru că un programator s-a gândit că nu are cu ce să-și piardă nopțile. Acel programator a investigat piața soluțiilor gratuite și nu a găsit ceva satisfăcător. Probabil a investigat chiar și piața soluțiilor comerciale. Decizia de a scrie de la zero un program distribuit gratuit nu se ia ușor. Mai ales când este vorba un sistem de fișiere care are ca public țintă tocmai organizațiile a căror funcționare se

bazează pe acele date, inclusiv organizația din care face parte programatorul. Iar dacă un proiect atrage mulți contribuitori și soluția este adoptată în medii de afaceri și academice în detrimentul altor soluții, avem dovada că acel sistem nou este superior celui vechi și în timp îl va înlocui, acolo unde este posibil. Exită mitul, că sistemele vechi sunt mai stabile și mai de încredere decât cele noi. Într-adevăr se poate întâmpla ca sistemele vechi să conțină mai puține defecte (bug-uri), dar e important de luat în considerare faptul că și un sistem vechi care e încă în dezvoltare continuă să acumuleze defecte. Nu există o metodă de a demonstra matematic că un sistem mai are sau nu defecte sau că are mai multe sau mai puține decât un alt sistem de orice vârstă. Un sistem utilizat de organizații în producție de mai mulți ani (chiar și de un an), poate fi considerat la fel de stabil și de încredere ca și unul vechi. Pe de altă parte, despre un sistem vechi se știe că are defecte arhitecturale ireparabile care au dus la crearea de sisteme noi. În concluzie, cel mai înțelept din partea arhitectului de sisteme este să ia o soluție cât mai nouă, marcată ca și stabilă și utilizată în producție de alte organizații. Totodată, administratorul de sisteme trebuie să își asume resposabilitatea de a contribui la proiectele care au produs programele utilizate prin corectarea sau măcar raportarea erorilor către producători. O altă responsabilitate a administratorului de sisteme este aceea de a proteja datele organizației împotriva pierderii sau deteriorării. (Nu vom vorbi aici despre protecția împotriva furtului, deoarece subiectul articolului este stocarea datelor, nu securitatea lor.) Administratorul trebuie

Objective C

jobs-cluj@yardi.com Yardi Romania

www.todaysoftmag.ro | nr. 26/august, 2014

programare Întreținerea la zi a sistemelor Linux – Partea a II-a să ateste organizației că responsabilitatea este a lui și nu trebuie externalizată altei companii. Orice program are defecte, iar administratorul este cel ce are responsabilitatea pentru aceste defecte. Lustre este folosit în mediile academice și de cercetare unde este nevoie să se prelucreze o cantitate imensă de date folosind supercalculatoare. Sistemul este testat și folosit de supercalculatoarele din top 500 mondial. Administratorii de sisteme de acolo sunt vârful inteligenței în domeniu, iar pe deciziile lor se pot baza administratorii din companii private. În momentul în care am luat decizia de a testa Lustre (2011) am aflat că nu suportă versiuni noi de nucleu de Linux (avea nevoie de un nucleu versiunea 2.6.18, modificat) - care nu era compatibil cu cerințele de drivere și de performanță din compania noastră. În anul următor, Intel a cumpărat Lustre și a promis suport pentru versiunea 3.0 a nucleului, totodată redenumindu-l în Whamcloud. Promisiunea nu s-a materializat, însă varianta dezvoltată de comunitate a Lustre a evoluat, iar în acest an clientul se găsește în nucleul de Linux. Totuși noi aveam nevoie în 2011 de ceva. Următorul pe listă, care oferea cele mai multe facilități, iar arhitectura era rezilientă la catastrofe a fost MooseFS. MooseFS are două probleme: 1. clientul este implementat în afara nucleului Linux, adică este un program ca oricare altul de pe sistem, ceea ce indică o performanță scăzută; din teste însă a rezultat o performanță satisfăcătoare și 2. nu oferea redundanța nodului „master”; această a 2-a problemă putea fi rezolvată de administratorul sistemului. Arhitectura MooseFS permite extinderea sistemului de fișiere pe toate serverele din centrul de calcul. MooseFS creează pe sistemele pe care le folosește o structură de fișiere numită „fișiere de date”, într-un mod asemănător cu baza de date Oracle. În aceste fișiere de date, MooseFS stochează fișierele propriu-zise după un algoritm intern: prima dată împarte fișierele primite de la clienți în bucăți de mărime variabilă de maxim 64MB (chunks), apoi distribuie și clonează aceste bucăți pe mai multe servere (denumite noduri sau chunkservers). Fiecare fișier primit de la clienți spre a fi stocat, are asociat o țintă de multiplicare, denumită „goal”, care reprezintă numărul de copii ale acelui fișier în sistemul de fișiere MooseFS. Copiile sunt stocate pe noduri diferite, astfel că dacă un fișier trebuie să aibă două copii și un nod ce conține

una din copii devine indisponibil, fișierul este încă accesibil pe celălalt nod. Desigur, un fișier poate avea oricâte copii, distribuite pe oricâte noduri, nu doar două. Poziționarea fișierelor este memorată pe nodul „ m a s t e r” a l c ăr u i rol este de a arbitra distribuția și clonarea bucăților de fișier. Master reține informațiile despre fișiere într-un fișier: m e t a d at a . m f s . Î n afară de acest fișier, el creează și niște fișiere de loguri cu toate tranzacțiile ce au avut loc, astfel încât fișierul metadata.mfs poate fi recreat din aceste loguri, dacă se corupe. În afară de logurile locale, pentru a asigura recuperarea fișierelor în cazul dezastrelor ce îl pot afecta, master trimite în fiecare oră o copie a metadata.mfs și a fișierelor de loguri către un alt tip de nod din infrastructura MooseFS: nodul metalogger. Pe acest nod ajunge atât metadata.mfs cât și o copie a logurilor de tranzacții create de master. Oricând un server metalogger poate deveni master, folosind copiile sale locale ale metadata.mfs și logurilor. În arhitectura MooseFS pot exista oricâte noduri chunk, oricâte noduri metalogger, dar doar un nod master. Clienții accesează MooseFS contactând nodul master, care îi redirecționează spre serverele de stocare (chunkservers), unde au loc operațiile de copiere. Deci copierea nu se desfășoară între clienți și master, ci între clienți și serverele de stocare, ceea ce înseamnă că transferurile au loc între toate serverele din centrul de calcul, cu viteză sporită. Din arhitectura MooseFS decurge o aplicație interesantă: Putem avea un sistem de fișiere distribuit, performant și cu reziliență la indisponibilitatea nodurilor folosind toate sistemele din rețea. Aceasta nu se aplică doar la centrul de date, ci și la un birou tipic, unde există sute de stații cu spațiu liber pe discuri, nefolosit. Astfel, angajații din birou vor stoca fișiere „pe rețea” la propriu, nu pe un server dedicat, scump, care poate deveni indisponibil sau plin sau pe care administratorii trebuie să-l îngrijească. Un ochi de administrator versat face imediat observația: dar discurile vor fi

nr. 26/august, 2014 | www.todaysoftmag.ro

umplute? Nu: MooseFS ține cont de gradul de umplere al discurilor pe care le folosește (nu doar în ceea ce-l privește, dar și cu datele pe care sistemul le stochează pe acel disc în afara MooseFS). MooseFS va încerca să egalizeze procentual gradul de utilizare a spațiului de stocare de pe toate discurile disponibile. Deci, datorită faptului că se face un calcul procentual al gradului de umplere, MooseFS nu impune ca toate discurile să aibă aceeași dimensiune. Astfel, de exemplu, toate discurile din nodurile MooseFS vor ajunge în timp la un grad de umplere egal procentual, indiferent de mărime. Dat fiind faptul că fișierele sunt multiplicate pe noduri diferite, la nivel de nod nu avem nevoie de soluții RAID care să duplice conținutul sau să fie ineficiente ca viteză pentru a asigura protecția datelor. Datele sunt protejate prin replicare internod, nu intranod. Gradul de multiplicare poate fi controlat de administrator până la nivelul fiecărui fișier în parte și fără întreruperea funcționării sistemului sau oricărei componente ale sale. Dacă pe MooseFS nu se stochează nimic, atunci spațiul ocupat de MooseFS pe nodurile de stocare este aproape zero. Deci, MooseFS ocupă exact atât spațiu de stocare cât are nevoie și nu are nevoie de partiții separate - folosește un director; administratorul de sisteme nu trebuie să își planifice nimic din timp, ci doar să instaleze și să pornească serviciile de stocare, serviciul master și serviciile de metalogger. Pentru a mări capacitatea de stocare, administratorul poate să adauge oricând, fără să anunțe, noduri noi, sau să extindă capacitatea de stocare a vechilor noduri, oprirea unui nod de stocare neafectând

TODAY SOFTWARE MAGAZINE în nici un fel disponibilitatea sistemului. Singurul punct care prezintă pericol în configurația standard este nodul master, dar la intervenția manuală a administratorului, un nod metalogger poate fi pornit ca master în mai puțin de 10 secunde.

Întrebuințarea sistemului de fișiere de rețea distribuit

MooseFS mai oferă două facilități interesante pentru cei ce rulează mașini virtuale aproape identice: snapshotting și coș de gunoi configurabil. Coșul de gunoi șterge fișierele care ating o anumită limită de timp configurabilă de către administrator ul de sisteme. Deci, coșul de gunoi nu trebuie golit manual și complet, ci fiecare fișier ce ajunge acolo este șters automat după o anumită perioadă. Toate fișierele șterse ajung în coșul de gunoi și nu se poate configura să fie șterse direct. Se poate însă configura coșul de gunoi în așa fel încât să șteargă fișierele după 0 secunde, ceea ce are ca efect ștergerea imediată. Snapshotting-ul este o metodă de a stoca bucățile identice ale mai multor fișiere o singură dată. Aceste fișiere indică spre aceleași date de pe disc, creând iluzia că sunt stocate de mai multe ori. Această metodă mai e cunoscută și ca „deduplicare”. În momentul în care într-unul din aceste fișiere se produce o modificare (se modifică o porțiune de fișier), acea porțiune este stocată separat pentru cele două fișiere. Restul porțiunilor sunt stocate doar o singură dată, spațiul efectiv ocupat de acele două fișiere fiind egal cu mărimea părților comune plus mărimea diferențelor. Metoda de a stoca doar diferențele se numește „copiere în momentul scrierii” (COW - copy on write). Astfel, dacă administratorul are un șablon de mașină virtuală, el poate crea mai multe fișiere imagine ale acelei mașini virtuale pe care să le pornească independent. De exemplu, pentru a scala un webserver supraîncărcat, se pornesc multe mașini virtuale ce folosesc același fișier de disc, iar diferențele apar când fiecare clonă își scrie propriile fișiere de loguri sau alte date pe disc. Comanda mfsmakesnapshot creează aceste tipuri de fișiere.

Momentan, la noi în companie se prelucrează cantități mari de date. Datele vin în formă denormalizată de la diferiți furnizori, periodic. Aceste date sunt atât gratuite, cât și plătite. Odată cu trecerea timpului cantitățile de date ce sunt primite cresc, iar echipa de administrare a fost pusă de mai multe ori în fața problemei epuizării spațiului de stocare. Câteodată, noaptea la ora 2:47. Nu doar datele care vin trebuie stocate. Nevoie de spațiu au și procesele de creare a copiilor de rezervă și procesele de arhivare a datelor prelucrate. Toate acestea cresc în timp. Utilizarea soluțiilor standard RAID pot să scaleze până când se umple suportul de discuri (enclosure). Bineînțeles că există și soluția extinderii cu un nou suport de discuri. Această scalare însă, nu oferă protecție la defectarea nodului la care acel suport de discuri e atașat. De asemenea, „mașinile virtuale” au nevoie de o metodă de a se opri pe un nod și a porni pe alt nod în timp cât mai scurt, fără pierdere de date. Astfel, nu putem face o copie a unei „mașini virtuale” azi și să o pornim, iar apoi mâine să folosim copia de azi pentru a porni „mașina virtuală” pe alt nod, deoarece între timp, mașina și-a modificat starea. În cazul în care „mașina virtuală” este stocată „pe rețea”, putem pur și simplu să o oprim pe un nod și să o pornim pe altul, fără a copia nimic între noduri. Într-un birou, administratorul de sisteme poate rula mașini virtuale pe stațiile colegilor. Acestea sunt stocate pe sistemul de fișiere de rețea și „sar” de pe un calculator pe altul automat, când calculatorul gazdă este oprit. Astfel se pot rula noaptea teste, build-uri, procese de calcul distribuit (grid computing) chiar pe stațiile angajaților, fără a mai fi nevoie de servere scumpe, dedicate. Alegerea unui sistem de fișiere de rețea performant este vitală pentru rezistența sistemelor la dezastre și pentru utilizarea eficientă a resurselor. Ce poate fi mai important decât să știi că TOATE discurile din centrul de calcul sunt umplute la același În partea a III-a voi discuta despre procent și că oricând e nevoie de mai mult LxC, o metodă de virtualizare a sistemelor spațiu se pot adăuga noduri suplimentare, Linux fără pierderi de performanță, care fără întreruperi în funcționarea sistemelor? face posibilă actualizarea controlată fără

întreruperea serviciului.

Disclaimer Schemele provin de pe situl http://www. moosefs.org <http://www.moosefs.org/> și sunt proprietatea autorilor MooseFS.

www.todaysoftmag.ro | nr. 26/august, 2014

programare

Să vorbim despre Swift

ompania Apple este recunoscută prin interesul manifestat în ceea ce privește standardele de înaltă calitate a produselor și serviciilor pe care le oferă. Iată că au reușit din nou acest lucru, odată cu lansarea noului limbaj de programare Swift. Acesta a fost un proiect în lucru pe parcursul ultimilor 4 ani, care chiar dacă a pornit ca un proiect personal al lui Chris Lattner, angajat Apple, a câștigat cu ușurintă încrederea managementului executiv al companiei, fiindu-i oferită o echipă în scopul finalizării lui.

Valentin Filip Valentin.Filip@tss-yonder.com Cluster Manager & Team Lead on Innovation @ Yonder

Pe data de 2 Iunie, Swift a fost făcut cunoscut developerilor, cu promisiunea unei performanțe și eficiențe sporite. Ținând cont de ultimele îmbunătățiri făcute limbajului de programare Objective-C, majoritatea publicului a fost surprins de mișcarea indrăzneață făcută de Apple, cu toate că se pot observa cu ușurință unele similarități dintre sintaxa modernă a Objective-C și elementele prin care Swift dorește să impresioneze. Ceea ce face ca Swift să fie un limbaj mai puternic este faptul că a adoptat toate părțile pozitive ale altor limbaje populare precum managementul automatizat al memoriei, sintaxă de tip script și type inference pentru a crea un mod mai ușor și mai direct de a lucra. Dar cel mai important este că a fost creat pentru programatorul obișnuit, suportând dezvoltarea până și a celor mai simple aplicații.

De ce Swift și nu vechiul Objective-C?

După cum am menționat mai sus, Swift oferă un mare avantaj, acela de a putea fi mult mai ușor de înțeles de către orice programator obișnuit. Deși simplul fapt de a putea fi un programator pentru dispozitivele mobile ale companiei Apple poate reprezenta un motiv suficient, eliminarea barierelor limbajului de programare face

nr. 26/august, 2014 | www.todaysoftmag.ro

ca adoptarea noii platforme să fie sporită. Swift oferă posibilitatea de a scrie cod pentru dispozitive Apple mult mai rapid. De asemenea, folosind “Playgrounds”, orice programator are oportunitatea de a învăța singur să codeze. Pentru programatorul obișnuit cu Objective-C, este necesar un motiv foarte bine întemeiat pentru a adopta schimbarea. Au existat și alte limbaje dezvoltate până acum, dar fără a avea impactul dorit, deși au fost susținute de companii importante precum Google, cu Go. Dar în timp ce până și Paul Jensen, analist independent, afirma că Go nu a creat necesitatea folosirii lui, Swift își face intrarea în scenă cu adevărate îmbunătățiri asupra modului curent de a lucra, acest lucru făcându-l dorit de toți programatorii ce momentan folosesc Objective-C. Swift este totuși destul de similar cu alte limbaje de programare disponibile în acest moment, dar având în vedere că singura alternativă ar fi Obecjtive-C, nenumărați programatori vor alege Swift datorită modului ușor de lucru pe care îl oferă. El vine împreună cu diverse caracteristici precum “inferred typing” prin care nu mai este necesară specificarea tipurilor pentru variabilele folosite, mai ales că în același timp codul este mai sigur, variabila preluând

programare

TODAY SOFTWARE MAGAZINE

tipul primei valori atribuite. Probabil că una dintre cele mai de efect schimbări adoptate de mediul folosit pentru a scrie applicații iOS, Xcode, este integrarea așa numitului “Playgrounds”. Prin acest mod se poate vedea în timp real produsul rezultat scrierii codului, facând mult mai rapidă testarea ideilor și în același timp învățarea de unul singur în mod empiric. “Playgrounds” reprezintă mai mult decât abilitatea de a testa câteva linii de cod. Demonstrează faptul că Swift este uimitor de rapid, având în vedere că face atât compilarea codului, rularea executabilului și afișarea rezultatului, toate acestea întâmplându-se într-un interval de sub 2 secunde, în funcție de mărimea și complexitatea codului, arătând rapiditatea cu care Swift va rula pe dispozitivele folosite. Și totuși oferă mai mult decât atât. Un program funcțional poate fi modificat fără a fi necesară executarea întregului cod. Cu ajutorul Playgrounds se poate integra cod într-o aplicație deja funcțională, având astfel siguranța că este la zi cu implementarea facută.

rezultat să se afle în cadrul ecosistemului, prin achiziționarea și plata cu ajutorul AppStore, înlocuind Web-ul. Comparând Swift cu JavaScript, asemănarea modului de scriere a codului este vizibil similară:

Va dispărea oare Objective-C?

Pentru a exemplifica utilizarea de Swift, în continuare este un exemplu de aplicație pentru calcularea bacșișului.

Partea bună este că Apple nu va elimina suportul pentru vechiul limbaj, iar aplicațiile vor putea avea baza de cod ce conține atât Swift cât și Objective-C. Cu toate că Swift pare mai ușor de folosit și adoptat, modul de scriere al Objective-C oferă totuși mai mult context unui începător în programare. Acest lucru poate fi destul de important în cazul transferului unui proiect. Prin încercarea de a diminua cât de mult cantitatea de cod scrisă, codul rezultat în Swift este unul din ce în ce mai criptat și greu de citit la prima vedere. Astfel că folosirea de comentarii poate deveni în timp o necesitate. Apple a luat în considerare toate situațiile în care mai poate apărea nevoia folosirii de Objective-C, astfel că permite folosirea ambelor limbaje în cadrul aceluiași proiect. Prin acest lucru se oferă oportunitatea programatorului de a folosi o librărie scrisă în Objective-C sau reutilizarea unei bucăți de cod pentru care rescrierea nu este încă o opțiune viabilă.

Nu se rezumă totul doar la performanță și eficiență

După cum a mai fost deja menționat, Swift oferă un avantaj mare asupra altor noi limbaje de programare atunci când se pune în discuție folosirea lui de către programatorii iOS existenți. Oferă perfomanță sporită și ușurință în utilizare. Dar este oare acesta singurul scop al lui Apple? Doar de a îmbunătăți performanța platformei? Din punctul meu de vedere, ar putea fi și o mișcarea îndrăzneață de marketing cu efect pe viitor. Objective-C a fost dintotdeauna considerat a fi greu de învățat și adoptat, mai ales de către programatori cu experiență pe alte tehnologii. Așa au apărut Appcelerator Titanium, Xamarin și altele. Swift ar părea că seamănă cu multe dintre limbajele folosite des în industrie, dar spre deosebire de acestea, oferă migrare rapidă și rezultate cele mai bune în cazul mutării către platforma Apple. Luând ca exemplu programatorii Web, alternativele sunt aplicații web optimizate pentru mobile sau Appcelerator Titanium. La momentul scrierii acestui articol, conform site-ului Appcelerator, există nu mai puțin de 618.722 de programatori ce folosesc platforma. Aș spune că aceștia formează o mulțime impresionantă. Oare Apple nu și-ar dori să utilizeze aceste resurse pentru dezvoltarea propriei lor platforme? Acest lucru ar asigura ca viitoarele aplicații să fie mai stabilie și mai rapide, mai multe componente ar fi create pentru Swift, iar șansele sunt ca venitul

JavaScript: var country = „Argentina” var countries = [„Argentina”, „Brasil”, „Mexic”] Swift: var country = „Argentina” var countries = [„Argentina”, „Brasil”, „Mexic”]

După cum este ușor de observat, sintaxa este similară în aceste exemple, deși, ținând cont de caracteristica “inferred type”, comportamentul variabilelor este puțin diferit. Swift a împrumutat multe trăsături de la alte limbaje de programare, făcându-l să fie un amestec de idei bune. Se pot observa similaritățile cu JavaScript, Python, Java, C#, C, Lisp, Cold Fusion, JSP și altele.

Ghid/Mod de folosire

class Calculator { let total: Double let taxPct: Double let subtotal: Double init(total:Double, taxPct:Double) { self.total = total self.taxPct = taxPct subtotal = total / (taxPct + 1) } func calculate() { println(„10% tip = : \(subtotal * 0.10), for total = \(total)”) } } let tipCalc = TipCalculator(total: 10, taxPct: 0.24) tipCalc.calculate()

Concluzii

Ținând cont de ce anume înlocuiește, Swift oferă o îmbunătățire în a permite scrierea rapidă de cod cu o performanță ridicată. Prin toate avantajele oferite, își va face cu siguranță loc spre inima chiar și a celor mai fideli programatori de Objective-C iar acest lucru se va întămpla cu un ritm mai alert comparativ cu situația altor limbaje. Mai contează oare că este totuși un limbaj specific ecosistemului Apple? Acest lucru depinde doar de scopul fiecăruia. Apple a încetat să mai susțină Java de o vreme, astfel că o uniune cu limbajul de programare ce stă la baza Android-ului nu pare realizabilă în viitorul apropiat. Drept urmare, orice revoluționare a platformei este mai mult decât binevenită și cu siguranță va produce inovații în viitorul apropiat. Există chiar și posibilitatea de a fi open-sourced, așa cum Apple a făcut în cazul Clang și LLVM, oferind tuturor șansa de a contribui la îmbunătățirea lui.

www.todaysoftmag.ro | nr. 26/august, 2014

programare

testare

Limbajul Hack

cest articol e în strânsă legătură cu cel despre maşina virtuală HipHop, publicat în numărul 21 al revistei. Atunci când Mark Zuckerberg a scris primele linii de cod ale Facebook-ului, a fost nevoit să aleagă limbajul de programare în care să dezvolte noua reţea de socializare. A ales PHP-ul pentru că, după cum ştim cu toţii, acesta are un ciclu de dezvoltare foarte rapid: faci o modificare, salvezi fişierul, apeşi F5 în browser şi vezi modificarea instantaneu. Acest lucru e posibil pentru că nu există un pas de compilare pe care programatorul trebuie să-l facă şi pentru că PHP-ul e un limbaj dinamic (nu obligă declararea tipurilor variabilelor). Toate acestea sunt în contrast cu limbajele bazate pe un model static, cum ar fi Java, C#, C++ etc..În aceste cazuri, compilarea e un pas obligatoriu şi, în cazul proiectelor mari, nu unul care să dureze puţin. În schimb, modelul static al acestor limbaje oferă niște avantaje foarte mari: bug-urile se pot detecta extrem de repede şi informaţiile statice despre tipuri oferă un fel de documentare automată a codului. Echipa de ingineri care dezvoltă partea front-end a Facebookului a crescut de la 80 de ingineri în 2008 până la 1000 în 2014. Iar lipsa scalabilităţii unei astfel de echipe, în combinaţie cu faptul că, la Facebook, se introduce cod în producţie de două ori pe zi, are drept consecință foarte mult cod şi foarte mult potenţial pentru probleme. Aşa că echipa de ingineri de la Facebook a decis să împrumute o parte din avantajele celeilalte lumi (cea a limbajelor statice) pentru a reduce o parte din riscurile asociate unei echipe atât de mare de programatori. Din această dorinţă s-a născut limbajul Hack, un limbaj hibrid care face legătura între cele două lumi.

transformare. Da, aşa este: poţi introduce treptat facilităţi ale Hack-ului, după cum îţi pofteşte inima.

Facilităţi

Hack-ul vine cu nişte facilităţi interesante în plus față de ceea ce ceea ce ofera deja PHP-ul. Pentru a vedea detalii şi sintaxa a ceea ce se prezintă mai jos, vedeţi documentaţia oficială a limbajului.

Anotări de tipuri

De departe, aceasta este cea mai importantă facilitate. Permite specificarea tipurilor de date în cadrul parametrilor de funcţii, tipului returnat de o funcţie şi câmpurilor claselor. Tipurile variabilelor din codul propriu-zis nu pot fi declarate; în schimb, sunt “ghicite” de către maşina virtuală. Mulţi programatori specifică aceste informaţii sub formă de comentarii. Hack-ul formalizează această informaţie. Tipurile de date ce se pot specifica sunt în general cele care pot fi specificate şi în cadrul altor limbaje statice: tipuri primitive, şiruri de caractere, nume de clase, “void”, “this” etc. Astfel se oferă avantajul detectării mai rapide a bug-urilor. De Hack-ul în detalii. asemenea, având în vedere existenţa în acest fel a informaţiei statDupă cum menționam mai sus, Hack este un limbaj hibrid ice în plus, compilatorul JIT din cadrul maşinii virtuale va putea care aduce în lumea PHP-ului (un limbaj dinamic) avantajele unui intui mai bine ce căi de execuţie vor fi traversate mai des. Acest model static. Nu este nimic altceva decât o extensie sintactică a aspect demonstrează performanţa crescută. PHP-ului. Hack-ul rulează momentan doar pe maşina virtuală HipHop, Generics de la versiunea 3.0 şi în sus a acesteia. A fost făcut open source în Multe limbaje au această calitate. În Hack, generics-urile vin ca Martie 2014. o întărire şi mai puternică a conceptului de anotări descrisă mai Un aspect important este faptul că, dacă ştii PHP, atunci ştii sus. Implementarea şi sintaxa lor este mai simplă şi mai limitată Hack. decât în cazul limbajelor Java şi C# de exemplu. În schimb, în Hack Există două caracteristici foarte importante ale Hack-ului care se permite folosirea tipurilor de date primitive şi chiar a instanţelor i-a asigurat adopţia în cadrul Facebook-ului şi, poate în viitor, şi de obiecte pentru a specifica tipul de date generic. în cadrul unor aplicaţii terţe: Există totuşi nişte cazuri speciale de care trebuie ţinut cont în a. Interoperabilitatea. Cu extrem de puţine excepţii, dacă ai legătura cu această facilitate. cod PHP înseamnă că ai cod Hack. Acesta arată că, în cadrul aceleiaşi aplicaţii, poţi avea cod PHP care apelează cod Hack Colecţii şi vice-versa. Cele două sunt interoperabile pentru că, la runLa fel cum cele mai multe limbaje statice oferă această time, au aceeaşi reprezentare în memorie: HHBC (HipHop Byte funcţionalitate, aceasta e binevenită şi în Hack. Cele mai imporCode). tante clase din acest framework sunt “Map”, “Vector” şi “Set”, fiecare b. Gradualitate. Limbajul este dezvoltat cu un puternic aspect dintre acestea având un corespondent care oferă imutabilitate. de gradualitate,demonstrându-se că programatorul este liber să Codul PHP obişnuit este de obicei împânzit cu array-uri. decidă care fişiere din aplicaţia sa vor fi transformate în Hack Dacă, în schimb, se vor folosi aceste clase, atunci codul va deveni şi, pe deasupra, cât de puternică şi (in)completă va fi această mai clar şi, în unele cazuri, se vor vedea şi sporuri de performanţă.

nr. 26/august, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Cod asincron PHP-ul nu are suport pentru mai multe fire de execuţie. Însă Hack introduce un foarte primitiv suport pentru această facilitate.

Expresii lambda Acestea sunt similare cu closure-urile deja existente în PHP, însă elimină o parte din limitări şi oferă o mai mare flexibilitate. Sintaxa acestora este asemănătoare cu cea pe care o putem vedea în Java 8.

XHP

codebase foarte mare, acest proces poate să dureze. De exemplu, pentru a transforma codul sursă a Facebook-ului (aproximativ 25 de milioane de linii), a fost nevoie de consumul a 10 GB RAM și un timp de procesare de 12 ore. În majoritatea cazurilor însă, nu ar trebui să depăşească câteva minute. b. Cele care ajută la scrierea de cod Hack cu sugestii în timp real. Este vorba de un typechecker foarte inteligent care rulează ca daemon şi monitorizează constant proiectul în care lucrezi. Atunci când există erori, acestea sunt raportate în timp real în cadrul editorului de text cu ajutorul unor plugin-uri. Momentan există astfel de plugin-uri doar pentru vim, emacs şi Sublime, însă este promisă dezvoltarea pe viitor a unor plugin-uri echivalente pentru majoritatea editoarelor şi IDE-urilor populare.

Aceasta e o extensie opţională a Hack-ului care permite folosirea de blocuri XML/HTML ca pe nişte elemente standard de sintaxă. În acest fel se uşurează foarte mult munca în cadrul codului care conţine logică şi elemente specifice templating-ului. Erorile raportate de typechecker sunt doar legate de anotările Hack oferă şi alte facilităţi minore demne de luat în calcul. De de tip. Timpul de răspuns al acestuia este foarte rapid datorită asemenea, o parte din elementele de sintaxă ale PHP-ului despre monitorizării constante a sistemului de fişiere. care se ştie că sunt ineficient sau rar folosite, sunt dezactivate, Acest typechecker are în schimb o serie de limitări: cum ar fi de exemplu operatorul “@”, operaţiunea “goto”, globalele • cazul de utilizare intenționat pentru acesta e un proiect care (“global $x”) şi multe altele. Prin urmare, acest nou aspect luat în include un autoloader. Va funcționa şi fără, însă nu în mod considerare va forţa programatorul să urmeze bune practici de optim. programare. • toate numele de clase și de funcții trebuie să fie unice în Mai jos puteți vedea o bucată de cod care exemplifică multe din respectivul proiect pentru a obține rezultate corecte. facilitățile prezentate mai sus. Puteți vedea cum sunt specificate • nu suportă declararea condițională a funcțiilor și claselor. anotarile de tipuri, cum e folosită una din clasele din framework• trecerea din cod Hack în cod HTML și înapoi nu este ul colecțiilor, un exemplu de tipuri generice și o expresie lambda suportată având în vedere că nu se mai practică o astfel de simplă: metodologie și se încearcă descurajarea acesteia. class MyExampleClass { public int $number; public CustomClass $myObject; private string $name; private array $stuff; private MyBag<int> $container; function doStuff(MyBag<int> $container, ?bool $x) : string { //immutable Map $map = ImmMap { ‹A› => $container->getA(), ‹B› => $container->getB(), }; if ($map->get(‹A›) == $container->getA()) { //error here because $map is immutable $map->set(‹C›, $container->getC()); } //$x is of type ?bool, which means: //a). it›s of type boolean //b). can also be null if (! is_null($x) && $x) { //lambda expression //and alternative/classic syntax for //accessing map elements $result = $r ==> $r + $map[‹A›] + $map[‹B›]; } else { $result = 0; } //error here because function›s return type is string return $result; } }

Unelte

Maşina virtuală HipHop vine împreună cu niște unelte foarte utile: a. Cele necesare transformării unui codebase PHP într-unul Hack. Acestea sunt relativ simplu de utilizat şi automatizează cea mai mare parte din proces, astfel încât programatorului îi va rămâne o cantitate minimală de muncă. În schimb, pe un

Concluzie

Hack-ul este un suflu nou adus unui limbaj a cărui dezvoltare a cam stagnat în ultimii ani. Hibriditatea dată de adăugarea unui model static peste un limbaj dinamic este un concept interesant pe care cu siguranță îl vom mai vedea în următorii ani. Personal, sunt impresionat de eleganța cu care facilitățile Hack-ului au fost implementate și îmbinate cu sintaxa existentă a PHP-ului. Sunt multe aspecte (în special sintactice) pe care nu le-am atins. Așa că vă invit să le explorați pe cont propriu, cu speranța că acest articol v-a trezit curiozitatea de a face asta.

Radu Murzea

rmurzea@pentalog.fr PHP Developer @ Pentalog

www.todaysoftmag.ro | nr. 26/august, 2014

programare

Clean Code - Naming

acă eşti un programator cu experiență atunci ai auzit de cartea „Clean code” scrisă de Robert C. Martin. În multe companii, această carte a devenit parte din biblia dezvoltatorului. Combinată cu „Clean Coder” (Programatorul Curat), aş spune că aceste două cărţi sunt obligatorii pentru toţi dezvoltatorii. Voi realiza o serie dedicate acestui subiect. Dacă deja aţi citit cartea, atunci este o ocazie bună să vă o reactualizați. Pentru ceilalţi, acesta este momentul perfect pentru a descoperi cât de bine ar trebui să arate codul. Toate ideile principale sunt preluate din „Clean Code” (Cod Curat). Puteţi privi această serie de articole drept un rezumat al cărţii în sine.

Nu ar trebui niciodată să folosim o denumire sofisticată sau care ascunde scopul unei resurse anume. Nu uitaţi că un nume lung nu afectează performanţa aplicaţiei. Da, este adevărat că în anumite limbaje aceasta poate să mărească dimensiunea aplicaţiei, dar în zilele noastre spaţiul nu mai este o problemă – este mai scump să ai o echipă de suport care nu înţelege o parte a aplicaţiei.

De ce?

Evitaţi dezinformarea

Am decis să încep să scriu despre această temă deoarece sunt lucruri care trebuie reamintite şi recapitulate din când în când. „Clean Code” este genul de carte pe care nu o citeşti doar o dată şi apoi o arunci într-un colţ întunecat al camerei tale. Este genul de carte pe care o reciteşti iar şi iar. De fiecare dată vei descoperi lucruri noi pe care le-ai omis sau care sunt revelatoare pentru tine în mai multe feluri.

Denumirea

Acesta este primul subiect pe care îl vom dezbate în acest articol. Un nume bun poate înlocui o documentaţie de o pagină şi poate ajuta un alt dezvoltator să înţeleagă aplicaţia şi să găsească o problemă într-o perioadă mai scurtă de timp. Totul într-o aplicaţie are un nume, de la un field (câmp) banal la numele unei metode sau al unei componente. De aceea este important să dai şi să utilizezi denumiri potrivite. De câte ori v-aţi uitat peste un cod scris cu trei luni în urmă şi nu v-aţi putut aminti ce aţi făcut acolo? De aceea, o denumire bună este de neînlocuit.

Denumirile trebuie să dezvăluie intenţia ta

Un nume bun poate să îţi economisească 10 minute de debugging (depanare) sau 20 de minute de căutare prin documentaţie. Atunci când ne uităm peste un cod, acesta trebuie să se desfășoare în mod coerent. Chiar şi cel mai complex algoritm ar trebui să fie uşor de citit dacă ai o denumire bună. Numele unui câmp, metodă, clasă sau componentă ar trebui să ne spună de ce a fost creat(ă), care este scopul său principal. Mai jos puteţi găsi exemplul clasic care este dat atunci când vorbim despre acest subiect. DateTime d; DateTime dn; DateTime dlr;

Găsirea unui nume bun poate dura ceva timp, dar ne poate economisi timp mai târziu. Deoarece găsirea unor denumiri bune este destul de dificilă, este destul de uşor să recurgi la nume care sunt deja consacrate. De exemplu, utilizarea numelor ca „hp”, „cmd” sau „sco” este dăunătoare. Acestea sunt nume care sunt deja utilizate drept comenzi de către sistemul de operare. Atunci când alegi un nume care este deja utilizat în alt context ar trebui să ai grijă să îl utilizezi în acelaşi context sau cu acelaşi sens. Nu utilizaţi niciodată denumiri consacrate în alte scopuri. carList houseList

Ce observați în exemplele de mai sus? Sufixul „List” ne spune că variabila este o colecţie de maşini sau case. Dacă variabila reprezintă numai o maşină sau o casă, atunci numele induce în eroare. De asemenea, există cazuri în care „List” este utilizat chiar dacă desemnează o mulţime sau alte tipuri de colecţii. Un alt aspect important este denumirea similară a câmpurilor. În exemplele de mai jos avem două câmpuri care sunt diferite numai printr-o singură literă, sau alte două câmpuri care sunt foarte lungi, iar observarea diferenţei este dificilă. cars car optimizelViewConfigurationUsingAVirtualProcess optimizeIViewConfigurationUsingBVirtualProcess

În exemplul legat de „car(s)”, găsirea unei denumiri precum „currentCar” şi „carCollection” ne-ar putea ajuta să înţelegem scopul lor. Evitaţi utilizarea caracterelor care sunt similare, cum ar fi „L” mic (l) şi „I” („i”) mare sau „0” (Zero) şi „O” („o” mare). Este extrem de dificil să observi diferenţa dintre ele. În exemplul de mai sus, cel legat de denumirile lungi, prima literă după „optimize” nu este aceeaşi.

Dacă ne uităm peste aceste definiţii ale câmpurilor sau dacă le Faceţi diferenţe cu înţeles vedem undeva în codul nostru, nu am avea nicio idee despre ceea Într-o aplicaţie, se poate întâmpla să sfârşeşti prin a avea denuce reprezintă aceste câmpuri sau de ce au fost ele utilizate (create). miri similare, chiar dacă ai încercat să faci o diferenţă clară între ele. Din această cauză se poate să scriem un cuvânt greşit sau să DateTime creatingDate; DateTime currentDate; adăugăm numere la finalul unei denumiri. DateTime timeFromLastRun; În exemplul de mai jos avem o metodă care transformă un şir Denumirile de mai sus ne oferă mai multe informaţii despre dintr-un format în altul. câmpurile noastre. Ne este clar care este scopul fiecărui câmp şi ce void Convert(string s1, string s2) fel de informaţii ne oferă.

nr. 26/august, 2014 | www.todaysoftmag.ro

management Numele parametrilor de input (intrare) nu ne ajută să înţelegem logica. Înlocuirea lui „s1” cu „input” sau „inputInXYZFormat” şi „s2” cu „output” sau „converted” sau „outputInABCFormat” ne-ar ajuta mai mult. Când nu avem idei pentru a denumi o clasă, putem sfârşi prin a avea 3 clase cu următoarele nume:

TODAY SOFTWARE MAGAZINE denumiri care sunt standard în zilele noastre. De exemplu, atunci când vedem un „i” sau „j”, ştim din primul moment că vorbim despre o iterare.

Denumirea Claselor şi a Metodelor

Există două reguli simple care ne pot ajuta mult atunci când trebuie să găsim un nume bun pentru clasa noastră sau pentru Car CarData metode: CarInfo • Un nume de clasă ar trebui să conţină un substantiv sau o Problema cu această denumire este că nu există o diferenţă expresie substantivală. clară între „Data” şi „Info”. Cititorul nu va şti ce fel de informaţie • Un nume de metodă ar trebui să conţină un verb sau o conţine fiecare clasă. expresie verbală. Utilizarea sufixelor sau a prefixelor care reprezintă tipul câmpului nu ne ajută să facem un cod mai lizibil. Care este diferenţa Încercaţi să evitaţi denumirea claselor cu prefixe sau sufixe dintre „Name” şi „StringName” sau „NameString”? Nu este nicio precum „Service”, „Factory”, „Processor”, „Data”, „Info”. Aceste diferenţă în final. Un nume precum „CarName” ar fi mai util. denumiri de clase sunt întrebuinţate prea mult (mai ales când nu Acelaşi lucru este valabil şi pentru denumirea metodei, a propri- găsim denumiri mai bune). etăţilor sau a clasei.

Utilizaţi nume uşor de pronunţat

Alegeţi un cuvânt per concept

Chiar dacă codul este scris pentru maşini (010101001), este destul de sigur că vei ajunge în timpul depanării sau a reutilizării să vorbeşti cu altă persoană despre acel cod. Ar suna destul de stupid să denumeşti un câmp într-un fel pe care nu îl poţi citi sau să foloseşti o denumire care este codată.

Un concept din sistemul tău ar trebui să aibă aceeaşi denumire. Fii consecvent în această privinţă. Nu vrei să ai două nume pentru o clasă care exprimă acelaşi concept. De exemplu „Processor” şi „Analyzer” sau „Controller” şi „Manager”. Utilizarea aceluiaşi cuvânt per concept îi va ajuta pe dezvoltatori să înţeleagă codul mai uşor.

‘carN4RegS1’ – ‘carNumberForRegistrationSection1’ ‘dtoCRcrd100’ – ‘car’

Utilizaţi denumiri din numele domeniu Soluţie şi Problemă

Folosiţi nume care pot fi căutate

Nu folosiţi denumiri care sunt din afara contextului şi nu sunt din acel domeniu specific. Este mai natural pentru cineva care lucrează în industria auto să folosească cuvântul „motor” şi nu „sursă de putere”. Ar trebui să utilizaţi denumirile specifice ale domeniului şi nu alte denumiri date de dezvoltatori, care pot fi greşite. Aceasta poate fi o cauză de neînţelegere între clienţi şi dezvoltatori.

Sună ciudat? Nu. Tu ai nevoie să cauţi în cod pentru a vedea diferitele câmpuri utilizate. Da, este adevărat că noile IDE pot face treaba asta pentru noi, dar totuşi trebuie să folosim denumiri care pot fi căutate uşor. De exemplu, cât de uşor este să găseşti unde a fost utilizat „i” sau „j”? Acelaşi lucru se întâmplă cu cuvintele magice care sunt folosite în linie, fără a le extrage drept constante. De exemplu, căutarea şi înlocuirea unei valori numerice într-o Nu adăugaţi context nejustificat aplicaţie poate fi un coşmar dacă aceeaşi valoare a fost utilizată în Este destul de uşor să adaugi context lucrurilor care sunt deja linie pentru cazuri de utilizare diferite. clare. De exemplu, într-o clasă denumită „Car”, nu este nevoie să numeşti câmpul culoare al clasei „carColor” sau „colorCar”. Eşti Evitaţi codificarea deja în clasa maşină şi toate informaţiile din această clasă sunt Nu încerca să reinventezi roata şi să-ţi defineşti propria legate de „Car (Maşină)”. codificare pentru lucruri care au fost deja definite şi standardizate. Ultimul lucru pe care doreşti să îl ai este propriul tău limbaj Concluzie personalizat. Găsirea denumirilor bune într-o aplicaţie poate fi o treabă difiDe aceea, încearcă să foloseşti prefixe precum „I” pentru inter- cilă şi care necesită mult timp. Nu este simplu să găseşti denumiri feţe sau sufixul „Base” pentru clase abstracte. Nu folosi prefixul bune. Dar ar trebui să investiţi timp pentru a găsi şi utiliza denu„C” pentru implementarea claselor sau „m_” pentru variabile. miri potrivite. Dacă sfârşeşti prin a avea o codare personalizată, fă un pas înapoi şi încearcă să vezi de ce ai ajuns în situaţia asta. În funcţie Cuvinte de încheiere de acest răspuns, ar trebui să iei o hotărâre. Diferenţa dintre un programator deştept şi unul profesionist este că profesionistul înţelege importanţa clarităţii. Profesioniştii Evitaţi hărţile mintale îşi folosesc abilităţile pentru a scrie cod care poate fi înţeles de Să începem cu un exemplu: r t p către alţii. Chiar dacă suntem dezvoltatori, nu dorim să învăţăm şi să memorăm că „r” înseamnă întregul url al Dacia server din Radu Vunvulea Radu.Vunvulea@iquestgroup.com România, „t” este acelaşi url, dar fără informaţia protocol şi „p” reprezintă parametrii de interogare pe care trebuie să îi trimitem Senior Software Engineer @iQuest la server pentru a putea să ne logăm. Chiar dacă hărţile mintale nu sunt benefice, există câteva www.todaysoftmag.ro | nr. 26/august, 2014

programare

TYPO3 Neos - Schimbând ecosistemul sistemelor de administrare a conţinutului

ajoritatea sistemelor de administrare a conţinutului deconectează editorul unei pagini web de designul / layout-ul paginii web. Editorii adaugă, editează sau șterg conținut “orbește” sau trebuie frecvent să schimbe între panoul de administrare a paginii web și pagina web în sine, întregul proces devenind o comparație constantă între date de intrare și date de ieşire.

Această modalitate de lucru duce de multe ori la frustrare și produce o barieră în fața creativității editorului, atât pentru conținut, cât și pentru aranjarea informaţiilor.

Pasărea Phoenix

Unul dintre giganţii sistemelor de management de conţinut este proiectul open source TYPO3 CMS. Lăudat ca un sistem de management pentru proiecte complexe și întreprinderi de dimensiuni mari, complexitatea și uşurinţa de extindere sunt punctele forte, însă regăsim aceeaşi problemă în modalitatea de lucru cu conţinutul. În octombrie 2008, echipa de dezvoltare TYPO3 s-a întrunit la Berlin. Principalul scop al acestei întruniri a fost planificarea dezvoltării TYPO3, atât versiunea 4 de atunci, cât și viitoarea versiune 5. Tot aici, echipa a clarificat viitorul celor două versiuni, atât pentru agențiile web, cât și pentru dezvoltatorii web care folosesc TYPO3 în proiectele lor. Aceștia au compus următorul manifest: Noi, participanții la conferința TYPO3 Developer Days 2008 afirmăm: • TYPO3 v4 va fi dezvoltată în continuare activ. • Dezvoltarea versiunii 4 va continua și după lansarea versiunii 5. • TYPO3 versiunea 5 va fi succesorul versiunii 4. • Migrarea conţinutului de la versiunea 4 la 5 se va face foarte uşor. • Versiunea 5 va introduce o mulţime de noi concepte și idei. Procesul de învăţare nu se opreşte niciodată și vom ajuta la o migrare cât mai ușoară.

înaintea utilizatorilor paginii web. 5. Pregătit de schimbare: interfața trebuie să fie adaptabilă la oricare reorganizare a conținutului. TYPO3 Neos e mult mai mult decât un paradis pentru editori. Unul dintre caracteristicile mult asteptate este content dimensions. Conceptul de content dimensions este de fapt conținut cu mai multe variante - o soluție flexibilă la localizarea conținutului pe mai multe dimensiuni. De exemplu, conținutul ar putea fi localizat nu doar per limbă, ci am putea avea un element de conţinut care se schimbă în funcție de vârsta utilizatorului sau originea sa.

Arhitectura TYPO3 Neos

În centrul arhitecturii TYPO3 Neos se află nodul. Aproape orice în TYPO3 Neos este reprezentat prin noduri, entitatea de nod fiind extinsă pentru a putea îndeplini cerinţele altor entităţi. Pentru ca totul să funcționeze armonios, avem următoarele componente:

Componente backend din panoul de adminstrare

Însă în decembrie 2013, TYPO3 versiunea 5 (cunoscută cu numele de cod „Phoenix”) a fost lansată sub numele de TYPO3 Neos, completând familia de produse TYPO3, în loc să fie un succesor la TYPO3 versiunea 4. TYPO3 v4 a continuat să fie dezvoltat până astăzi la versiunea 6.x.

Soluția: TYPO3 Neos

TYPO3 Neos este un sistem de adminstrare de conținut al viitorului, produs de comunitatea TYPO3. Ceea ce face ca Neos să iese în evidență față de celelalte sisteme de administrare de conținut este atenţia la detalii în tot ce înseamnă UIX pentru editori. TYPO3 Neos dispune de cinci principii de UIX: 1. Creează limite: separă clar diferitele tipuri de componente pentru a facilita navigarea cu ușurință a editorului. 2. Thinking is King: gândirea este cea care determină experienţa web pentru editori și nu sistemul de administrare în sine. 3. Capacitate distribuită: furnizarea de caracteristici puternice doar atunci când este necesar. 4. Simulare înainte de publicare: a experimenta conţinutul

nr. 26/august, 2014 | www.todaysoftmag.ro

Fluid - Motor de templating modern cu suport pentru Namespaces, Variables / Object Accessors, View Helpers și Arrays. TYPO3CR - Content Repository ( JCR / Sling) TypoScript - pe scurt, ca un vector PHP multi dimensional, însă în TYPO3 Neos avem parte de TypoScript 2.0 care suportă orientarea pe obiect. Forms - Form API & Form Builder (via Flow Forms API) Expose - Interfață de administrare extensibilă Eel - Embedded Expression Language FlowQuery - O modalitate de procesare a conținului (reprezentat ca un nod TYPO3CR) în contextul Eel. Operațiile FlowQuery sunt implementate în clase PHP. Pentru orice operație

arhitectură

TODAY SOFTWARE MAGAZINE

FlowQuery, trebuie să existe un pachet instalat care implemen- TYPO3 Neos Panou de admistrare tează acea operație. Oricare pachet poate să adauge propriile Asigură o editare simplă a conținului, on the fly: operații FlowQuery. Un set de bază de operații este disponbil tot • Operații simple (eg. Aloha editor), timpul fiind parte din pachetul TYPO3.Eel. • Perioadă scurtă de învățare, • Nu e necesară o sesiune de training pentru editorii noi, Componente frontend din panoul de adminstrare • Folosire intuitivă.

Editorii nu trebuie să treacă prin sesiuni lungi de training pentru a edita conținutul în TYPO3 Neos. Trebuie doar să dea click pe obiectele pe care doresc să le editeze. Iar aceasta nu e singura modalitate de editare a conținului. EmberJS - JavaScript Web Application Framework Se poate opta între folosirea In-Place editing, după cum îi Create.js - Web Editing Interface spune și numele, editare direct în design sau Raw content editing Aloha / Hallo - HTML5 WYSIWYG Editor care înlătură toate elementele de design și permite editorului să se VIE = viejs.org - Semantic Interaction Framework axeze exclusiv pe conținut. RequireJS - JavaScript file and module loader Modulul Raw Content permite de asemenea refolosirea conținutului în mai multe canale de distribuție a conținutului fără Instalare a ține cont de template-ul folosit. În schimb, editorii se pot concentra astfel pe cuvintele folosite și ce formate media vor fi folosite. Cerințe sistem Modulul Preview Central este locul unde se poate simula • server web (Apache sau nginx, IIS și altele, însă netestate pagina web în timp real cu conținut proaspăt adăugat înainte ca încă) acesta să fie disponibil pentru publicul larg. Aici editorii pot con• minim PHP 5.3.2 sulta, spre exemplu, trei formate diferite de prezentare a paginii • modulele PHP mbstring, tokenizer și pdo_mysql activate, web - desktop, mobile, tabletă, etc. sau simulări personalizate, de magic_quotes_gpc = off exemplu cum ar arată o pagină indexată în Google Index. • funcțiile PHP system(), shell_exec(), escapeshellcmd() și escapeshellarg() să fie active Concluzie • o bază de date care suportă Doctrine DBAL TYPO3 Neos este deocamdată un produs tânăr și nou pe piața • virtual hosts pentru dezvoltarea locală: sistemelor de administrare de conținut. Chiar dacă constatăm că îi lipsesc câteva caracteristice importante precum traducerea de NameVirtualHost *:80 <VirtualHost *:80> conținut, suport pentru mai multe domenii web sau o documentaDocumentRoot „/your/htdocs/TYPO3-Neos-1.1/Web/” ţie completă pentru dezvoltatorii web, acesta are un potențial uriaș SetEnv FLOW_CONTEXT Production ServerName neos.demo și, mai ales clienții par să fie îndrăgostiți la prima vedere de el. </VirtualHost> Însă versiunea 1.2 promite să acopere majoritatea problemelor. Instalare din arhivă Introducerea completă a content dimensions va fi face din TYPO3 1. Descarcă arhivă via http://neos.typo3.org/download.html Neos primul sistem de administrare de conținut unic în ceea ce 2. Extrage arhiva în folderului web dorit. privește administrarea de conținut cu dimensiuni multiple. 3. Continuă cu Setup, accesând www.domain.local/setup TYPO3 Neos este momentan folosit într-o varietate mare de 4. Urmează instrucţiunile. proiecte datorită timpului mic de acomodare e editorilor și a versatilităţi extraordinare arhitecturii care se mulează pe orice tip de Instalare cu Composer proiect, domeniu! Mai multe detalii: http://neos.typo3.org 1. Instalare composer (dacă lipsește): curl -s https://getcomposer. org/installer | php 2. Rulează comanda în folderu de instalare: php /path/to/comTomiță Militaru tmilitaru@arxia.com poser.phar create-project --no-dev typo3/neos-base-distribution TYPO3-Neos-1.1 Senior Web Developer @ Arxia 3. Continuă cu Setup, accesând www.domain.local/setup 4. Urmează instrucţiunile.

www.todaysoftmag.ro | nr. 26/august, 2014

programare

Provocări în promovarea internă

n 2005, gigantul Daimler-Chrysler anunța concedierea CEO-ului Juergen Schrempp, arhitectul fuziunii Daimler-Chrysler, care a preluat conducerea companiei imediat după fuziune. Schrempp și-a început cariera la Daimler, subsidiară a Mercedes-Benz în 1967 ca inginer și a avansat până la poziția de CEO. După fuziune, Schrempp care și-a ignorat partenerii Crysler din SUA și operațiunile lor de marketing, a fost martorul declinului noii afaceri. În primul an, afacerea a pierdut peste 50% din valoarea capitalului. Datorită acestei colaborări defectuoase, board-ul a hotărât concedierea lui Juergen Schrempp după o carieră de 38 de ani în aceeași companie. Acest exemplu indică prezența unor erori în promovarea internă care puteau fi evitate, dacă înainte de promovare se luau în considerare toate aspectele critice ale unei promovări interne. La prima vedere am spune că nu se poate compara o promovare clasică cu una pentru pozițiile de CEO, dar pentru orice nivel, înainte de a lua o decizie care implică soarta unei echipe sau a unei întregi companii, trebuie să verificăm în detaliu potrivirea persoanei cu noua poziție. În funcție de etapa de dezvoltare în care se află sau nevoia de talente pe care o au, companiile mari, aflate la maturitate, favorizează o dezvoltare a angajaților care în timp să fie capabili să ocupe pozițiile vacante. În cealaltă tabără, companiile în creștere accelerată și inovative tind să se concentreze mai mult pe atragerea candidaților externi, inclusiv pentru pozițiile cu abilități rare. Aproape toate companiile recurg în cele din urmă la o strategie mixtă, combinând cele două surse în funcție de nevoi. În contextul dificultății retenției angajaților talentați, atenția companiilor trebuie să se îndrepte către descurajarea acestor angajați de a părăsi compania și dezvoltarea acestora în viitori lideri. În sine, fiecare companie trebuie să aibă o strategie, un plan de succesiune, să asigure dezvoltare continuă, pe scurt să formeze lideri pregătiți să dezvolte compania. Studiile recente realizate de profesorul Matthew Bidwell, profesor de management la facultatea Wharton, referitoare la succesiunea pentru pozițiile de CEO, au demonstrat că liderii seniori angajați din exterior costă semnificativ mai mult, aceștia fiind plătiți cu mai mult decât un CEO ,,crescut,, în interior. Totodată, o persoană adusă din exterior se adaptează mai greu poziției, demonstrând eficiență mai redusă. De asemenea, un studiu realizat de compania de consultanță în management global, Booz and Co. arată că 35% dintre cei angajați pe pozițiile de CEO atrași din exterior au fost concediați, în comparație cu 19% dintre cei dezvoltați intern.

nr. 26/august, 2014 | www.todaysoftmag.ro

Fie că vorbim de poziții de specialiști sau de top management, de recrutarea din surse interne sau externe, întotdeauna vor exista provocări, de la implementarea unui proces de evaluare corect și până la luarea deciziei corecte. Companiile care aleg promovarea internă se concentrează pe crearea unei culturi și a unui brand puternic al organizației. Printre avantajele promovării interne se numără: 1. Nivelul de performanță al unei persoane obișnuite cu mediul organizației va fi mai mare decât al unui candidat adus din exterior; 2. Candidații interni cunosc regulile și modul în care acționează compania, astfel se reduce perioada de induction; 3. Se reduc costurile privind anunțul, căutarea și selectarea candidatului; 4. Promovările interne construiesc o cultură organizațională puternică, în care angajații au încredere. 5. Permițând angajaților să se deplaseze pe verticală și pe orizontală în cadrul organizației se reduce posibilitatea ca ei să își caute un alt loc de muncă. În ciuda numeroaselor avantaje, promovarea internă are și puncte slabe care pot să ducă la eșec. Pentru a evita erorile care pot decurge dintr-o promovare greșită, trebuie să avem în vedere următoarele aspecte: 1. Dacă la început, se oferă candidaților interni un avantaj de excusivitate și nu există un candidat potrivit poziției, procesul de recrutare va fi prelungit inutil. 2. Companiile care permit managerilor să aibă drept de veto în decizia de agajare și nu se bazează pe evaluări propriu-zise, pot cauza erori și afecta pe ceilalți candidați. 3. Promovările interne care nu sunt bazate pe un proces riguros care să includă evaluări psihometrice și centre de evaluare pot provoca frustrări în interiorul unei echipe.

programare 4. Candidații interni ai companiei nu au CV-urile actualizate și abilitățile lor de interviu nu sunt exersate, astfel apare riscul ca un candidat intern să pară mai puțin potrivit decât unul extern. 5. Se întâmplă ca cei proaspăt promovați să simtă nevoia de a-și elimina concurența pentru a-și solidifica poziția. 6. Pentru companiile cu locații multiple, costurile de relocare pot fi foarte costisitoare, de aceea angajarea din surse externe poate reprezenta o alegere mai bună. 7. Când contractele și experiența în arii noi pentru companie sunt cerute, promovarea internă nu este de calitate și nu se justifică. 8. Multe sisteme de promovare internă sunt bazate pe senioritate, care de multe ori nu produce calitate în contextul schimbării rapide a oricărei industrii. 9. O promovare internă poate cauza un val al promovărilor, deoarece în urma unei promovări apare o nouă poziție vacantă și astfel, ciclul se perpetuează la nesfârșit. Acest fapt poate destabiliza performanța companiei datorită faptului că sunt prea multe persoane noi care au prea multe de învățat. 10. Sunt situații în care cei nepromovați îl vor sabota pe cel promovat. 11. Promovările interne pot ajunge la nivelul de performanță dorit doar atunci când există un program de instruire și dezvoltare foarte bun. Costurile unor astfel de programe interne de dezvoltare pot fi mai ridicate decât talentele pregătite din exterior. 12. Companiile mici care cresc rapid nu au suficient personal pentru a promova din interior. 13. Promovarea celui mai experimentat sau cu cele mai multe abilități, nu înseamnă reușita acestuia. Abilitățile necesare unui jucător valoros sunt diferite de cele ale unui bun coach. Multe companii sunt mai susceptibile în a-i retrograda pe cei seniori decât să îi concedieze. 14. Puține sisteme de succesiune măsoară sau evaluează exact eficiența și abilitățile. 15. Majoritatea evaluărilor psihometrice nu sunt adecvate la mediul de business, astfel devenind complet ineficiente. Mai devreme sau mai târziu, orice companie va înfrunta provocări în promovarea internă, pentru a crea un sistem sănătos care ne scutește de dificultăți, înainte de a promova angajații, companiile trebuie să își îmbunătățească procesul de recrutare și cel de onboarding. Dacă vorbim de poziții de management și unele companii încă se bazează doar pe interviu și pe referințele aduse de candidați, sunt expuși la o recrutare greșită. Liderii seniori dețin arta interviurilor memorabile. Aceștia au o experiența vastă în prezentări, vânzări și sunt persuasivi. Rețeta pentru evitarea unor astfel de erori sunt centrele de evaluare și evaluările psihometrice care furnizează un contur mai comprehensiv și un profil al potrivirii candidatului cu un anumit rol, cultură sau industrie. Noii angajați care nu se pot ridica așteptărilor reprezintă de multe ori o dificultate pentru unele companii. Asta se datorează faptului că majoritatea nu au trecut printr-un proces sănătos de onboarding. Promovările interne sunt de regulă rodul unor activități bidirecționale. Pe de-o parte, angajatul demonstrează abilitățile și potențialul potrivit poziției și pe de altă parte compania dezvoltă potențialul pentru a crea un lider de succes care să fie temelia unei echipe, a unui departament sau poate chiar a întregii companii.

TODAY SOFTWARE MAGAZINE Așadar, atunci când avem o poziție liberă este bine să punem în balanță promovarea internă sau recrutarea unui candidat extern. Iar în momentul în care am ales varianta promovării interne este bine să includem criterii clare de selecție și să nu ezităm să apelăm la specialiști pentru centre de evaluare și teste psihometrice.

Monica Soare

monica.soare@artwinconsulting.ro Manager @ Artwin

www.todaysoftmag.ro | nr. 26/august, 2014

management

programare

Cadrul analizei de business (I)

maginaţi-vă că sunteţi un entuziast analist de business alocat pe un proiect nou şi nu ştiţi de care capăt să apucaţi. Nu cunoaşteţi domeniul, nici oamenii din echipa de dezvoltare şi nici măcar aşteptările părţilor implicate. Fred Brooks scria în cartea sa „No Silver Bullet” următoarele: ,,Cea mai grea parte în construirea unui sistem este aceea de a decide exact ce vrei să construieşti. Nicio altă parte a lucrării conceptuale nu este aşa de dificilă ca şi cea a stabilirii de cerinţe detaliate…Nicio altă parte nu este mai dificil de rectificat mai târziu”. Pentru că subiectul mă pasionează şi că am identificat o preocupare pentru acesta și din partea mai multor analiști de business, intenția este de a dedica mai multe articole acestui subiect. Acest articol va fi doar o introducere în temă pentru o serie de mai multe articole. Definiție: Cadrul analizei de business este o structură reală şi/ sau conceptuală care include folosirea unui ansamblu de cunostinţe, tehnici practice şi concepte demonstrate, cu scopul de a descoperi rapid, de a analiza critic şi de a capta cu precizie cerinţele de business. Un astfel de ansamblu e prezentat în Figura 1:

De la ce a pornit nevoia unui cadru al analizei de business?

Experienţa recentă m-a învăţat că odată ce mi-am însuşit anumite metode şi metodologii de lucru, nu trebuie să mă opresc aici, ci să continui să îmi dezvolt bagajul de cunoştinţe şi să identific cu precizie situaţiile în care trebuie aplicate fiecare în parte. Îmi dau seama că domeniul analizei de business este foarte variat, modul de lucru, activitățile şi aşteptările variind de la o companie la alta. Prin urmare, odată cu prezentarea cadrului de analiză de business creat de mine, vă invit şi pe voi să vă gândiţi cum ar arăta propriu cadru de analiză. Consider că doar în acest mod, ne vom putea adapta mereu la schimbările frecvente care apar. În cazul meu, schimbarea majoră a fost trecerea de la un proiect mic intern cu totul nou, unde am elaborat un document conţinând cerinţele de business (Business Requirements Document), către un proiect foarte mare pentru o corporaţie, în care sunt implicaţi mai mulţi stakeholder-i. Acum ştiu că în primă fază, definirea unui cadru poate părea un pic dificil pentru un analist de business la început de drum, de aceea e necesară o ordonare clară a lucrurilor şi o vizualizare a paşilor ce trebuie parcurşi, ca şi în Figura 2.

Figura. 1. Cadrul analizei de business Figura 2. Paşi de parcurs

Avansând în domeniul analizei de business și acumulând experiență pe câteva proiecte, consider că analistul de business treÎn paralel şi/sau adiacent cu parcurgerea acestor paşi, se vor buie să îşi poată defini cadrul specific pe proiectul pe care lucrează, alătura şi elementele ce alcătuiesc cadrul de analiză, pe care le voi fie el mic sau mare, waterfall sau agile. descrie în linii mari în cele ce urmează.

nr. 26/august, 2014 | www.todaysoftmag.ro

TODAY SOFTWARE MAGAZINE Elementele din cadrul analizei de business

Planul de dezvoltare al proiectului

În cazul meu, planul de dezvoltare folosit este cel în acord cu PMI: iniţializare proiect, planificare, execuţie, monitorizare şi conCele 4 activităţi importante care se regăsesc în majoritatea pro- trol, finalizare: iectelor sunt prezentate în imaginea de mai jos:

Activităţile de BA

Tehnicile folosite La nivel general, tehnicile de captare a cerinţelor pe care le folosesc sunt: • Brainstorming, • Interviuri, • Observare , • Shadowing, • Workshop-uri, • Prototipuri, • Modelare vizuală.

Setul de documente scrise Acestea se folosesc în timpul activităţilor de analiză de business şi sunt necesare în sprijinirea dezvoltării, precum şi în livrarea rezultatelor. Setul de documente şablon (template documents) pe care doresc să îl folosesc pe proiectul meu conţine: • Matricea de implicare a părţilor interesate (Stakeholder Involvement Matrix), • Analiza lacunelor (Gap analysis), • Specificaţiile cerinţelor de business (Business Requirements Specifications), • Planul de management al cerinţelor (Requirements Management Plan), • Specificaţii de use case-uri (Use Case Specifications), • Planul de comunicare (Communication Plan).

Bineînţeles, sunt mai multe elemente care pot fi folosite în crearea unui cadru de analiză personalizat. Fiecare analist e liber să decidă ce se poate aplica cu succes pe proiectul său. În încheiere doresc să evidenţiez obiectivul principal pe care toţi vrem să îl atingem, şi anume, faptul că ne dorim cu toţii un client mulţumit. Pentru aceasta e necesară folosirea unui cadru de analiză de business bine definit. Acest lucru va face ca nevoile şi cerinţele clientului să poată fi comunicate şi înţelese în aceeaşi măsură de toate părţile interesate astfel încât, la final, clientul să fie pe deplin mulţumit de soluţia livrată. După cum am menţionat la începutul acestui articol, subiectul este foarte vast şi va fi detaliat în următoarele ediţii ale revistei. Dacă aveţi idei, propuneri sau deja aveți un cadru de analiză pe care îl folosiţi cu succes puteţi să îmi scrieţi despre el la adresa ioanaa@imprezzio.com.

Modelare vizuală cerinţelor Folosesc cu succes următoarele: • Diagrame de Use Case-uri (Use Case Diagram), • Diagrame de activităţi (Activity Diagram), • Diagrame de clasă (Class Diagrams), • Diagrame de mod lucru (Work Flow Diagram), • Diagrame de process (Process Flow Diagram), • Prototipuri, • Mind maps, • Entity Relationship Diagrams (ERD), • User Interface Diagram.

Ioana Armean

ioanaa@imprezzio.com Business Analyst @ Imprezzio Global

www.todaysoftmag.ro | nr. 26/august, 2014

programare

Securizarea Codului Opensource (III)

n numerele anterioare 24 și 25, s-au publicat primele două părți ale acestui articol. Acest număr prezintă ultima parte a acestuia. După cum am menționat în părțile anterioare ( vezi Figura 1), codul opensource încorporat în software-ul comercial nu este de obicei supus la aceeași analiză statică riguroasă și revizuire ca și codul patentat nou dezvoltat. Raghudeep Kannavara

raghudeep.kannavara@intel.com Security Researcher, Software and Services Group @Intel USA

nr. 26/august, 2014 | www.todaysoftmag.ro

În fluxul alternativ de lucru pe care îl propunem, după cum vom vedea în Figura 9, noi recomandăm includerea rezultatului instrumentului SCA atât pentru softwareul nou dezvoltat cât și pentru software-ul opensource adoptat în pachetul de revizuire formală software. Acest flux de lucru va supune codul opensource unei analize de cod și unui proces de revizuire detaliat împreună cu codul patentat nou dezvoltat. Orice eroare (bug) descoperită prin analiza statică este reparată și în codul opensource și în codul nou dezvoltat, înainte ca acesta să fie supus analizei dinamice și cu mult înainte să fie lansat pe piață. Bineînțeles, acceptarea termenilor licenței codului opensource adoptat este la fel de importantă și poate pretinde comunicarea reparațiilor sau modificării codului către responsabilii cu întreținerea, înainte ca software-ul să fie expediat. Acest proces s-ar putea să nu găsească toate erorile

, dar cu siguranță va ajuta la descoperirea timpurie a anumitor erori, oferind astfel șansa de a le îndrepta mai devreme, după cum s-a demonstrat în secțiunea anterioară despre analiza vulnerabilității. Mai mult, considerați scenariul realizării unui upgrade al componentelor open source care au fost încorporate. Adoptarea fluxului de lucru propus va fi și mai utilă într-un astfel de scenariu: • Pentru a te ajuta să decizi dacă un upgrade al unui component este fezabil, prin bilanțul erorilor care sunt îndreptate și erorilor nou introduse. Uneori, efortul suplimentar necesar îndreptării erorilor nou introduse în versiunea de software upgradat poate fi un factor decisiv pentru lansarea produsului. • Pentru estimarea muncii potențiale de portare prin înțelegerea relației dintre componentele open source și componentele proprii.

TODAY SOFTWARE MAGAZINE

Figura 9. Segment al procesului de dezvoltare software alternativ propus, care încorporează analiza statică în timpul integrării codului opensource (2)

Provocări în adoptarea fluxului de lucru propus

Chiar dacă analiza statică a codului opensource adoptat este folositoare în identificarea timpurie a anumitor erori (bugs) în software, există provocări tehnice și orientate pe proiect care ar putea să facă această propunere să nu fie viabilă în anumite situații, după cum vom discuta în continuare. • Instrumentele SCA tind să producă un număr mare de alarme false (false positives). Revizuirea și eliminarea alarmelor false poate fi o sarcină descurajatoare pentru ambele echipe, de dezvoltare și de asigurare a calității, în special atunci când proiectele sunt supuse unor constrângeri serioase legate de resurse, timp și buget. Odată ce alarmele false sunt eliminate, este necesară comunicarea problemelor reale către echipele de dezvoltare, spre a fi corectate. Uneori, aceasta poate necesita ca îndreptările să fie comunicate echipei de mentenanță a software-ului opensource, înainte de livrarea produsului, în baza termenilor licenței pentru software-ul opensource. • Evaluarea gravității pentru problemele semnalate de Klocwork sunt ilustrate în Figura 10. Klocwork suportă 10 nivele de gravitate, cu 1 (Critic) fiind cel mai ridicat și 10 (Info) fiind cel mai scăzut. În mod similar, alte instrumente SCA vor avea propria lor clasificare a problemelor. Datorită numărului mare de alarme false, tendința de a ignora problemele semnalate drept non-critice de către instrumentele SCA poate face ca probleme reale să fie ignorate. De aceea, revizuirea sârguincioasă a problemelor înainte de a le ignora, chiar dacă este o sarcină descurajatoare, poate de fapt să merite efortul. • Efectuarea cu conștiinciozitate a SCA și revizuirea rezultatelor SCA pentru întregul cod, opensource sau nou dezvoltat, necesită devotament și resurse pregătite dedicate, care pot să nu fie disponibile în proiecte care duc deja lipsă de personal sau unde volumul de lucru este prea mare și sunt necesare ore suplimentare.

Figura 10. Evaluarea gravității Klocwork

Chiar dacă este recomandată SCA pentru codul opensource adoptat, cât și pentru codul nou dezvoltat, provocările menționate anterior necesită compromisuri datorate limitărilor de buget, timp și resurse, care pot părea necesare, dar sunt probabil riscante. Câteva moduri de abordare a compromisurilor sunt următoarele: • Un mod ar fi să te concentrezi pe componentele de complexitate mai mare din codul opensource adoptat și să revizuiești rezultatele SCA pentru aceste componente de complexitate ridicată, ceea ce poate economisi timp și resurse prin îngustarea ariei de verificat. Aceasta se bazează pe analiza noastră, după cum am explicat în secțiunea anterioară, despre analiza complexității – componentele de complexitate mai mare tind să prezinte o incidență crescută de erori raportate. Cu toate acestea, aplicarea analizei statice unui cod complex are un efect secundar interesant, și anume, acela că va fi mai dificil să distingem alarmele false pozitive. Acest lucru este necesar deoarece omul trebuie să înțeleagă acum acest cod complex pentru a determina clasificarea avertismentului. • Un alt mod ar fi să identifici componentele critice ale proiectului, de exemplu networking, și să îți concentrezi eforturile SCA pe aceste componente critice, după cum s-a demonstrat în secțiunea anterioară despre analiza vulnerabilității. • În pr ivinț a a lar melor fa ls e, invest igare a naturii alarmelor false s-ar putea să merite efortul. Alarmele false se pot clasifica în alarme false veritabile și alarme false perceptive. Primele sunt exemplificări ale faptului că instrumentul a dat greș pur și simplu, sau că trebuie să fie acordat sau că verificatorul trebuie să fie oprit pentru această anumită bază de date. Cealaltă categorie de alarme false (perceptive) este mai mult o problemă ce ține de educația și/sau de prioritizarea dezvoltatorului. Adesea, în special în cazul vulnerabilităților de securitate sau a defectelor de fiabilitate mai subtile, instrumentul are dreptate, dar fie dezvoltatorul nu înțelege de ce este o problemă, fie nu este atât de interesat de acea problemă particulară. Este de datoria vânzătorului de instrument să se asigure că acesta explică în mod clar rapoartele erorilor, dar cealaltă parte a ecuației este un proces sensibil de creștere în interiorul organizației, pentru mai mulți dezvoltatori seniori și/sau educație și training.

Concluzii

Software-ul opensource, Linux de exemplu, este disponibil pentru oricine dorește să îl obțină și să îl utilizeze în produsele sau proiectele sale, atâta timp cât aderă la termenii din licența software-ului opensource. În analiza noastră, am ales Klocwork drept instrument SCA și Linux Kernel drept bază de cod, doar ca și exemple sau instrumente sau proiecte reprezentative, pentru a evidenția problema securizării codului opensource încorporat în software comercial. În general, analiza noastră poate fi extinsă la alte instrumente SCA și alte proiecte opensource. Chiar dacă proiectele opensource definesc canale adecvate de raportare a defectelor de securitate și non-securitate, aceste erori (bugs) sunt raportate de către dezvoltatori individuali pe măsură ce le descoperă, într-o manieră ad-hoc. Orice efort obiectiv dedicat de a analiza static baza de cod opensource, de a documenta și raporta descoperirile, este absentă din comunitatea opensource, chiar dacă, recent companii SCA precum Klocwork sau Coverity (10) au luat inițiativă în această direcție. Dar chiar și așa, viteza cu care versiunile mai noi ale software-ului opensource sunt lansate sau actualizate reprezintă o barieră în calea unor asemenea eforturi. Eforturi precum programele (11) Agenției de Securitate Națională (NSA), www.todaysoftmag.ro | nr. 26/august, 2014

programare Securizarea Codului Opensource (III) Centrului pentru Software Asigurat (CAS), care prezintă un studiu al instrumentelor de analiză statică pentru C/C++ și Java în anul 2010 utilizând teste disponibile drept Juliet Test Suites (14), constituie un pas în direcția corectă, dar chiar și așa, nu există parametri absoluți pentru alegerea unui anumit instrument SCA. Comercianți SCA concurenți tind să găsească probleme destul de diferite într-o bază de cod comună, iar suprapunerea devine aproape neglijabilă prin includerea în comparație a numai trei instrumente diferite. Drept regulă, nu toate problemele identificate prin instrumentele de analiză statică sunt implicit erori (bugs). Un anumit procent din probleme cel mai probabil poate fi ignorat în siguranță după o revizuire adecvată. Totuși, din totalitatea problemelor găsite, o proporție substanțială garantează într-adevăr corectitudinea. Chiar dacă se impune o investigare detaliată suplimentară pentru a stabili exploatabilitatea acestor defecte în perioada de rulare, de exemplu prin fuzzing (4) sau prin Testarea Aleatorie Automatizată Direcționată (DART) (19), analiza noastră demonstrează fără nicio îndoială că aplicarea analizei statice pe codul opensource are avantajul de a descoperi anumite defecte critice din timp, spre deosebire de a aștepta comunitatea opensource să găsească și să raporteze aceste erori, dacă și când vin în contact cu aceste probleme. Identificarea timpurie a acestor erori (bugs) are avantajul de a le corecta mult mai rapid și eficient. Comercianților de software care încorporează cod opensource bazat pe GPL în software-ul lor patentat, li se poate cere să facă întregul proiect opensource, inclusiv codul lor patentat. Aceasta este în contrast cu încorporarea licenței Apache sau a codului opensource bazat pe termenii MPL în software-ul patentat, care nu obligă comerciantul de software să facă întregul

proiect opensource. Acest lucru poate duce la o situație în care o parte din software este opensource, iar restul este patentat. Orice defect (bug) exploatabil găsit în partea opensource a acestui software poate fi virulent și produsul software poate fi ușor exploatat fără nici un efort depus pentru inginerie inversă. În consecință, securizarea codului opensource care este încorporat software-ului comercial este la fel de critică ca și securizarea software-ului patentat în sine. De aceea, odată cu validarea atentă a software-ului patentat nou dezvoltat prin intermediul SCA, este de asemenea foarte recomandabil să se includă analiza statică a oricărui cod opensource necesar produsului, în procesul de validare software general și să se realizeze o revizuire formală a codului opensource necesar, înainte de adoptarea sa. Poate fi făcută o analogie cu abordarea build (construire). Atunci când folosește o bibliotecă opensource, dezvoltatorul ar descărca un binar și l-ar include direct în build, sau ar descărca sursa și ar integra-o în milestone-ul proiectului? Prin faptul că nu utilizează binarul în mod direct și prin descărcarea sursei și încorporarea acesteia în milestoneurile proiectului, proiectul este protejat de problemele ce pot să apară environment-ul de creare a build-ului. Dacă este așa, de ce să nu includem același cod opensource când realizăm analiza statică, împreună cu codul nou dezvoltat? Se știe bine în industria de software: cu cât descoperim mai repede un bug, cu atât mai ieftin este să îl repari, evitând astfel procesele de judecată costisitoare sau daunele iremediabile aduse reputației companiei. În multe feluri, acest efort suplimentar este critic pentru îmbunătățirea calității generale, a fiabilității și siguranței produsului software. În cele din urmă, organizațiile care își pot permite costul și care au nevoie, vor descoperi

nr. 26/august, 2014 | www.todaysoftmag.ro

valoarea acestui efort.

Mulțumiri

Autorul dorește să îi mulțumească lui Wayne Trantow și echipei Opensource PDT de la Intel pentru furnizarea unor perspective valoroase pe parcursul scrierii acestei lucrări.

testare

BBST -Un curs practic despre Testare Software

n contextul dezvoltării profesionale în domeniul IT, programatorii sunt în general foarte obișnuiți cu ideea că, pentru a avansa în cariera de dezvoltator software și pentru a-și dezvolta abilitățile profesionale, trebuie să participe la diferite cursuri, să obțină diferite certificări pentru anumite tehnologii, să învețe tehnici sau limbaje de programare noi, să participe la ateliere unde să aplice în mod practic aceste tehnici și să fie la zi cu ultimele trenduri software. Alexandru Rotaru

alex.rotaru@altom.ro Managing Partner @ Altom Consulting

Ru Cindrea

ru.cindrea@altom.ro Managing Partner @ Altom Consulting

Domeniul testării software nu este foarte diferit de cel al dezvoltării, dar spre deosebire de programatori, testerii au mai puține opțiuni când vine vorba de învățarea de abilități noi. În urma contactului pe care l-am avut la Altom cu tineri absolvenți sau studenți la Politehnică sau Informatică, am observat că, deși facultățile oferă cursuri de testare, studenții nu înțeleg complexitatea problemelor din testarea software și nu pot să aplice conceptele prezentate. În urma interviurilor avute cu diferite persoane pentru poziția de software tester, am observat că, întrebați ce au citit despre testare și de unde își iau informații noi pe domeniul pe care vor să se specializeze, chiar și candidații cu experiență tind să răspundă că au citit ceva articole online, dar de multe ori nu pot să dea un exemplu clar de articol care li s-a părut interesant sau folositor. Mai rar pot să menționeze o carte despre testare pe care au citit-o. Se întâmplă ca unii candidați să menționeze că au învățat din syllabus-ul

de ISTQB. După o serie de întrebări e ușor de observat că mulți dintre candidații care au trecut testul ISTQB Foundations cunosc doar diferiți termeni din domeniul testării software, dar nu stăpânesc de fapt conceptele în sine și nu știu să le implementeze. Materialele ISTQB tratează aceste concepte doar la nivel de definiție, fără să aprofundeze aplicabilitatea lor în diferite situații. Certificările ISTQB sunt în schimb foarte promovate și sunt văzute de mulți ca singura opțiune pentru testerii care vor să se specializeze și să își îmbunătățească abilitățile de testare. Unele dintre firmele care recrutează testeri tind fie să prefere candidați care sunt deja certificați ISTQB, fie să investească în certificarea angajaților. În contextul actual, în care tot mai multe persoane vor să se specializeze pe testarea software, certificările ISTQB axate pe aspecte teoretice creează o nouă problemă: testerii începători nu se simt pregătiți pentru situațiile reale din domeniul dezvoltării software, unde prioritizarea eficientă, abilitățile de comunicare,

www.todaysoftmag.ro | nr. 26/august, 2014

testare BBST Un curs practic despre Testare Software investigare și explorare și lucrul sub condiții de stres sunt extrem de importante, iar testerii experimentați, care caută să își îmbunătățească abilitățile de testare, se simt demotivați și neapreciați și nu găsesc un context în care să lucreze la îmbunătățirea acestor abilități.

Importanța cursurilor de testare software în contextul actual

software online care introduc o abordare practică a testării software, prin care studenții au ocazia să aplice ceea ce învață în mod direct, să testeze diferite aplicații, să scrie planuri de test, să lucreze cu diferite contexte care sunt foarte asemănătoare cu situațiile întâlnite în mod curent la locul de muncă. Spre deosebire de ISTQB, cursurile BBST® nu predau „cele mai bune practici”. În schimb, predau practici care sunt utile în situațiile potrivite, și au în vedere faptul că în contexte diferite se aplică practici diferite. De-a lungul seriei, testarea este prezentată ca investigație. Un investigator bun caută în mod activ informații, nu așteaptă să-i fie date de-a gata. Ideea principală a testării software este de a afla informații despre produs necesare stakeholder-ilor. Nu există nici o formulă predefinită pentru testare, nici “cea mai bună procedură”, nici “cele mai bune practici”. Diferite situații cer diferite abordări și competențe diferite, și, spre deosebire de ISTQB, care prezintă doar aspecte teoretice, cursurile BBST® sunt construite în jurul unor teme și assingment-uri în care studenții lucrează efectiv cu diferite situații și contexte și primesc feedback de la instructori și de la colegi, cu o abordare tip “learning by doing”. Studenții BBST® învață să utilizeze instrumentele care sunt cele mai eficiente în condițiile date, nu un anumit set numit „cele mai bune instrumente”.

În condițiile în care prestatorii de servicii de testare trebuie să rămână competitivi, crește și riscul ca diferențierea acestor serviciilor să se facă pe baza prețului. Ca urmare, abilitățile testerilor intră pe planul doi și accentul se pune doar pe procesele de testare, pe metodele și pe instrumentele folosite. Rezultatul unei astfel de situații lasă mult de dorit: testarea se face prost, în grabă, testerii devin demotivați, activitatea de testare este văzută ca o activitate pe care o poate face oricine, oricând, fără să fie nevoie de abilități speciale pentru a aduce valoare. Este important să ne schimbăm perspectiva și să ne îndreptăm spre un model în care valoarea adusă de serviciile de testare este cea care contează în primul rând. Ca testeri, vrem să fim primii care ne îndreptăm în această direcție și să demonstrăm prin abilitățile noastre de testare și investigare că putem să aducem valoare produsului cu care lucrăm. Nu putem face acest lucru dacă ne concentrăm doar pe procese și metode și dacă ne mulțumim Seria de cursuri BBST® cu un certificat în loc de dezvoltarea unor La momentul actual, seria de cursuri abilități. BBST® include patru cursuri: Pentru a deveni niște testeri cu adevărat • BBST® Foundations - primul curs buni, e nevoie de exercițiu, de practică, de din serie, axat pe conceptele de bază în exemple din contexte diferite și de feedtestarea software. Studenții lucrează și back din partea unor oameni care au o aprofundează conceptele de strategie de experiență vastă. testare, misiunea testării, test coverage, și încearcă să lucreze cu problemele cele Alternativa practică mai grele din testare: Din fericire, cursurile ISTQB nu mai • Cum știm dacă un program a tresunt singura opțiune. Cursurile BBST® cut sau nu un test? oferă o alternativă practică fiecărui tester • Când ne oprim din testat? care vrea să își îmbunătățească abilitățile • Cum hotărâm că am acoperit necesare în testare. produsul îndeajuns de bine? BBST® este un acronim relativ nou în • Cum măsurăm testarea și calitaRomânia în domeniul cursurilor de testare tea testării pe care am făcut-o? software, dar care s-a dezvoltat semnificativ • BBST® Bug Advocacy - un curs în ultimii ani, după ce numeroși absolvenți axat pe una dintre cele mai importante BBST® au descris importanța acestor cursarcini pentru un tester: găsirea și raporsuri și au vorbit despre influența și ajutorul tarea defectelor și problemelor software, pe care materialele BBST® le-au adus în punerea accentului pe importanța lor din mod direct și practic în munca lor de zi cu punctul de vedere al utilizatorului final, zi. izolarea unei probleme, adăugarea de BBST® (sau Black Box Software Testing) informații suplimentare. Studenții vor reprezintă o serie de cursuri de testare lucra cu un produs software open-source,

nr. 26/august, 2014 | www.todaysoftmag.ro

vor căuta probleme raportate deja, vor raporta probleme noi și își vor dezvolta abilitățile de raportare și detaliere a defectelor. • BBST® Test Design - un curs introductiv în diferitele tehnici de design de teste, cu accent pe câteva dintre cele mai uzuale. Studenții învață să aplice anumite tehnici, să înțeleagă punctele tari și punctele slabe ale diferitelor tehnici prezentate, astfel încât ulterior să poată decide care tehnică e mai potrivită pentru contextul în care lucrează. • BBST® Domain Testing - un curs extrem de practic care aprofundează una dintre cele mai cunoscute tehnici de testare: crearea claselor de echivalență pe domeniul variabilelor dintr-un program și alegerea de reprezentați pentru crearea de teste a căror eficiența în descoperirea bug-urilor este maximizată.

BBST® - un curs online

Cursurile BBST® sunt organizate online. Dacă vă imaginați ceva similar cu o sesiune gen webinar de mai lungă durată, veți fi surprinși să aflați cât de diferite de această idee și cât de interactive sunt aceste cursuri. Cursurile durează patru săptămâni și folosesc o platformă online care facilitează interacțiunea directă atât cu ceilalți studenți cât și cu instructorii cursului. Primele trei săptămâni sunt pentru lecții, teme și laboratoare (câte două lecții pe săptămână) iar ultima săptămână este dedicată examenului final. Fiecare lecție conține: • o lecție video cu Cem Kaner și slideuri pentru ea. • un test/quiz cu întrebări grilă care sunt menite doar să ajute aprofundarea materialelor și nu afectează decizia finală de trecere a cursului (notele primite sunt doar orientative pentru studenți). • un laborator sau o temă prin care studenții aplică direct și în mod practic conceptele explicate în lecția video. De exemplu, pentru una din primele lecții din cursul BBST® Foundations, studenții primesc o descriere a unui produs întrun context anume, pentru care trebuie să scrie o strategie de testare, răspunzând la niște întrebări specifice legate de ceea ce trebuie să acopere. Pe lângă acest tip de abordare foarte practică, studenții primesc pentru fiecare temă feedback și comentarii din partea instructorilor cursului, care participă activ la discuții și încearcă să îndrume studenții de-a lungul procesului de învățare. Studenții primesc și dau feedback de

TODAY SOFTWARE MAGAZINE asemenea și colegilor lor de clasă, și mulți dintre absolvenții BBST® spun că au învățat extrem de mult nu doar de la instructorii cursului, dar și de la colegi. Fiecare student contribuie la fiecare lecție, aducând aspecte noi, descriind contexte diferite de cele în care lucrează alți studenți - și această diversitate de opinii face experiența mult mai folositoare. De la începutul cursului, studenții au acces la un set de întrebări cu răspuns deschis care acoperă temele discutate în fiecare modul. Examenul final conține întotdeauna un subset al acestor întrebări, pentru care studenții pregătesc răspunsuri tip eseu. Pe parcursul cursului și în special în ultima săptămână din curs, când nu mai există alte teme sau laboratoare, studenții pot să discute întrebările împreună, să își revizuiască unul altuia răspunsurile și să le îmbunătățească pe măsură ce aprofundează conceptele. Examenul final nu va fi deci “o surpriza”, ci o finalizare firească a muncii de-a lungul celor patru săptămâni. În urma examenului, studenții primesc feedback fie într-o discuție pe Skype cu unul dintre instructori, fie în scris - la alegerea studenților. Decizia finală de trecere a cursului este luată de instructori în funcție nu doar de răspunsurile date la examenul final, ci în urma unei evaluări a întregii contribuții de-a lungul cursului și în funcție de performanța studenților la toate activitățile incluse. Spre deosebire de ISTQB, unde decizia finală este dată de alegerea răspunsurilor corecte dintr-un test grilă, la BBST® instructorii urmăresc în primul rând evoluția individuală a fiecărui student, înțelegerea și în mod special aplicarea conceptelor prezentate. Comunicarea, atenția la detalii, implicarea pe parcursul cursului și interesul arătat pentru a învăța și a deveni un tester mai bun contează și ele în decizia finală.

Scurt istoric

Materialele din cursurile BBST® au fost dezvoltate ca parte dintr-un studiu de cercetare susținut de Grantul NSF “Improving the Education of Software Testers” (Îmbunătățirea Educației Testerilor de Software) și “Adaptation & Implementation of an Activity-Based Online or Hybrid Course in Software Testing” (Adaptarea și implementarea unui curs on-line sau hibrid bazat pe activități în testarea software”). Autorul principal al materialor prezentate în curs este Cem Kaner (http://kaner. com) - “Profesor de Inginerie Software” la Institutul de Tehnologie din Florida și coautorul uneia dintre cele mai cunoscute cărți de testare software: Lessons Learned in Software Testing (Cem Kaner, James Bach, Bret Pettichord). Materialele care se află la baza seriei de cursuri BBST® sunt folosite în cursurile predate de Cem Kaner la Universitatea de Tehnologie din Florida. Acestea au fost adaptate și modificate pentru a putea fi predate unei audiente mai largi, online, de către Rebecca Fiedler, care deține un doctorat în educație de la Universitatea Centrală din Florida.

așa cum e testarea software, e greu să găsim ocaziile de a exersa o tehnică în cadrul proiectelor pe care lucram, e greu să creăm situații progresiv mai complexe. În cazul real al unui produs în dezvoltare, mai ales în contextul Agile, ca testeri, abia avem timp să reacționăm, cu atât mai puțin să exersăm. Este la fel de greu uneori să găsim mentori care pot să investească timp pentru a ne da un feedback util la munca pe care o facem și care pot să ne ajute să creștem și să ne îmbunătățim abilitățile de testare. Cursurile BBST® creează un mediu de învățare în care ne putem permite să exersăm tehnici diferite și să le încercăm în diferite situații, să primim și să dăm feedback. E un mediu în care contextul și problemele sunt foarte similare cu cele reale de la locul de muncă, dar în care o greșeală înseamnă cu adevărat doar o nouă oportunitate de învățare. E ca un mediu de test pentru testeri.

De ce BBST®?

Vorbind despre cum putem să ne dezvoltăm anumite abilități, Cem Kaner spune: „Cred că cel mai bun mod pentru o persoană să își dezvolte niște abilități este să facă ceva, să primească feedback despre cum să facă acel ceva mai bine, să îl facă mai bine (sau să facă ceva similar), să primească feedback și să continue să facă același lucru pe probleme care devin progresiv mai grele sau care aplică tehnica într-un mod nou.” Procesul descris sună atât de firesc încât pare evident. Din experiența personală, într-un domeniu complex și în continuă dezvoltare

www.todaysoftmag.ro | nr. 26/august, 2014

legal

Folosirea serviciilor de tip cloud nu e lipsită de riscuri juridice

loud computing este un concept cool, vehiculat des în domeniul IT și cu o creștere vertiginoasă. Potrivit unui raport al IHS Technology din februarie 2014, se estimează că până în 2017, companiile vor plăti 235.1 mld.$ pentru servicii de cloud – adică de trei ori mai mult decât în 2011. Printre giganții care își împart piața de cloud se numără Amazon, Google, Microsoft, Barracuda Networks, Dropbox, etc. – fiecare cu „specializarea” sa de cloud.

În luna mai, când am participat la Cluj la evenimentul de nișă ITCamp, unul dintre subiectele intens abordate a fost folosirea Microsoft Azure. Iar experții prezenți au dezbătut pe larg provocările de natura tehnică privind această platformă de cloud. Dar este bine de știut că pe lângă provocările tehnice există și provocări legale deloc de neglijat care pot influența masiv activitatea “jucătorilor” din industrie. Motivul? Furnizorii de cloud se confruntă constant cu o dilemă: ei trebuie să furnizeze soluții cât mai avantajoase și inovatoare din punct de vedere tehnic și comercial, dar în același timp, trebuie să se conformeze regulilor privind protecția și securitatea datelor cu caracter personal (adică cele care vizează persoanele fizice). Or, acest echilibru este uneori greu de atins. Microsoft România a văzut necesitatea de a aborda problematica datelor personale în cloud. Pe 4 iunie, a organizat la București un eveniment dedicat cloud computing-ului, invitând și un reprezentant al ANSPDCP (Autoritatea competentă în Domeniul Datelor Personale). S-au abordat unele provocări din perspectiva serviciilor enterprise oferite de Microsoft (Windows Azure, Dynamics CRM Online și Office 365). Din experiența clienților mei știu că există unele probleme controversate și, așa cum mă așteptam, au fost multe întrebări. La unele dintre acestea, răspunsurile reprezentantului autorității au arătat clar faptul că în viziunea autorității, cloud-ul are în practică unele „zone gri” care rămân a fi interpretate de la caz la caz de către experți.

În final

De multe ori, folosirea serviciilor de tip cloud poate fi o zonă a nisipurilor mișcătoare din punct de vedere juridic. De aceea, e necesară conștientizarea faptului că implică anumite riscuri. Dacă și cum pot fi acestea eliminate sau măcar minimalizate, depinde de la caz la caz – în funcție de tipul de serviciu cloud și de puterea de negociere a clientului. În cazul acelor servicii cloud pentru care nu se încheie contracte de adeziune (cum sunt contractele enterprise care, în general, nu pot fi negociate), este indicat ca furnizorul și clientul să negocieze unele clauze privind, de exemplu: funcționalitatea și disponibilitatea serviciilor, locul stocării datelor, responsabilitățile ambelor părți privind datele personale, proprietatea intelectuală și limitarea răspunderii.

Important de reținut

Există tipuri diferite de servicii și modele de cloud care atrag în practică consecințe variate, cu obligații legale diferențiate. De exemplu, în timp ce Microsoft Dynamics CRM e Software as a Service (SaaS), Microsoft Azure e Platform as a Service (PaaS) și Infrastructure as a Service (IaaS) pentru Virtual Machines. Deosebirile lor tehnice atrag și diferențe din punct de vedere legal. Una dintre diferențe este că în PaaS, principial datele nu sunt reținute și prelucrate de către furnizorul de cloud. Ceea ce înseamnă că, de exemplu, clientul enterprise al Microsoft (care, de obicei, doar pune platforma Azure la dispoziția clienților proprii) nu colectează datele cu caracter personal furnizate atunci când aceștia creează aplicații sau stochează informații în Azure. În consecință, dacă nu are acces și nu folosește datele personale stocate de clienții săi, nu ar trebui să fie ținut de obligațiile legale privind notificarea la autoritatea competentă, implementarea unor măsuri de securitate, condițiile speciale în care datele pot fi dezvăluite altor persoane, etc. .

nr. 26/august, 2014 | www.todaysoftmag.ro

Claudia Jelea

claudia.jelea@jlaw.ro Avocat & Consilier in domeniul marcilor @ Jlaw Claudia este specializată pe aspecte juridice ce implică mediul online, comerțul electronic și IT&C, protecția datelor cu caracter personal și proprietatea intelectuală.

sponsori