TO DAY SOFTWARE Nr. 26 • August 2014 • www.todaysoftmag.ro • www.todaysoftmag.com MAGAZINE 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 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 Să vorbim despre Swift Întreținerea la zi a sistemelor Linux – Partea a II-a
Transcript
TSM T O D A YS O F T WA R E
Nr. 26 • August 2014 • www.todaysoftmag.ro • www.todaysoftmag.com
M AG A Z I N E
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
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
Să vorbim despre Swift
Întreținerea la zi a sistemelor Linux – Partea a II-a
6Standardele deschise – o miză pentru România
Daniel Homorodean
10Poveşti de succes la finalul How
to Web MVP AcademyIrina Scarlat
12Noi modele de educație pen-
tru pasionații de tehnologie: bootcamp-ul Simplon
Roxana Rugină
15SEETEST 2014
Irina Scarlat
16Aplicaţie IT în SAP prezentată la
‘IT Conference on SAP technologies 2014’- Cluj
Horea Rațiu
18Informație structurată -
aplicare AgileBogdan Mureșan
21Întreținerea la zi a sistemelor
Linux (II)Sorin Pânca
26Să vorbim
despre Swift Valentin Filip
2
28Limbajul HackRadu Murzea
30Clean Code -NamingRadu Vunvulea
32TYPO3 Neos - Schimbând ecosistemul sistemelor de administrare a conţinutuluiTomiță Militaru
Lansarea 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 înca-
dreze în limitele a două minute. Cei interesați sunt rugați să trimită o scurtă descriere și un link la site/produs la adresa [email protected]. 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 Cluj-Napoca 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 standarde-lor 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ă progra-meze, 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 manage-ment 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.
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 trans-parente, î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.
Ce sunt Standardele Deschise ?De-a lungul timpului, o serie de organizaţii sau guverne au
încercat să dea o definiţie proprie a conceptului de Open Standard. În funcţie de compoziţia și de interesul acestor entităţi, definiţia
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ă cos-turi. 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 guver-namentale ale ţărilor dezvoltate, deoarece prin folosirea lor se asigură interoperabilitatea între sisteme și între instituţii și acce-sul 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 au definit clar, prin normative, Standardul Deschis. Toate specifică faptul că standardul trebuie să fie gratis, unele ( Africa de Sud s.a. ) chiar specificând că standardul “trebuie să fie întreţinut de către o organizaţie ne-comercială”. Caracterul extensibil al standardului este explicit precizat în multe cazuri - aspect important, pentru că unele standarde sunt deschise pentru utilizare, dar nu permit extinderea lor decât după ce cumperi acest drept. Deocamdată, România nu a adoptat o definiţie a standardului deschis, dar acest
Acum 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 docu-mente. De acum, orice software cumpărat de instituţiile guvernamentale britanice trebuie să fie compatibil cu ODF.
Young spiritMature organizationA shared vision
Join our journey!
www.fortech.ro
7www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINE
lucru va fi necesar, tocmai pentru că nu există o definiţie „uni-versală” 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 inter-net, SMTP să schimbăm mesaje, PCI și USB ne lasă să conectăm echipamentele. Din pleiada de standarde deschise cu care inter-acţ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 preci-ză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, SVGHTML, XHTML, UTF-8/UTF-16, ePub, PostscriptOffice Open XML ( OOXML )Open Document Format ( ODF )PDF ( partial, doar subsets)gzip, tar, ZIPCSS, 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 apli-caţ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, stand-
ardele și mai ales formatele deschise au două obiective majore:• asigurarea interoperabilităţii între instituţii,• asigurarea accesului cetăţeanului, organizaţiilor și opera-
torilor economici la informaţia publică, gratis și fără costuri ascunse ( licenţieri de programe).
Desigur, eficientizarea costurilor este și ea un motiv impor-tant, 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 infor-marea 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 ODFOffice Open XML ( OOXML, OpenXML) este un format bazat
pe XML și arhivat (zipped), folosit pentru descrierea formatelor documentare ( spreadsheets, presentations, word processing docu-ments, 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 com-itetul 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 /
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 incom-petenţ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ţinu-tului 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, prec-edentul 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 standarde-lor ș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 imple-mentarea sistemelor și publicarea informaţiilor.
Cluj IT Cluster şi standardele deschisePentru Clusterul Cluj IT este foarte importantă promovarea
bunelor practici și a standardelor în industria IT, cu avantaje sem-nificative în toate sectoarele de activitate și în special în mediul public. Open Data, accesibilitatea web, open source sau open stand-ards 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ă.
Prima ediţie How to Web MVP Academy a avut loc în perioada 2 iunie – 22 iulie la TechHub Bucharest și a adus împre-ună 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 dez-voltare ș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 pro-fesioniștilor în tehnologie la nivel regional, și au beneficiat de workshop-uri, mentorat și conexiuni cu investitori de tip angel, pro-grame de accelerare și fonduri de investiţii early stage.
Pe parcursul programului, echipele How to Web MVP Academy au avut oca-zia 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 suc-ces la scară globală, cum să facă networking cu clienţii și partenerii de afaceri sau cum să își spună povestea și să își prezinte pro-dusul î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 reco-mandări din propriile experienţe. Printre men-torii 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 pen-tru Romtelecom şi COSMOTE România şi le considerăm parteneriate mutual bene-fice 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
ş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, profe-sioniș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 investi-tori! Şi sper că ne vom întâlni la anul şi îmi veţi spune cu mândrie că vă număraţi prin-tre 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 cinematogra-fului 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
eveniment
Poveşti de succes la finalul How to Web MVP Academy
Bucureș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.
valoare rezultatele educaţionale4. Drimm.in – platformă care monito-
rizează 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 restauran-telor 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 per-mite 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
internet11. Qalendra – platformă de călăto-
rii 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 aces-tora 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ţă inte-resate î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 pro-duse şi să dezvolte afaceri sustenabile şi au cunoscut oameni care îi vor ajuta să meargă la următorul nivel. Am adaptat în per-manenţă activităţile din
program pentru a răspunde nevoilor speci-fice ale fiecărei echipe, iar rezultatele au fost pe măsura aşteptărilor. Startup-urile fina-liste 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 pro-priile 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.
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 des-chide 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 publi-citate 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 prin-tre spam-urile managerilor de HR. Când reușeam să ajung la un interviu mi se spu-nea 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
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 PHD-uri ș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 des-chide în curând și în Tunisia, Brazilia,
La 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.
business
Noi modele de educație pentru pasionații de tehnologie:
bootcamp-ul Simplon
13www.todaysoftmag.ro | nr. 26/august, 2014
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 speciali-zată î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.
Noile tehnologii se schimbă foarte rapid. Pentru a dezvolta soluții inovatoare, Sim-plon 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
Statele Unite și l-a adaptat la piața euro-peană. Ş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 conti-nuare candidați. Programul se adresează în special persoanelor subreprezentate în mediul digital și care au nevoie de trai-niguri 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 calif icat, cu
experiență de lucru în medii de lucru dina-mice, 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, market-ing, geografie care nu-și găsesc de lucru.
TODAY SOFTWARE MAGAZINE
14 nr. 26/august, 2014 | www.todaysoftmag.ro
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 eva-luă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 urma 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 teh-nici 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 tehno-logia 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.
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 con-trola 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.
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
Bucureş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 & per-formanţă sau principiile de bază ale testării de aplicaţii mobile.
Cea de a doua zi a evenimentului este dedicată discursurilor susţinute de execu-tivi 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 com-paniilor internaţionale din domeniul calităţii software-ului șansa de a-și pre-zenta 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ă testa-rea de software, tehnici și design al testării, managementul proceselor de testare, testa-rea 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 dis-cuţ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).
Cele două ediţ i i 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 reu-nit peste 250 de vizitatori. SEETEST 2014 va aduce împreună aproximativ 300 de par-ticipanţ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 sesi-unile 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 dispo-nibile până la data de 31 august. Grupurile de peste 5 persoane, membrii organizaţii-lor partenere, studenţii și partenerii ISTQB beneficiază de o reducere de 10% dispo-nibilă după încheierea perioadei early bird. Biletele la SEETEST 2014 sunt dis-ponibile online la http://seetest.org/index.php?page=registration.
Cea de a treia ediţie a conferinţei de testare de software din
msg systems România a dezvoltat în Cluj-Napoca, un produs IT bazat pe ultimele tehnologii propuse de SAP. Proiectul dema-rat 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 colab-orare cu consultanţi business ai branşei asigurări – reasigurări. Dezvoltarea soft-ware 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 des-chisă. 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: [email protected].
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 asi-gură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.
Aplicaţie IT în SAP, dezvoltată de msg systems România, prezentată la ‘IT Conference on SAP technologies 2014’- Cluj şi la inscom 2014
Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 585 / Nr. Evenimente: 46
Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Website: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmagData înfiinţării: 06.02.2012 /Nr. Membri: 1671/Nr. Evenimente: 21
Cluj Business AnalystsComunitate dedicată analizei de businessWebsite: www.meetup.com/Business-Analysts-ClujData înfiinţării: 10.07.2013 / Nr. Membri: 80 / Nr. Evenimente: 8
Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobileWebsite: www.meetup.com/Cluj-Mobile-DevelopersData înfiinţării: 05.08.2011 / Nr. Membri: 221 / Nr. Evenimente: 14
The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 440 / Nr. Evenimente: 81
Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 187/ Nr. Evenimente: 28
Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 246/ Nr. Evenimente: 14
Tabăra de testareUn 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
Cu 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.
Calendar August 12 (Cluj)Lansarea numărului 26 a Today Software Magazine (Cluj)www.todaysoftmag.ro
August 18-23 (Cluj)MoodleMoot Romania 2014it-events.ro/events/moodlemoot-romania-2014-18-23-au-gust-cluj-napoca/
August 21 (Iaşi)Mastering Requirementsmeetup.com/Tabara-de-Testare-Iasi/events/181662022/
August 21 (Cluj)#13 PM Meetup - Risk Managementmeetup.com/PMI-Romania-Cluj-Napoca-Project-Management-Meetup-Group /events/194808502
August 27 (Bucureşti)Bucharest FP #3 — Haskell Types and QuickCheckmeetup.com/bucharestfp/events/198339372
August 29 (Oradea)Startup Weekend Oradeaoradea.startupweekend.org
Septembrie 4 (Cluj)IT Conference on SAP - recomandat de TSMhttp://www.msg-systems.ro/agenda_sap.0.html
Septembrie 8 (Cluj)Design Patterns Master Class - recomandat de TSMcodecamp-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 Clusterwww.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 con-ceptul 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ă manage-ment 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, deve-nind 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ân-duri, 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.
Managementul este într-o continuă evoluție. Noi framework-uri, noi metodolo-gii 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.
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 indu-stria 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 pen-tru 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 proj-ect 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 rezol-vat 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 con-texul ș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
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 pro-cese: 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 stakeholder-ii. 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 începu-tul 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ă sun-tem 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, proce-sul 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 (veloci-tatea 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ă regu-lile PMI ca referință (proiectele conduse după metoda Waterfall se mulează perfect pe această structură) putem să vedem
programare
www.3pillarglobal.com
3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.
Our core competencies include:
ProductStrategy
ProductDevelopment
ProductSupport
Our offerings are business focused, they drive real, tangible value.
20 nr. 26/august, 2014 | www.todaysoftmag.ro
management
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 pro-cesul ș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 sim-plu precum achiziționarea unui set de controale, câteodată poate fi ceva mai com-plicat 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 man-agementul achiziților. Trebuie să știm cum să definim regulile pentru selectarea ven-dorului ș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 detali-ile fiecărei arii de cunoaștere dar dacă am face o analiză și mai detaliată, am con-stata 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 tre-bui să se oprească la primul framework care funcționează. Cu cât știm mai multe, cu atât putem acționa mai eficient deo-arece 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 framework-uri 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.
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.
Informație structurată - aplicare Agile
21www.todaysoftmag.ro | nr. 26/august, 2014
Acest 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 sistemu-lui de fișiere pentru un centru de calcul, vom realiza o scurtă clasificare și istorie a
sistemelor de fișiere.
Sistemele de fișiere se împart în două cat-egorii, în funcție de localizarea lor:
A. Sisteme de fişiere locale - de obicei aceste sisteme rezidă pe un dispozitiv local:
a. disc dur cu platane (HDD);b. 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”);
c. disc optic (CD/DVD/BlueRay);d. RAID - 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);
e. memorie RAM cu acumulator, conectată la interfața PCIe;
f. memristor (nelansat încă).
B. Sisteme de fişiere pe rețea (nu le voi enumera pe toate, ci voi da doar câteva exemple, în ordinea evoluției, pentru a ilustra arhitecturile și conceptele ce le au în comun și care stau la baza funcționării lor):
a. cu punct de acces unic, pe modelul client - server: CIFS (cunoscut ca My Network Places în Windows), NFS, FTP, rsync, IMAP, scp, WebDAV, etc.;
b. de tip cluster cu replicare la nivel de bloc de date: DRBD, Microsoft DFS, GlusterFS;
c. de tip cluster cu replicare la nivel de fișier: Lustre, Ceph, MooseFS, XtreemFS.
Istoric, calculatoarele erau sisteme izo-late a căror arhitectură consta în: Procesor,
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 ordi-
nul 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, uti-lizând ambele fețe și o densitate mare a datelor);
• discuri dure de 3,5”;• restul de medii, enumerate mai sus.
A urmat revoluția rețelelor, când a apărut nevoia de a transfera fișiere fără a duce fizic un suport de date (discheta) de la un sistem la altul, în special în scopul comunicării în timp real.
Astfel a apărut ideea de „model server - client” în care un sistem care deținea o resursă (de exemplu un fișier) putea să o pună la dispoziția altor sisteme folosind un limbaj de comunicare (protocol) printr-un canal de comunicație (rețeaua); acest sistem joacă rolul de „server” (sau servitor, pentru că servește resurse). Un sistem de calcul care are nevoie de o resursă (clientul) ce se găsește pe un alt sistem, poate contacta sistemul 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, rezolva-rea lor este notată cu R) :
• doi clienți vor să actualizeze aceeași resursă deodată (R: sis-temele de fișiere de rețea implementează blocarea resurselor);
• prea mulți clienți doresc aceeași resursă, epuizând capaci-tatea 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, deo-arece 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 sto-care 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:
a. 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.
b. 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”.
c. 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
d. RAID6 - oferă protecția datelor prin calculul a două sume de control; viteză mai scăzută decât RAID5
e. 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)
f. 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 availabil-ity) 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ă ser-vere țin fișierele sincronizate, pot accesa sistemul de fișiere simulat și îl 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 con-tinuu. 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 administra-torului: 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
programareÎntreținerea la zi a sistemelor Linux – Partea a II-a
23www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINE
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 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țeaDeș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 meta-date (MRC) și servicul director (DIR), iar autorii doresc să îl distribuie doar ca binar în viitor, ceea ce este ortogonal cu principi-ile enunțate la sfârșitul introducerii.
Inițial am studiat toate variantele de sis-teme 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 adop-tat 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 programa-tor 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 gra-tuit 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 supe-rior 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 sis-temele vechi să conțină mai puține defecte (bug-uri), dar e important de luat în con-siderare faptul că și un sistem vechi care e încă în dezvoltare continuă să acumuleze defecte. Nu există o metodă de a demon-stra 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 arhitec-turale 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 tre-buie să își asume resposabilitatea de a contribui la proiectele care au produs pro-gramele utilizate prin corectarea sau măcar raportarea erorilor către producători. O altă responsabilitate a administra-torului 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 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 responsabili-tatea pentru aceste defecte.
Lustre este folosit în mediile academice și de cercetare unde este nevoie să se pre-lucreze 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 administra-torii 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 material-izat, î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 „mas-ter”; această a 2-a problemă putea fi rezolvată de administratorul sistemului.
Arhitectura MooseFS permite extin-derea 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 chunk-servers). Fiecare fișier primit de la clienți spre a fi stocat, are asociat o țintă de mul-tiplicare, 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 tre-buie 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, distribu-ite pe oricâte noduri, nu doar două.
P o z i ț i o n a r e a f i ș i e r e l o r e s t e memorată pe nodul „master” al cărui 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: metadata.mfs. Î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 infra-structura 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 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 multi-plicate 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 com-ponente 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,
Întreținerea la zi a sistemelor Linux – Partea a II-a
25www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINE
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 în nici un fel disponibilitatea sistemului. Singurul punct care prezintă pericol în configurația standard este nodul master, dar la intervenția manuală a administra-torului, 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
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 calcu-latorul 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 utiliza-rea eficientă a resurselor. Ce poate fi mai important decât să știi că TOATE discurile
d i n c e n t r u l de calcul sunt u m p l u t e l a același procent și că oricând e nevoie de mai m u l t s p a ț i u se pot adăuga noduri supli-mentare, fără întreruperi în funcț ionarea s i s t e m e l o r ? MooseFS mai o f e r ă d o u ă facilități inte-resante pentru cei ce rulează m a ș i n i v i r -tuale aproape identice: snap-shotting și coş de gunoi configurabil. Coşul de gunoi șterge fișierele care ating o anumită limită de timp configurabilă de către administratorul 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 „dedupli-care”. Î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 scri-erii” (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.
În partea a III-a voi discuta despre LxC, o metodă de virtualizare a sistemelor Linux fără pierderi de performanță, care face posibilă actualizarea controlată fără întreruperea serviciului.
26 nr. 26/august, 2014 | www.todaysoftmag.ro
Să vorbim despre Swift
Compania 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.
Pe data de 2 Iunie, Swift a fost făcut cunoscut developerilor, cu promisiu-nea 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 infe-rence 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 pro-gramator obișnuit. Deși simplul fapt de a putea fi un programator pentru dispozi-tivele mobile ale companiei Apple poate reprezenta un motiv suficient, eliminarea barierelor limbajului de programare face
ca adoptarea noii platforme să fie sporită. Swift oferă posibilitatea de a scrie cod pen-tru 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 schimba-rea. Au existat și alte limbaje dezvoltate până acum, dar fără a avea impactul dorit, deși au fost susținute de companii impor-tante 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 ade-vă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 pre-cum “inferred typing” prin care nu mai este necesară specificarea tipurilor pentru vari-abilele folosite, mai ales că în același timp codul este mai sigur, variabila preluând
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 integra-rea 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 abili-tatea 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 aces-tea î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ă.
Va dispărea oare Objective-C? 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 rescri-erea 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 vii-tor. 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 folo-site 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
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 scri-ere a codului este vizibil similară:
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”, com-portamentul variabilelor este puțin diferit.
Swift a împrumutat multe trăsături de la alte limbaje de pro-gramare, 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 folosirePentru a exemplifica utilizarea de Swift, în continuare este un
exemplu de aplicație pentru calcularea bacșișului.
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 ecosiste-mului 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 rea-lizabilă în viitorul apropiat. Drept urmare, orice revoluționare a platformei este mai mult decât binevenită și cu siguranță va pro-duce 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.
28 nr. 26/august, 2014 | www.todaysoftmag.ro
testare
Limbajul Hack
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 avan-taje 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 Facebook-ului 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 pen-tru 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.
Hack-ul în detalii. După cum menționam mai sus, Hack este un limbaj hibrid
care aduce în lumea PHP-ului (un limbaj dinamic) avantajele unui model static. Nu este nimic altceva decât o extensie sintactică a PHP-ului.
Hack-ul rulează momentan doar pe maşina virtuală HipHop, de la versiunea 3.0 şi în sus a acesteia. A fost făcut open source în Martie 2014.
Un aspect important este faptul că, dacă ştii PHP, atunci ştii Hack.
Există două caracteristici foarte importante ale Hack-ului care i-a asigurat adopţia în cadrul Facebook-ului şi, poate în viitor, şi în cadrul unor aplicaţii terţe:
a. Interoperabilitatea. Cu extrem de puţine excepţii, dacă ai 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 şi vice-versa. Cele două sunt interoperabile pentru că, la run-time, au aceeaşi reprezentare în memorie: HHBC (HipHop Byte Code).
b. Gradualitate. Limbajul este dezvoltat cu un puternic aspect de gradualitate,demonstrându-se că programatorul este liber să decidă care fişiere din aplicaţia sa vor fi transformate în Hack şi, pe deasupra, cât de puternică şi (in)completă va fi această
transformare. Da, aşa este: poţi introduce treptat facilităţi ale Hack-ului, după cum îţi pofteşte inima.
FacilităţiHack-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 tipuriDe 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 varia-bilelor 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 asemenea, având în vedere existenţa în acest fel a informaţiei stat-ice în plus, compilatorul JIT din cadrul maşinii virtuale va putea intui mai bine ce căi de execuţie vor fi traversate mai des. Acest aspect demonstrează performanţa crescută.
GenericsMulte limbaje au această calitate. În Hack, generics-urile vin ca
o întărire şi mai puternică a conceptului de anotări descrisă mai sus. Implementarea şi sintaxa lor este mai simplă şi mai limitată decât în cazul limbajelor Java şi C# de exemplu. În schimb, în Hack se permite folosirea tipurilor de date primitive şi chiar a instanţelor de obiecte pentru a specifica tipul de date generic.
Există totuşi nişte cazuri speciale de care trebuie ţinut cont în legătura cu această facilitate.
ColecţiiLa fel cum cele mai multe limbaje statice oferă această
funcţionalitate, aceasta e binevenită şi în Hack. Cele mai impor-tante clase din acest framework sunt “Map”, “Vector” şi “Set”, fiecare dintre acestea având un corespondent care oferă imutabilitate.
Codul PHP obişnuit este de obicei împânzit cu array-uri. Dacă, în schimb, se vor folosi aceste clase, atunci codul va deveni mai clar şi, în unele cazuri, se vor vedea şi sporuri de performanţă.
Acest 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).
programare
29www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINEtestare
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 lambdaAcestea 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.
XHPAceasta e o extensie opţională a Hack-ului care permite folo-
sirea de blocuri XML/HTML ca pe nişte elemente standard de sintaxă. În acest fel se uşurează foarte mult munca în cadrul codu-lui care conţine logică şi elemente specifice templating-ului.
Hack oferă şi alte facilităţi minore demne de luat în calcul. De asemenea, o parte din elementele de sintaxă ale PHP-ului despre care se ştie că sunt ineficient sau rar folosite, sunt dezactivate, cum ar fi de exemplu operatorul “@”, operaţiunea “goto”, globalele (“global $x”) şi multe altele. Prin urmare, acest nou aspect luat în considerare va forţa programatorul să urmeze bune practici de programare.
Mai jos puteți vedea o bucată de cod care exemplifică multe din facilitățile prezentate mai sus. Puteți vedea cum sunt specificate anotarile de tipuri, cum e folosită una din clasele din framework-ul colecțiilor, un exemplu de tipuri generice și o expresie lambda simplă:
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; }}
UnelteMaş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
codebase foarte mare, acest proces poate să dureze. De exemplu, pentru a transforma codul sursă a Facebook-ului (aproxima-tiv 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 echiva-lente pentru majoritatea editoarelor şi IDE-urilor populare.
Erorile raportate de typechecker sunt doar legate de anotările de tip. Timpul de răspuns al acestuia este foarte rapid datorită monitorizării constante a sistemului de fişiere.
Acest typechecker are în schimb o serie de limitări:• cazul de utilizare intenționat pentru acesta e un proiect care
include un autoloader. Va funcționa şi fără, însă nu în mod optim.
• toate numele de clase și de funcții trebuie să fie unice în respectivul proiect pentru a obține rezultate corecte.
• nu suportă declararea condițională a funcțiilor și claselor.• trecerea din cod Hack în cod HTML și înapoi nu este
suportată având în vedere că nu se mai practică o astfel de metodologie și se încearcă descurajarea acesteia.
ConcluzieHack-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.
Dacă 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 cei-lalţ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.
De ce?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 arti-
col. 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ă utili-zezi 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 taUn nume bun poate să îţi economisească 10 minute de
debugging (depanare) sau 20 de minute de căutare prin docu-mentaţ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;
Dacă ne uităm peste aceste definiţii ale câmpurilor sau dacă le vedem undeva în codul nostru, nu am avea nicio idee despre ceea ce reprezintă aceste câmpuri sau de ce au fost ele utilizate (create).
Denumirile de mai sus ne oferă mai multe informaţii despre câmpurile noastre. Ne este clar care este scopul fiecărui câmp și ce fel de informaţii ne oferă.
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.
Evitaţi dezinformareaGă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. carListhouseList
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 repre-zintă 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âmpuri-lor. Î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ă.
Î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.
Faceţi diferenţe cu înţelesÎntr-o aplicaţie, se poate întâmpla să sfârșești prin a avea denu-
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ă adăugăm numere la finalul unei denumiri.
În exemplul de mai jos avem o metodă care transformă un şir dintr-un format în altul.
void Convert(string s1, string s2)
Clean Code - Naming
31www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINE
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:
CarCarDataCarInfo
Problema cu această denumire este că nu există o diferenţă clară între „Data” și „Info”. Cititorul nu va ști ce fel de informaţie conţine fiecare clasă.
Utilizarea sufixelor sau a prefixelor care reprezintă tipul câm-pului nu ne ajută să facem un cod mai lizibil. Care este diferenţa dintre „Name” și „StringName” sau „NameString”? Nu este nicio diferenţă în final. Un nume precum „CarName” ar fi mai util. Același lucru este valabil și pentru denumirea metodei, a propri-etăţilor sau a clasei.
Utilizaţi nume uşor de pronunţatChiar 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ă.
Folosiţi nume care pot fi căutateSună 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 aplicaţie poate fi un coșmar dacă aceeași valoare a fost utilizată în linie pentru cazuri de utilizare diferite.
Evitaţi codificareaNu încerca să reinventezi roata și să-ţi definești propria
codificare pentru lucruri care au fost deja definite și standardi-zate. Ultimul lucru pe care dorești să îl ai este propriul tău limbaj personalizat.
De aceea, încearcă să folosești prefixe precum „I” pentru inter-feţe sau sufixul „Base” pentru clase abstracte. Nu folosi prefixul „C” pentru implementarea claselor sau „m_” pentru variabile.
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 de acest răspuns, ar trebui să iei o hotărâre.
Evitaţi hărţile mintaleSă începem cu un exemplu: r t pChiar dacă suntem dezvoltatori, nu dorim să învăţăm și
să memorăm că „r” înseamnă întregul url al Dacia server din 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 la server pentru a putea să ne logăm.
Chiar dacă hărţile mintale nu sunt benefice, există câteva
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 MetodelorExistă două reguli simple care ne pot ajuta mult atunci când
trebuie să găsim un nume bun pentru clasa noastră sau pentru metode:
• Un nume de clasă ar trebui să conţină un substantiv sau o expresie substantivală.
• Un nume de metodă ar trebui să conţină un verb sau o expresie verbală.
Încercaţi să evitaţi denumirea claselor cu prefixe sau sufixe precum „Service”, „Factory”, „Processor”, „Data”, „Info”. Aceste denumiri de clase sunt întrebuinţate prea mult (mai ales când nu găsim denumiri mai bune).
Alegeţi un cuvânt per conceptUn 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 dezvolta-tori să înţeleagă codul mai ușor.
Utilizaţi denumiri din numele domeniu Soluţie şi Problemă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.
Nu adăugaţi context nejustificatEste destul de ușor să adaugi context lucrurilor care sunt deja
clare. De exemplu, într-o clasă denumită „Car”, nu este nevoie să numești câmpul culoare al clasei „carColor” sau „colorCar”. Ești deja în clasa mașină și toate informaţiile din această clasă sunt legate de „Car (Mașină)”.
ConcluzieGăsirea denumirilor bune într-o aplicaţie poate fi o treabă difi-
cilă și care necesită mult timp. Nu este simplu să găsești denumiri bune. Dar ar trebui să investiţi timp pentru a găsi și utiliza denu-miri potrivite.
Cuvinte de încheiereDiferenţa dintre un programator deștept și unul profesionist
este că profesionistul înţelege importanţa clarităţii. Profesioniștii îşi folosesc abilităţile pentru a scrie cod care poate fi înţeles de către alţii.
Majoritatea 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 PhoenixUnul 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 dimen-siuni 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 ver-siune 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ă.
Î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 suc-cesor la TYPO3 versiunea 4. TYPO3 v4 a continuat să fie dezvoltat până astăzi la versiunea 6.x.
Soluția: TYPO3 NeosTYPO3 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 edi-tori. 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ă experi-enţ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
î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 dimensi-ons. 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 enti-tăţi. Pentru ca totul să funcționeze armonios, avem următoarele componente:
Componente backend din panoul de adminstrare
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
33www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINE
FlowQuery, trebuie să existe un pachet instalat care implemen-tează acea operație. Oricare pachet poate să adauge propriile operații FlowQuery. Un set de bază de operații este disponbil tot timpul fiind parte din pachetul TYPO3.Eel.
Componente frontend din panoul de adminstrare
EmberJS - JavaScript Web Application FrameworkCreate.js - Web Editing InterfaceAloha / Hallo - HTML5 WYSIWYG EditorVIE = viejs.org - Semantic Interaction FrameworkRequireJS - JavaScript file and module loader
Instalare
Cerințe sistem• server web (Apache sau nginx, IIS și altele, însă netestate
magic_quotes_gpc = off• funcțiile PHP system(), shell_exec(), escapeshellcmd() și
escapeshellarg() să fie active• o bază de date care suportă Doctrine DBAL• virtual hosts pentru dezvoltarea locală:
NameVirtualHost *:80<VirtualHost *:80> DocumentRoot „/your/htdocs/TYPO3-Neos-1.1/Web/” SetEnv FLOW_CONTEXT Production ServerName neos.demo</VirtualHost>
Instalare din arhivă1. Descarcă arhivă via http://neos.typo3.org/download.html2. Extrage arhiva în folderului web dorit.3. Continuă cu Setup, accesând www.domain.local/setup4. Urmează instrucţiunile.
Instalare cu Composer1. Instalare composer (dacă lipsește): curl -s https://getcomposer.
org/installer | php2. Rulează comanda în folderu de instalare: php /path/to/com-
3. Continuă cu Setup, accesând www.domain.local/setup4. Urmează instrucţiunile.
TYPO3 Neos Panou de admistrareAsigură o editare simplă a conținului, on the fly:• Operații simple (eg. Aloha editor),• Perioadă scurtă de învățare,• Nu e necesară o sesiune de training pentru editorii noi,• Folosire intuitivă.
Editorii nu trebuie să treacă prin sesiuni lungi de training pen-tru 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.
Se poate opta între folosirea In-Place editing, după cum îi spune și numele, editare direct în design sau Raw content editing care înlătură toate elementele de design și permite editorului să se axeze exclusiv pe conținut.
Modulul Raw Content permite de asemenea refolosirea conținutului în mai multe canale de distribuție a conținutului fără a ține cont de template-ul folosit. În schimb, editorii se pot con-centra astfel pe cuvintele folosite și ce formate media vor fi folosite.
Modulul Preview Central este locul unde se poate simula pagina web în timp real cu conținut proaspăt adăugat înainte ca acesta să fie disponibil pentru publicul larg. Aici editorii pot con-sulta, spre exemplu, trei formate diferite de prezentare a paginii web - desktop, mobile, tabletă, etc. sau simulări personalizate, de exemplu cum ar arată o pagină indexată în Google Index.
ConcluzieTYPO3 Neos este deocamdată un produs tânăr și nou pe piața
sistemelor de administrare de conținut. Chiar dacă constatăm că îi lipsesc câteva caracteristice importante precum traducerea de conținut, suport pentru mai multe domenii web sau o documenta-ţie completă pentru dezvoltatorii web, acesta are un potențial uriaș și, mai ales clienții par să fie îndrăgostiți la prima vedere de el.
Însă versiunea 1.2 promite să acopere majoritatea problemelor. Introducerea completă a content dimensions va fi face din TYPO3 Neos primul sistem de administrare de conținut unic în ceea ce privește administrarea de conținut cu dimensiuni multiple.
TYPO3 Neos este momentan folosit într-o varietate mare de proiecte datorită timpului mic de acomodare e editorilor și a ver-satilităţi extraordinare arhitecturii care se mulează pe orice tip de proiect, domeniu! Mai multe detalii: http://neos.typo3.org
Î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 promo-vare 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, favo-rizează 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 suc-cesiunea 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.
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 ori-zontală î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 rigu-ros care să includă evaluări psihometrice și centre de evaluare pot provoca frustrări în interiorul unei echipe.
programareHR
35www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINEprogramare 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 compa-nie sunt cerute, promovarea internă nu este de calitate și nu se justifică.
8. Multe sisteme de promovare internă sunt bazate pe seni-oritate, 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 desta-biliza 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 dez-voltare 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 perso-nal pentru a promova din interior.
13. Promovarea celui mai experimentat sau cu cele mai multe abilități, nu înseamnă reușita acestuia. Abilitățile nece-sare 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 pro-vocă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, compa-niile 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 inter-viurilor 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.
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.
Imaginaţ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 preo-cupare 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 cunos-tinţ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:
Figura. 1. Cadrul analizei de business
Avansând în domeniul analizei de business și acumulând experiență pe câteva proiecte, consider că analistul de business tre-buie să își poată defini cadrul specific pe proiectul pe care lucrează, fie el mic sau mare, waterfall sau agile.
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 anu-
mite 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 2. Paşi de parcurs
În paralel şi/sau adiacent cu parcurgerea acestor pași, se vor alătura și elementele ce alcătuiesc cadrul de analiză, pe care le voi descrie în linii mari în cele ce urmează.
Cadrul analizei de business (I)
management
37www.todaysoftmag.ro | nr. 26/august, 2014
TODAY SOFTWARE MAGAZINEprogramare
Elementele din cadrul analizei de business
Activităţile de BACele 4 activităţi importante care se regăsesc în majoritatea pro-
iectelor sunt prezentate în imaginea de mai jos:
Setul de documente scriseAcestea se folosesc în timpul activităţilor de analiză de busi-
ness ș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).
Modelare vizuală cerinţelorFolosesc 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.
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 con-trol, finalizare:
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ă. Bineînţeles, sunt mai multe elemente care pot fi folosite în cre-
area 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 [email protected].
Î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.
Î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 software-ul nou dezvoltat cât și pentru software-ul opensource adoptat în pachetul de revizu-ire 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 openso-urce ș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 comunica-rea reparațiilor sau modificării codului către responsabilii cu întreținerea, înainte ca software-ul să fie expediat. Acest pro-ces 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 anteri-oară 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 componen-tele proprii.
Security Researcher, Software and Services Group@Intel USA
39www.todaysoftmag.ro | nr. 26/august, 2014
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 propusChiar 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 alarme-lor 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 nece-sita 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 pro-bleme 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 rezulta-telor 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 comple-xitate 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 îngus-tarea 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ă distin-gem 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 pro-iectului, 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 larmelor fa lse, invest igarea natu-rii 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ă instru-mentul 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, instrumen-tul are dreptate, dar fie dezvoltatorul nu înțelege de ce este o problemă, fie nu este atât de interesat de acea problemă parti-culară. 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 interio-rul organizației, pentru mai mulți dezvoltatori seniori și/sau educație și training.
ConcluziiSoftware-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ă proiec-tele 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 com-panii 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),
40 nr. 26/august, 2014 | www.todaysoftmag.ro
programareSecurizarea 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 des-tul 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 corectitudi-nea. Chiar dacă se impune o investigare detaliată suplimentară pentru a stabili exploatabilitatea acestor defecte în peri-oada de rulare, de exemplu prin fuzzing (4) sau prin Testarea Aleatorie Automatizată Direcționată (DART) (19), analiza noastră demonstrează fără nicio îndoială că aplica-rea 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 avanta-jul de a le corecta mult mai rapid și eficient.
Comercianților de software care încor-porează 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 con-trast 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 par-tea 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ță, securiza-rea 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 nece-sar produsului, în procesul de validare software general și să se realizeze o revizu-ire 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ă open-source, dezvoltatorul ar descărca un binar și l-ar include direct în build, sau ar des-că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 milestone-urile 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ă cos-tisitoare 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
valoarea acestui efort.
MulțumiriAutorul 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.
41www.todaysoftmag.ro | nr. 26/august, 2014
testaretestare
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ă dife-
rite 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.
Domeniul testării software nu este foarte diferit de cel al dezvoltării, dar spre deose-bire 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 probleme-lor 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 concep-tele î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 speci-alizeze ș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 spe-cializeze 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 priori-tizarea eficientă, abilitățile de comunicare,
BBST Un curs practic despre Testare Softwaretestare
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
În condițiile în care prestatorii de servi-cii 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, activita-tea 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 per-spectiva și să ne îndreptăm spre un model în care valoarea adusă de serviciile de tes-tare este cea care contează în primul rând. Ca testeri, vrem să fim primii care ne îndreptăm în această direcție și să demon-stră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 cu un certificat în loc de dezvoltarea unor abilități.
Pentru a deveni niște testeri cu adevărat buni, e nevoie de exercițiu, de practică, de exemple din contexte diferite și de feed-back din partea unor oameni care au o experiență vastă.
Alternativa practicăDin fericire, cursurile ISTQB nu mai
sunt singura opțiune. Cursurile BBST® oferă o alternativă practică fiecărui tester care vrea să își îmbunătățească abilitățile necesare în testare.
BBST® este un acronim relativ nou în România în domeniul cursurilor de testare software, dar care s-a dezvoltat semnificativ în ultimii ani, după ce numeroși absolvenți BBST® au descris importanța acestor cur-suri și au vorbit despre influența și ajutorul pe care materialele BBST® le-au adus în mod direct și practic în munca lor de zi cu zi.
BBST® (sau Black Box Software Testing) reprezintă o serie de cursuri de testare
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 fap-tul că în contexte diferite se aplică practici diferite. De-a lungul seriei, testarea este pre-zentată 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ă proce-dură”, 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”.
Seria de cursuri BBST®La momentul actual, seria de cursuri
BBST® include patru cursuri:• BBST® Foundations - primul curs
din serie, axat pe conceptele de bază în testarea software. Studenții lucrează și aprofundează conceptele de strategie de testare, misiunea testării, test coverage, și încearcă să lucreze cu problemele cele mai grele din testare:
• Cum știm dacă un program a tre-cut sau nu un test?
• Când ne oprim din testat?• Cum hotărâm că am acoperit
produsul îndeajuns de bine? • Cum măsurăm testarea și calita-
tea testării pe care am făcut-o? • BBST® Bug Advocacy - un curs
axat pe una dintre cele mai importante sarcini pentru un tester: găsirea și rapor-tarea defectelor și problemelor software, punerea accentului pe importanța lor din punctul de vedere al utilizatorului final, izolarea unei probleme, adăugarea de informații suplimentare. Studenții vor lucra cu un produs software open-source,
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 intro-ductiv în diferitele tehnici de design de teste, cu accent pe câteva dintre cele mai uzuale. Studenții învață să aplice anu-mite 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ă pen-tru contextul în care lucrează.
• BBST® Domain Testing - un curs extrem de practic care aprofundează una dintre cele mai cunoscute tehnici de tes-tare: 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 onlineCursurile BBST® sunt organizate online.
Dacă vă imaginați ceva similar cu o sesi-une 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 facili-tează 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 slide-
uri 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 într-un 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
43www.todaysoftmag.ro | nr. 26/august, 2014
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ă diver-sitate 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 examenu-lui, studenții primesc feedback fie într-o discuție pe Skype cu unul dintre instruc-tori, 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ăs-punsurilor 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 con-ceptelor 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 istoricMaterialele din cursurile BBST® au fost
dezvoltate ca parte dintr-un studiu de cer-cetare 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 prezen-tate în curs este Cem Kaner (http://kaner.com) - “Profesor de Inginerie Software” la Institutul de Tehnologie din Florida și co-autorul 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 cursu-rile 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 docto-rat în educație de la Universitatea Centrală din Florida.
De ce BBST®? Vorbind despre cum putem să ne dez-
voltă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
așa cum e testarea software, e greu să găsim ocaziile de a exersa o tehnică în cadrul pro-iectelor 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 men-tori 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.
Î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 provo-că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 acti-vitatea “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, invi-tâ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.
Important de reținutExistă 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 pro-prii) 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. .
În finalDe 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 con-tracte 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.
Folosirea serviciilor de tip cloud nu e
lipsită de riscuri juridice
Cloud 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.
Claudia este specializată pe aspecte juridice ce implică mediul online, comerțul elec-tronic și IT&C, protecția datelor cu caracter personal și proprietatea intelectuală.
