TO DAY SOFTWARE No. 18 • Decembrie 2013 • www.todaysoftmag.ro • www.todaysoftmag.com MAGAZINE Ediție specială Interviu cu domnul primar Emil Boc Păstrarea angajaţilor talentaţi, o temă recurentă în IT Cum sa menţii succesul unui joc la peste 2 ani de la lansare? Extension Points Alinierea partiţiilor în medii virtuale How To Web 2013 Inovaţie şi Antreprenoriat la IT Days în Cluj-Napoca Gestionarea Autentificării în AngularJS Scrum în practică: un studiu de caz Real time web with Meteor Îmbunătăţirea continuă – o practică de luat în serios Testarea funcţională în PHP
Transcript
TSM T O D A YS O F T WA R E
No. 18 • Decembrie 2013 • www.todaysoftmag.ro • www.todaysoftmag.com
M AG A Z I N E
Ediție specială
Interviu cu domnul primar Emil Boc
Păstrarea angajaţilor talentaţi, o temă recurentă în IT
Cum sa menţii succesul unui joc la peste 2 ani de la lansare?
Extension Points
Alinierea partiţiilor în medii virtuale
How To Web 2013
Inovaţie şi Antreprenoriat la IT Days în Cluj-Napoca
Gestionarea Autentificării în AngularJS
Scrum în practică: un studiu de caz
Real time web with Meteor
Îmbunătăţirea continuă – o practică de luat în serios
Testarea funcţională în PHP
6IT Days
2013Ovidiu Mățan
8How to Web 2013 a reunit
comunitatea tech din Europa de Sud Est
Irina Scarlat
10Interviu cu domnul
primar Emil BocOvidiu Mățan
13Testarea funcțională în PHP
Bogdan Matei
17Gestionarea
autentificării în AngularJSLeonard Abu-Saa
19Specificații executabile
Alexandru Bolboaca și Adrian Bolboacă
21Îmbunătățirea Continuă –
o practică de luat în seriosOvidiu Dolha
24Alinierea partițiilor
în medii virtualeDragoș Masarasan
27Extension Points
Radu Vunvulea
30Scrum în practică: un studiu de cazPapp László
34Ecosistemul startup-urilordin ClujMircea Vădan și Marius Mornea
38
SpotTuneGeorge Platon
39CTF365Marius Corîci
41Cum să menţii succesul unui joc mai mult de doi anide la lansare?George Abramovici
43Păstrarea angajaţilor talentaţi, o temă recurentă în ITMonica Soare
45Real time web with MeteorAndrei Cacio
47 Cum pot fi protejate afacerile cu aplicații mobile? Claudia Jelea
49Interviu cu Richard Campbell (II) Attila-Mihaly Balazs
4 nr. 18/Decembrie | www.todaysoftmag.ro
Startup-urile, un subiect la modă, față de care companiile manifestă un interes cres-cut, dorind să se implice în apariția noilor produse. Riscurile sunt mari pentru ambele părți, dar recompensa ce poate apărea în câțiva ani este o fata morgana care
devine realitate. La How To Web 2013, unde am participat de curând, unul dintre spea-kerii intervievați a atras atenția asupra faptului că există un număr mare de startup-uri care aduc pe piață produse mult prea facile, creând de fapt doar o interfață grafică peste o simplă bază date. Dar ultimele produse create de startup-uri sunt foarte încurajatoare, demonstrând multă creativitate. Un exemplu sugestiv în acest sens este chiar produsul startup-ului castigator al ediției How To Web din acest an: o mână complet robotizată, low cost, pentru persoanele cu dizabilități. De asemenea, în același sens, trebuie să-l menționăm pe Ionuț Budișteanu, cel care a câștigat marele premiul al competiției Intel ISEF cu un proiect de automobil autonom. Exemplele acestea sunt dovada că trebuie să îndrăznim mai mult, că trebuie să abordăm interdisciplinar realitatea, valorificându-i conexiunile ascunse. Dacă până acum era suficient să ai o echipă de programatori, acum a venit momentul în care trebuie să existe cel puțin un electronist sau poate chiar un spe-cialist în robotică în echipă. Oare cum s-ar mai putea îmbunătăți mediul domestic, cu tot confortul pe care îl deținem deja? Aceasta poate să nu fie o întrebare retorică.Gândiți-vă că acasă avem telefoane, tablete, calculatoare care pot simula și accesa aproape orice din perspectiva unui uz caznic. Evoluția lor implică adăugarea de noi senzori, putere de pro-cesare, durată de viață a bateriei și conectivitate. Nimic nou sau spectaculos. Alternativ, uitați-vă în jur și numărați câți roboți aveți în jurul vostru prin casă? Poate un Roomba, destul de prostuț de altfel. Nu avem o platformă mobilă larg răspândită pe care să poată fi instalate diferite brațe, senzori și care să ne facă viața de zi de zi mai ușoară. La fel avem și dronele, au devenit în ultimul timp destul de accesibile, iar în curând vom asista la o evoluție exponențială a numărului acestora. Din păcate sau poate din fericire pentru noi, toate sunt controlate prin telecomandă,iar partea de autonomie și AI nu și-a făcut simțită prezența serios. Sper așadar că v-am ridicat un semn de întrebare înainte de a decide să lucrați pentru următoarele șase luni la o aplicație care îți arată pe hartă cea mai apropiată benzinărie sau ordonează task-urile în funcție de priorități.
Continuăm această pledoarie pentru inovație și în cadrul evenimentului IT Days, eveniment organizat de revista TSM. Sperăm că evenimentul va oferi reprezentanților comunității clujene de IT ocazia concretizării unei abordări originale și creative, care să se transforme într-un reper al activității lor. Participanții vor asista din punct de vedere al tematicilor abordate la o îmbinare a subiectelor tehnice cu prezentările de startup-uri locale, precum și cu prezentări ale proiectelor de cercetare. Pentru a afla mai multe, vă invităm să citiți primul articol al acestei ediții speciale a Today Software Magazine.
Eduardo Mendez Polo, head of IT Cloud la Telefonica Spain care va vorbi des-pre evoluția serviciilor cloud în viitor
Tine Thygesen , CEO Everplaces Danemarca, susține o prezentare des-pre inovație și startup-uri având tema Disruptive technologies.
Voicu Oprean, CEO Arobs, are ca temă de prezentare tranziția de la outsourcing la produs.
Maria Diaconu, CEO Mozaic Works, va prezenta modul în care poate fi crescuta
inovația în cadrul echipelor de dezvol-tare de produselor.
Mirel Borodi, director general al Trustului de Consultanță Transilvănean, fondator www.multifinantare.ro, va pre-zenta inițiativa de crowd sourcing adresată comunității locale.
Șerban Țîr, director tehnic al grupu-lui de firme Gemini Solutions prezintă o abordare practică pentru suportul startup-urilor locale.
Deschiderea evenimentului o va realiza reprezentatul administrației locale, domnul primar Emil Boc, care a acceptat invitația noastra, manifestând astfel susținerea acestui eveniment cu implicații pozitive în dezvoltarea orașului nostru. Acestuia îi va urma Alexandru Tulai, președintele Cluj IT Cluster, organizația ce reunește un număr mare de companii de IT clujene.
Gazda evenimentului este Dan Mircea Suciu, lector doctor la Facultatea de Matematică ș i Informatică din Universitatea Babes Balyai și Director of engineering la compania 3Pillar Global.
Subiectele tehnice vor fi susținute de experți locali și vor acoperi o arie largă din domeniul IT: începând cu arhitectura siste-melor, programare, testare, tehnologii SAP, direcții de cercetare, project management și terminând cu design-ul adaptiv și securita-tea aplicațiilor web.
Evenimentul este susținut de impor-tante companii de IT din Cluj: EBS, Arobs, Endava, Evoline, Accesa, Gemini Foundry, Skobbler, Yardi, msg systems Romania, 3Pillar Global. Detaliile complete despre eveniment se găsesc online pe www.itdays.ro.
Vom reveni în numerele următoare cu înregistrările complete și cu multe informații de la aceasta primă ediție a IT Days.
Revista online clujeană Today Software Magazine organizează în 5-6 Decembrie 2013, la Cluj Arena, evenimentul IT Days. În cadrul conferinţei sunt invitaţi atât speakeri internaţionali cât și reprezentanţi din industria software locală. În prima zi, se abordează teme precum inovaţia și tehnologia în IT , pentru ca în cea de-a doua zi, tema principală să fie antreprenoriatul .
IT Days 2013
7www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE business
8 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
evenimente
How to Web 2013 a reunit comunitatea tech din Europa de Sud Est startups
Prezentările How to Web 2013 s-au desfășurat în paralel pe două scene. Astfel, pe scena principală a evenimentului, Grow Stage, au avut loc prezentări ale profesio-niștilor din domeniul tehnologiei la nivel mondial. Acestea s-au adresat dezvoltato-rilor, designerilor și comunităţilor din jurul produselor tech și au adus în discuţie ino-vaţia în tehnologie, dezvoltarea echipelor durabile, tendinţele actuale în industrie sau importanţa design-ului pentru dezvoltarea produselor inovative.
Conferinţa a fost deschisă de Thomas Hartwig (Co-Fondator și CTO King.com), care a vorbit despre avantajele și provocă-rile aduse de creșterea accelerată a unui startup (de la 1 la peste 100 de milioane de utilizatori în cazul specific al King) și a continuat cu prezentarea lui Mike Butcher (Senior Editor TechCrunch), care a vorbit despre cei mai puternici oameni în tehno-logie la nivel european.
O altă secţiune a fost dedicată lecţii-lor învăţate lucrând la distanţă cu echipe de cercetare-dezvoltare, subiect care a fost dezvoltat în cadrul unui panel moderat de Philipp Kandal (Co-Fondator și CTO Skobbler), din care au făcut parte Marius Jumolea (General Manager al centrului R&D Visual.ly Romania) și Michael Levit (Fondator Spigot).
Cea de a doua zi a conferinţei a început cu prezentarea lui Robin Wauters, jurnalist în tehnologie, care a vorbit despre tendinţele din industrie și modul în care companiile mici din Europa inovează și se menţin cu un pas înaintea celorlalte. Evenimentul a continuat cu o discuţie cu Radu Georgescu,
Fondator Avangate, care a vorbit despre deciziile strategice pe care le-a luat în dezvoltarea compa-niei, de la idee până la exit.
D a v i d B i z e r ( C E O T a l e n t Fountain), a prezen-tat lecţiile învăţate din lansarea, dezvol-tarea și închiderea HackFwd, iar instru-mentele adresate dezvoltatorilor au fost aduse în discuţie de Martyn Davies (Developer Evangelist SendGrid), Jamie Hannaford (Software Developer Rackspace) și Michal Wawra (Developer Evangelist Twilio), în cadrul unui panel moderat de Ivan Brezak Brkan (Netocratica). Christopher Martin (Senior Manager Bosch) a abordat dificultăţile dezvoltării unui produs tech de calitate, iar Vitaly Golomb (Fondator și CEO Keen Systems) a prezentat motivele pentru care nimic nu este mai important decât design-ul unui produs.
Pe parcursul celor două zile ale eveni-mentului, pe scena principală a How to Web au urcat profesioniști importanţi ai indus-triei printre care se numără Paul Ford (CIO Softlayer), Alex Hunter (CEO Rushmore.fm), Philipp Kandal (Co-Fondator și CTO Skobbler), Marco Cecconi (Software Engineer Stack Exchange), Simon Stewart (Software Engineer, Facebook), Matt Clayton (Co-Fondator și CTO Mixcloud)
sau Ştefan Szakal (Fondator X3 și [e-spres-oh]).
Ignite Stage, cea de a doua scenă a con-ferinţei, a găzduit paneluri care au abordate subiecte specifice startup-urilor: bune practici pentru un startup care trece printr-un program de accelerare; cum să dezvolţi echipa potrivită; cum să atragi investi-ţii; cum să colaborezi cu și să înveţi de la mentori, investitori și clienţi; greșeli frec-vente pe care le fac fondatorii. Acestea au fost abordate de cei peste 25 de investitori, reprezentanţi ai acceleratoarelor și fondu-rilor de investiţii prezenţi la eveniment. Adresată tuturor celor care își dezvoltă propriul startup sau care se pregătesc de acest pas, scena Ignite a avut drept princi-pali beneficiari cele 32 de echipe finaliste ale programului Startup Spotlight.
Echipele au fost evaluate de un juriu de specialitate care a urmărit criterii precum echipa și experienţa acesteia, dimensiu-nea pieţei, scalabilitatea, tracţiunea, sau
București, 25 noiembrie 2013 – Săptămâna trecuta How to Web a transformat pentru a patra oară consecutiv Bucureștiul în capitala tehnologiei din Europa de Sud-Est. Desfășurat în jurul conceptului central „Să creștem împreună”, How to Web 2013 a adus în faţa celor peste 800 de persoane din audienţă mai bine de 40 de vorbitori internaţionali de calibru de pe 4 continente
care au abordat teme precum dezvoltarea de produse inovative la scară globală, valorificarea contextului local sau tehnologiile viitoru-lui. În paralel a avut loc Startup Spotlight, competiţie și program de mentorat adresat celor mai performante 32 de echipe din regiune.
9www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
fezabilitatea produselor dezvoltate. Smart Hand, startup din Bulgaria care dezvoltă o mână prostetică mioelectrică pentru persoanele cu dizabilităţi, a fost desemnat câștigătorul competiţiei Startup Spotlight. Echipa clasată pe locul II a fost Synetiq, aplicaţie care oferă companiilor informaţii utile despre clienţii acestora, iar Wyliodrin, startup care propune o metodă simplă de dezvoltare web pentru servicii încorporate, a primit IXIA Innovation Award. Premiul pentru cea mai bună prezentare a fost acor-dat echipei de la Data Maid, instrument pentru crearea și publicarea de conţinut media bogat. Finaliștii competiţiei au pri-mit premii în valoare totală de 20.000 USD oferite de IXIA, partener principal al How to Web Startup Spotlight.
Pe lângă premiile în bani, echipele finaliste au primit și alte premii valoroase oferite de partenerii programului: acces la platforma Microsoft Azure, infrastructură gratuită și mentorat în cadrul programului pentru startup-uri Software Catalyst, office hours cu Jon Bradford (Managing Director al programului de accelerare TechStars), 3 ore de consiliere juridică oferite de Biriș Goran, posibilitatea de a-și prezenta pro-dusele în cadrul Startup Bootcamp, acces la workshop-ul Hub:raum din Cracovia,
posibilitatea de a participa la un eveniment S e e d c a m p , infrastructură c loud ofer i t ă de Rackspace, c o n t u r i p r e -mium Evernote, pro du s e o fe -rite de F6S și a c c e s d i r e c t l a R o m a n i a n I n n o v a t i o n
Commercialization Program (RICAP).„Am început How to Web cu o primă
ediţie în 2009, în Politehnica București, și l-am continuat cu o primă ediţie inter-naţională în 2010. An de an, How to Web a crescut ca număr de participanţi dar, și mai important, s-a maturizat din punct de vedere al structurii agendei și al obiectivelor pe care și le propune. How to Web nu a fost niciodată doar o con-ferinţă – ne-am dorit mereu să-l facem un instrument util, practic, cu rezultate măsurabile pentru cei care îi trec pragul. Ne bucurăm că am reușit să ne atingem obiectivele și de această dată, iar lista de povești de succes confirmă acest lucru”, a declarat Bogdan Iordache, Co-Fondator și CEO How to Web.
How to Web 2013 a fost dezvol-tat cu sprijinul IXIA, X3, Bitdefender, CyberGhost, SoftLayer, Enterprise Ireland, Avangate, Microsoft, Hubraum, PayMill, Twilio, Biris Goran și Banca Comercială Română și a avut loc pe 20 și 21 noiembrie la Crystal Pallace Ballrooms în București.
Mediatizarea evenimentului a fost asigurată de parterii media prin-cipali Prove PR, Digi TV, Adevărul, Forbes România, Capital, Wall-Street.ro,
Evenimentul Zilei, DAS Cloud, Revista Cariere, C t r l - D , s t a r t u p s .ro și Entrepreneur.bg, si de partenerii media Economy.bg, Newtrend.bg, Digjitale, IT Dogadjaj i , CEE Startups, Invendor.hu, Goal Europe, Times New Roman, Akcees, IQ Ads, C omputer World , PC World , Agora , IT Trends ,
Business Cover, Tech Cover, Business Woman, Gadget & Trends, Comunicaţii mobile, Market Watch, Business Review, Manager Express, România Liberă, Comunicatedepresă.ro, Zelist, Ejobs, Softlead, Ziare.com, Business24, Romanian Startups și Today Software Magazine.
Industria de IT locală este în continuă creștere, spuneți-ne cum sprijină Primăria Cluj-Napoca acest domeniu?
În această perioadă lucrăm la defi-nitivarea Strategiei Municipiului pentru 2014-2020, iar industria IT este o compo-nentă esențială a procesului. Am urmărit să implicăm în proces specialiști din întreaga comunitate, pe fiecare componentă, de la educație la antreprenoriat și inovație. Corelarea studiilor preuniversitare și uni-versitare cu cerințele pieței este doar un aspect care va avea un impact semnificativ în dezvoltarea industriei. Cei interesați pot afla mai multe despre direcțiile principale ale strategiei pe site-ul cmpg.ro.
Cluj-Napoca s-a definit în ultimii ani ca un oraș al serviciilor și se poziționează din ce în ce mai puternic pe harta Europei ca un centru cultural și ca un centru al inovaţiei. Am încredere că, având strate-gia potrivită și sprijinul comunității, vom depăși Bucureștiul în mai multe domenii, în primul rând în IT. Orașul nostru are potențialul de a fi cu adevărat un „smart city” al Europei, iar la Primăria Cluj-Napoca, având acest obiectiv, urmărim
să implementăm soluții „smart”, etapizat, pe fiecare direcție - de la transport în comun la plata taxelor și impozitelor. Avem totodată pro-iecte majore, menționez aici Cluj Innovation City, pe care le spriji-nim cu toată convingerea, lucrând alături de reprezentanții industriei pentru a găsi cele mai bune soluții pentru ca aceste proiecte să devină realitate.
Credem că mulți programa-tori ar fi interesați să scrie aplicații bazate pe o platformă care le-ar putea da acces la informații în timp real. Ne referim la datele de trafic, poziția sau timpul estimat de a ajunge în stație a mijloacelor de transport în comun, nivelul de poluare etc. . Astfel s-ar crea cu un efort minim posibilitatea de a dezvolta aplicații folositoare pentru clujeni prin intermediul direct al programatorilor locali. Credeți că este posibil în viitor acest lucru ?
Suntem deschiși la orice inițiativă care ar putea îmbunățăți viața de zi cu zi a cetățenilor și procesele de lucru ale instituției, ceea ce, până la urmă, va fi
tot spre beneficiul fiecărui clujean. Sunt aspecte în care am primit deja propuneri prin intermediul grupurilor care elabo-rează Strategia Municipiului. Sunt mai multe domenii în care s-ar putea începe chiar acum dezvoltarea de aplicații și m-ar bucura ca ideile și punerea lor în practică să vină de la comunitate. Îi invit așadar pe toți cei interesați să ne contacteze, pentru că Serviciul Strategii de informatizare al Primăriei vă stă la dispoziție.
Clujul este un oraș cu mulți vizita-tori, aveți în considerarea crearea unei rețele wireless gratuită la nivelul centrului orașului? Știm că există ceva asemănător în Parcul Mare, iar aceasta poate crea un
Domnul primar Emil Boc a avut amabilitatea să ne răspundă la câteva întrebări referitoare la susținerea IT-ului clujean, modul în care comunitatea locală a programatorilor se poate implica și proiectul de susținere a startup-urilor locale
Interviu cu domnul primar Emil BocCluj - centru al inovației
11www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
impact pozitiv în special pentru cei vizitatorii străini.Într-adevăr, există o rețea wireless funcțională, însă am fost
precauți în ceea ce privește extinderea ei, în principal din motive de securitate. Cluj-Napoca va fi Capitală Europeană a Tineretului în anul 2015 și candidăm pentru titlul de Capitală Culturală Europeană. Astfel că ne așteptăm la o creștere semnificativă a numărului de vizitatori și ne pregătim în acest sens. Avem însă o responsabilitate majoră ca municipalitate de a asigura securitatea și confidențialitatea datelor, o problemă dacă vorbim în special de rețele publice cu acces gratuit. Vom discuta cu experți din dome-niu și vom vedea care sunt cele mai bune soluții.
Există proiecte în care Primăria Cluj are nevoie de voluntari IT ?Da, Primăria Cluj-Napoca este într-un proces de informati-
zare a activității - avem deja rezultate încurajatoare, avem nevoie de sprijin, astfel că m-aș bucura să avem tinerii care activează în industria IT clujeană implicați alături de noi în implementarea acestor schimbări. Recomand tinerilor interesați să ne dea un e-mail pe adresa serviciului specializat - [email protected] - în urma căruia vor primi mai multe informații.
Știm că este în derulare în zona Lombului un proiect pentru suportul startup-urilor locale. Ne puteți spune mai multe cuvinte despre acesta?
Centrul pentru Industrii Creative va oferi companiilor oportu-nitatea de a-și desfășura activitatea într-o structură unică la nivel regional datorită complexităţii și diversităţii facilităţilor și servici-ilor. Centrul va oferi servicii integrate pentru afaceri, servicii de asistenţă gratuită (tip help desk) oferite de personalul structurii de sprijinire a afacerilor în următoarele domenii: consultanţă și ser-vicii IT, consultanţă juridică, în marketing și vânzări. Proiectarea întregii structuri este una dinamică, fiind creată pe o bază parti-cipativă, răspunzând astfel nevoilor reale ale potenţialilor clienţi, în termeni de amplasare, funcţiuni, suprafeţe, servicii, parcări, dotare și echipare. Avem în vedere producerea unui efect de clus-ter care va permite creșterea competitivităţii companiilor găzduite prin schimbul de informaţii, facilitarea parteneriatelor de afaceri, economiile realizate prin utilizarea în comun a unor spaţii și echi-pamente. Centrul vine în sprijinul necesităţii firmelor de a fi la curent cu ultimele evoluţii tehnologice, prin crearea unui corp consultativ alcătuit inclusiv din reprezentanți ai mediului acade-mic. Aceștia vor putea comunica cu reprezentanții firmelor care activează în domeniul industriilor creative, în funcţie de specificul fiecărei companii.
Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 550 / Nr. Evenimente: 43
Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Website: www.facebook.com/todaysoftmagData înfiinţării: 06.02.2012 / Nr. Membri: 1029 /Nr. Evenimente: 15
Romanian Testing CommunityComunitate dedicata testerilor.Website: www.romaniatesting.roData înfiinţării: 10.05.2011 / Nr. Membri: 672 / Nr. Evenimente: 2
GeekMeet RomâniaComunitate dedicată tehnologiilor web.Website: geekmeet.roData înfiinţării: 10.06.2006 / Nr. Membri: 567 / Nr. Evenimente: 17
Cluj.rbComunitate dedicată tehnologiilor Ruby.Website: www.meetup.com/cluj-rbData înfiinţării: 25.08.2010 / Nr. Membri: 151 / Nr. Evenimente: 36
The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 330 / Nr. Evenimente: 40
Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 152/ Nr. Evenimente: 23
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: 230/ 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: tabaradetestare.roData înfiinţării: 15.01.2012 / Nr. Membri: 356/ Nr. Evenimente: 20
Decembrie vine cu surprinzător de multe evenimente înainte de sărbătorile de iarnă. Vă invităm sa participați la ele iar reco-mandarea noastră este IT Days pentru cei din Transilvania și nu numai.
Calendar Decembrie 4 (Cluj)Lansarea numărului 18 al Today Software Magazinewww.todaysoftmag.ro
Decembrie 4 (Cluj)An introduction to web application security with Simon Bennettsw w w . m e e t u p . c o m / Ta b a r a - d e - Te s t a r e - C l u j /events/152638932/
Decembrie 5-6 (Cluj)IT Days - recomandarea TSMwww.itdays.ro
Decembrie 7 (Cluj)Android Workshop 1it-events.ro/events/android-workshop-1/
Decembrie 7-8 (Iași)Winter Web Workshopit-events.ro/events/winter-web-workshop/
Decembrie 10 (Cluj)UI/UX Cluj Meetup #2www.meetup.com/UXUICluj/events/150664862/
Decembrie 10 (Cluj)How to make smartphone hits with Bart Decrem, Senior VP @ Walt Disneyit-events.ro/events/make-smartphone-hits-bart-decrem-senior-vp-walt-disney/
Decembrie 14 (Cluj)Global Day of Coderetreat 2013 - Cluj Napocawww.meetup.com/cluj-rb/events/149860962/
Decembrie 14-16 (Bucure;ti)“Talks” by Softbinator #30it-events.ro/events/talks-softbinator-30/
Decembrie 22 (Brașov)Brașov Tech Meetup: December Meetit-events.ro/events/brasov-tech-meetup-december-meet/
Comunităţi IT
comunități
13www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE programare
În PHP conceptul BDD a cunoscut două forme: SpecBDD - care se concentrează pe comportamentul tehnic al codului- și mult mai popularul, StoryBDD - care pune accen-tul pe comportamentul de business/trăsătură. Astfel, pentru SpecBDD se scriu specificații despre cum să se comporte codul, iar pentru StoryBDD se scriu „povești” („story”-uri) despre cum ar trebui să se comporte aplicația, folosind un limbaj foarte apropiat de cel uman, numit Gherkin. Framework-urile venite să ajute aceste activițăti au devenit PHPSpec pentru SpecBDD și Behat pentru StoryBDD, acesta din urmă fiind un proiect inspirat de Cucumber din Ruby.
Articolul de față este dedicat formei StoryBDD și vine să prezinte aspecte tehnice de organizare a testării funcționale pen-tru proiecte web, în vederea automatizării acesteia. Ca să testăm exact din perspectiva clientului ar presupune, în condiții ideale, să avem același tip de browser, să efectuăm în aplicație același comportament ca al său și să analizăm totodată rezultatele acțiunilor noastre, dacă corespund unor așteptări de business corecte. În condiții inferioare celor ideale, din mai multe motive, s-ar putea totuși să ne mulțumim măcar cu o testare server-side, renunțând parțial sau complet la facilitățile browser-ului. Punerea
în aplicare a unui astfel de mediu de testare BDD presupune următoarele etape: instalarea tool-urilor, configurarea mediului, scrierea de “story”-uri, extinderea limbajului, com-pararea datelor, execuția si raportarea.
InstalareaEste prima etapă și, din păcate, de obi-
cei riscă să fie cea mai frustrantă. Pentru că am menționat tool-uri, excepție PHP care se subînțelege (versiunea minim 5.3), suita este compusă din:
a. un interpretor de limbaj Gherkin, care să traducă ”poveștile” umane în acțiuni mașină: Behat;
b. un set de metode care să producă acțiuni în browser: Mink cu driver-ele sale și MinkExtension;
c. o soluție de a comunica cu browser-ul (proxy-uri), transmițându-i instrucțiunile de mai sus și citind răspunsul: Sahi (supe-rior, mai ales versiunea Pro) sau Selenium2 (necesită JRE instalat);
d. o soluție de a compara răspunsul de la browser cu așteptările corecte, dar care să permită includerea într-un proces de tes-tare automată: PHPUnit;
e. și bineînțeles browser-e. La acest punct testarea de diferite versiuni de Internet Explorer adaugă complexitate
În 1999 se afirmau principiile de „Extreme programming”, iar patru ani mai târziu Kent Beck a reformulat conceptele în așa numitul Test Driven Development. În același an Dan North încerca să răspândească principiile TDD, dar se lovea frecvent de aceleași
întrebări: „În ce fază să înceapă scrierea de cod?”, „Ce trebuie testat mai exact?” și „Care să fie structura testelor și cum să se numească ele?”. Atunci el a avut inspirația să propună ideea testării de comportament sau testarea funcțională și astfel s-a născut Behaviour Driven Development - o paradigmă care își propune o testare din perspectiva utilizatorului.De la concept la implementare în diferite limbaje n-a mai fost decât un mic pas.
suplimentară, prin faptul că nu pot exista mai multe versiuni de IE pe aceeași mașină.
Diagrama de interacțiune și instalare a componentelor este următoarea:
Procesul de instalare permite mai multe variante. Dacă Sahi vine cu un „installer” vizual, este mai ușor ca celelalte compo-nente să fie instalate împreună, folosind Composer. Se editează un fișier text, com-poser.json, cu următorul conținut JSON:{ „require”: { „behat/behat”: „2.4.*@stable”, „behat/mink”: „1.4.*@stable”, „behat/mink-extension”: „*”, „behat/mink-goutte-driver”: „*”, „behat/mink-selenium2-driver”: „1.0.*”, „behat/mink-sahi-driver”: „1.0.*”, „phpunit/phpunit”: „3.7.*” }, „minimum-stability”: „dev”, „config”: { „bin-dir”: „bin/” }}
se aduce și se demarează instalarea întregii suite definite mai sus:curl http://getcomposer.org/installer | phpphp composer.phar install
Operațiile de instalare pot dura cîteva minute, dar la final rezultatul este un fol-der vendor/ care conține dependențele proiectului.
În această etapă sunt utile cîteva mențiuni speciale:
• pentru o organizare fără modificări în afara directorului de proiect nu se recomandă includerea executabilulului ”bin/behat” în lista comenzilor cunos-cute, ci lansarea executabilui prin calea completă sau relativă la directorul de proiect;• este bine de creat un folder dedicat
rapoartelor.
ConfigurareaImediat după instalare este nece-
sară configurarea mediului de testare funcțională.
Pentru acest lucru se inițializează (prima și o singura dată pe proiect) mediul Behat, prin comanda:
php bin/behat --init
În acest moment practic suntem gata de utilizare a unui cadru BDD minimalist, însă în practică cerințele se extind la:
• p os ibi l i t atea de a r u la tes te f u n c ț i o n a l e î n browser-e specifice;• rularea tes-
t e l o r î n m e d i u l ser ver-s ide, când browser-ele lipsesc sau nu este nevoie de ele;• n e c e s i t a t e a
de a avea rapoarte s e r v e r- s i d e dup ă exe c uț i a te s te lor funcționale;
• intervenția minimă în procesul de configurare, pentru o mentenanță ușoară.
Majoritatea acestor cerințe se înde-plinesc prin realizarea unui fișier ”behat.yml” cu profile specifice, cel implicit fiind profilul Mink de bază, server-side, care nu permite interpretarea de Javascript:default: extensions: Behat\MinkExtension\Extension: base_url: ‚https://www.site.com/’ goutte: guzzle_parameters: ssl.certificate_authority: false filters: tags: „~@javascript”
Ultima parte a configurării se referă la browser-e:
• se recomandă efectuarea configură-rilor de proxy server, corespunzătoare Sahi sau Selenium2. Această operațiune aproape că leagă exclusiv browser-ele de testarea funcțională, funcția de navigator fiind obstrucționată de proxy-uri - de aceea se impune un mediu dedicat pen-tru testarea funcțională;
• sunt necesare configurări speciale pentru ”https”, întrucât invitația certifi-catului face imposibile testele, iar acest lucru depinde de proxy-ul utilizat; sco-pul final este ca browser-ul să cunoască adresa “https” și certificatul să fie deja instalat;• atunci când ne aflăm în imposibilita-
tea de a utiliza browser-e comune (spre exemplu ne aflăm pe un server cu mod text), se poate testa funcțional inclu-siv codul Javascript folosind browser-ul PhantomJS; întrucât Mink nu are dri-ver pentru acesta, utilizarea lui se poate face printr-un proxy. Pentru Sahi browser-ul PhantomJS trebuie adăugat la configurări;• atunci când proiectul este mare, ceea
ce implică multe teste, este mai bună, în Behat versiunea 2, o organizare cu mai multe template-uri de behat.yml, pentru fiecare browser, iar la nivel de profile să fie testarea trăsăturilor individuale ale aplicației.
Structura testelorDan North a mai venit cu o realizare
însemnată: el a simplificat structura teste-lor clasice de la patru faze (setup, executare, verificare, teardown) la trei, și anume Given, When, Then. Acestea au devenit cuvinte cheie care semnifică actorul, con-textul (procesul) și rezultatele acțiunilor.
Testele sunt organizate în ”story”-uri sau suite, care prezintă un titlu și o descriere. Fiecare ”story” cuprinde unul sau mai multe scenarii. Un scenariu este o compoziție ordonată de mai mulți pași de testare (”steps”). Fiecare pas reprezintă în limbaj Gherkin o acțiune. ”Cum știe cal-culatorul ce să execute la întâlnirea unui pas Gherkin? ” este o întrebare care își află răspunsul printr-un dicționar, nimic mai mult decât o tabelă de asociere injectivă de la limbaj spre metode PHP.
Behat vine implicit cu un dicționar de bază. Pentru aflarea acestuia, cu detalii sau fără, se pot folosi comenzile :php bin/behat -diphp bin/behat -dl
Extinderea dicționarului este simplă și în acest sens Behat ajută prin indicarea unui prototip de metodă PHP pentru fie-care frază Gherkin pe care nu o cunoaște. Metoda va trebui implementată în cadrul contextului.
Persistența ”story”-urilor pe disc se rea-lizează ca fișiere text, cu extensia ”.feature”. Pentru proiectele mari se poate realiza o structură logică cu directoare imbricate, dar aceasta presupune că suitele vor trebui
programare
15www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
rulate individual, întrucât, implicit, dacă nu este specificat, Behat execută toate fișierele ”*.feature” din folder-ul ”features/”, dar nu recursiv. Referitor la story-uri se impun următoarele mențiuni:
• nu pot exista dependențe între ”story”-uri;• implicit scenariile sunt complet
independente, iar dacă sunt necesare persistențe de date între acestea , se impune programare specială;• se recomandă folosirea tag-urilor, în
special a celor care împart scenariile în două categorii: necesită sau nu Javascript (pentru Javascript tag-ul este @Javascript și se poate insera deasupra titlului ”story”-ului sau la fiecare scenariu).
Spre exemplificare, structura unui
”story” devine:# Content of file Login.feature Feature: User makes login As a user I want to do login So that I can see my dashboard
@Javascript Scenario: Login with correct credentials Given I am in the „/login” page When I fill ”myusername” And I fill ”mypassword” And I click ”Login” Then I should see ”Welcome Username!”
Scenario: Login with bad credentials Given I am in the „login” page When I fill ”bad username” And I fill ”bad password” And I click ”Login” Then I should see ”Invalid credentials”
Structura fișierelor de contextMai sus scriam despre dicționar că este
conceput ca o tabelă care traduce Gherkin în metode PHP. Dacă Gherkin este descris în fișiere ”features/*.feature”, metodele sunt organizate în așa-numitele fișiere de context, localizate implicit la ”features/bootstrap/*.php”.
Există un singur fișier de context
principal, compus din definiția unei clase care derivă, în principal (întrucît există și alte clase de context, dar sunt particu-lare), din BehatContext sau MinkContext. Diferența dintre cele două clase de bază este că MinkContext aduce în plus funcționalitatea de sesiune, iar BehatContext oferă o funcționalitate implicită minimală. Contextul principal poate avea subcontexte și astfel se rezolvă problema unui dicționar care poate deveni foarte mare pentru un singur fișier.
Pentru extinderea dicționarului tre-buie realizată o corespondență între pasul din ”story” și metoda necesară a fi imple-mentată în context. Implementarea este precedată de adnotările speciale @Given, @When, @Then, urmate de o expresie regu-lată, care, dacă este îndeplinită, declanșează apelul metodei respective: /** * Some function description * * @Given /I am („\w+” user)/ * @Given /I am user:/ */ public function iAmUser(User $user) { $this->user = $user; }
Funcția poate avea orice nume, expre-sia regulată este cea determinantă. Aceeași funcție poate avea mai multe adnotări, cum se vede mai sus, important fiind că relația regex-funcție să fie injectivă, altfel survine o eroare. De asemenea este recomandat să fie scrisă și o descriere-titlu a funcției, care va fi vizibilă la afișarea detaliată a dicționarului.
În corpul unei funcții se poate scrie lim-baj Gherkin, realizându-se un pas complex:/** * @Given /I entered „([^”]*)” and expect „([^”]*)”/ */public function complexStep($number, $result){ return array(
new Step\Given(„I have entered \”$num-ber\””), new Step\When(„I press +”), new Step\Then(„I should see \”$result\” on the screen”) );}
De asemenea, se poate injecta cod Javascript direct în browser sau se pot apela funcții specifice proxy-lui utilizat.
Este ușor de anticipat că pentru pro-iecte mari, atunci când există un singur fișier de context principal, acesta riscă să cuprindă multe definiții și să devină greu de gestionat, mai ales că expresiile regulate trebuie să fie injective inclusiv la utiliza-rea sub-contextelor. În Behat versiunea 2 (singura stabilă în acest moment) ,pro-iectele mari au următoarele alternative de organizare:
• utilizarea profilelor, din fișierul behat.yml, și pentru fiecare profil se poate utiliza proprietatea cheie ”class ” sau împreună proprietățile ”features” si ”bootstrap”; acest lucru necesită atenție la setup-ul profilelor (numele trebuie să fie unice);• utilizarea sub-contextelor; contextul
principal poate încărca contexte copil, fiecare cu sesiune individuală sau parta-jată de la contextul parinte.
Versiunea Behat 3, în curs de dezvol-tare, va aduce posibilitatea de organizare feature-context.
Mai departe, Behat oferă și posibilita-tea de a avea acțiuni automate, rulate prin intermediul ”hook”-urilor:
• înainte sau după rularea testelor funcționale (tag-ul @BeforeSuite); • înainte sau după un story (tag-ul @
BeforeStory);• înainte sau după un scenariu (tag-ul
@BeforeScenario).
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.
TODAY SOFTWARE MAGAZINE
16 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
programare
Acestea sunt utile pentru operațiunile de conectare la baza de date, pentru pregă-tiri de teste sau curățări și raportare. Figura alăturată prezintă etapele de execuție ale acestor operații, intercalate în faza de rulare a fișierelor “*.feature”.
Se poate întâmpla ca anumite site-uri să se încarce mai greu și din acest motiv tes-tele funcționale să invalideze. În acest sens sunt utile ”spin” –urile, care au rolul de a testa prelungit un anumit step, înainte ca
acesta să invalideze rapid.
Verificarea datelorÎn cadrul fișierlor de context, în corpul
funcțiilor, atât celor implicite cât și celor dezvoltate ulterior, intervine operația de comparare între rezultatul întâlnit și rezul-tatul așteptat. Utilă în acest sens este librăria PHPUnit care vine cu o largă varietate de operațiuni de comparare care validează sau nu rularea testelor.
Folosirea PHPUnit aduce avantajele integrării mature cu mediile de Continuous Integration/Delivery și utilizarea unui cod existent. Mink are deja funcții de com-parare derivate din PHPUnit, dar pentru folosirea tuturor funcțiilor PHPUnit este necesar importul:require_once ‚PHPUnit/Autoload.php’;require_once ‚PHPUnit/Framework/Assert/Func-tions.php’;
necesar ca proxy-ul să fie instalat pe aceeași mașină unde se află browser-ul, să fie pornit, iar browser-ul să aibă setările de proxy deja configu-rate. Mink va transmite comenzile la adresa proxy-ului specificată în behat.yml, proxy-ul va deschide browser-ul local, însă rapoartele și rezultatele testelor se desfășoară pe mașina unde s-a rulat linia de comandă. Acest lucru permite utili-zarea mașinilor virtuale, cu diferite instanțe de browser-e (de obicei
cerute de Internet Explorer), mașini care la rândul lor pot fi controlate prin utilizarea script-urilor. Condiția este ca serverul de test să aibă mod grafic și o soluție de virtu-alizare (VMWare, VirtualBox etc.).
Testarea funcțională independentăUn caz destul de frecvent este cerința
de a implementa testări funcționale com-plet independent de proiect. Acest lucru presupune crearea unui proiect pentru testele funcționale, care să permită o struc-tură flexibilă de extindere pe orizontală, mai ales când portalul web are dimensiuni mari. Extinderea presupune trei sau patru dificultăți:
• structura pe disc a fișierelor ”.feature”;• structura fișierelor de context și
decizia de organizare a testelor pe profile (mai eficientă și mai ușor de intreținut, cel mai bine cu template-uri de behat.yml specifice unui tip de browser) sau pe sub-contexte (în acest caz nu se recomandă folosirea funcțiilor magice);• modul de obținere al setului de date
cunoscute;• opțional, mai ales în cadrul pro-
iectelor în care structura DOM a HTML-ului nu permite acționarea facilă a elementelor (spre exemplu avem lipsa
proprietăților ”id”, ”name”, ”class” la elementele HTML), este necesară identi-ficarea programatică a elementelor de pe UI (de obicei folosind Xpath ”locators”); când numărul acestora crește considera-bil, este necesară o structura favorabilă de persistență, aflată în relație cu setul de date cunoscute.
Pentru o mai bună organizare și pentru că de multe ori QA-ul nu cunoaște modul de stabilire al datelor corecte, este mai bine ca setul de date cunoscute să fie păstrat în cadrul proiectulului părinte, iar între acesta și proiectul de testare funcțională să se poată stabili o metodă de comunicare (REST, http, bază de date comună etc.), prin care se poate interoga valoarea corectă pentru un element funcțional specific.
ConcluziiTestarea funcțională reprezintă apogeul
actual al testelor efectuate din perspectiva utilizatorului. O intuiție sau o reproducere a comportamentului acestuia și a contex-tului acestuia (browser) asigură un nivel excelent de calitate a produsului software. Menirea pricipală a testelor funcționale o reprezintă analiza comportamentală și con-textuală, însă ele pot fi extinse și la anumite analize de performanță sau securitate.
Testarea funcțională în PHP
17www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
Atenţie!Nu uitaţi că toate acţiunile au loc în
browser-ul clientului, ceea ce înseamnă că acesta are control deplin asupra browser-ului și poate evita controalele de securitate. De aceea este foarte important să verificăm și în back-end.
Configurarea rutării clientuluiAici vom selecta paginile care vor
avea nevoie de autentificare și vom confi-gura rutarea aplicaţiei. O rută se definește furnizând cel puţin template-ul sau tem-plateUrl-ul și controller-ul paginii. În plus, am adăugat proprietatea access cu atributul allowAnonymous. În acest fel știm dacă ruta actuală necesită autentificare sau este o pagină cu acces nerestricţionat. În exemplele de mai jos avem pagina Login care este acce-sibilă oricui și pagina MembersPage care necesită autentificare.
Următorii pași sunt recunoașterea utili-zatorului autentificat și verificarea accesului acestuia la rute.
Recunoaşterea unui utilizator autentificatAcest lucru se poate face în multiple
moduri, dar preferăm folosirea de servicii în AngularJS. De aceea am creat un UserService în care am stocat numele de utilizator actual și o valoare care indică dacă utilizatorul este autentificat sau nu.
// in UserService.js
myApp.factory(‚userService’, function () { var user = { isLogged: false, username: ‚’, };
După ce am configurat serviciul, este timpul să îl folosim și să implementăm func-ţionalitatea de verificare a rutei. În cazul schimbării rutei există mai multe metode de interceptare, dar pe noi ne interesează doar schimbarea care are loc înainte ca utilizato-rul să fie redirecţionat pentru a putea verifica dacă este autentificat: $routeChangeStart, $locationChangeStart. Prin aceste metode putem verifica dacă ruta accesată permite accesul unui utilizator neautentificat. În caz de eroare putem afișa un mesaj de eroare și
Autentificarea este procesul de identificare a unui utilizator care dorește să acceseze o resursă protejată. Folosim procesul de autentificare în viaţa cotidiană: cărţi de iden-titate, nume de utilizator, parole, carduri de acces etc. . Procesul care urmează se
numește autorizare, ambele sunt în strânsă conexiune și, uneori, confundate. Prin autorizare verificăm drepturile utilizatorilor pentru a vedea dacă au sau nu acces la o resursă specifică, după ce s-au autentificat. În orice caz, nu confundaţi noţiunile: autorizarea nu poate exista fără autentificare. În articolul de faţă vom analiza procesul de identificare a utilizatorului folosind AngularJS.
să-l redirecţionăm pe utilizator înspre pagina de logare. // in RootController.jsmyApp.controller(‚RootController’, function ($scope, $route, $routeParams, $location, $rootScope, authen-ticationService, userService, toaster) { $scope.user = userService.user; $scope.$on(‚$routeChangeStart’, function (e, next, current) { if (next.access != undefined && !next.access.allowAnonymous && !$scope.user.isLogged) { $location.path(„/Login”); } });
$scope.logout = function () { authenticationService.logout() .success(function (response) { userService.reset(); toaster.pop(„info”, ‚You are logged out.’, ‚’); }); }; $rootScope.$on(„$locationChangeStart”, function (event, next, current) { for (var i in window.routes) { if (next.indexOf(i) != -1) { if (!window.routes[i].access.allowAnonymous && !userService.user.isLogged) { toaster.pop(„error”, ‚You are not logged in!’, ‚’); $location.path(„/Login”); } } } }); });
Authentication ServiceAcest serviciu oferă o modalitate de a comunica cu serverul și
stabilește statusul de autentificare. În acest moment ne interesează metodele de login/logout. Pe partea de back-end se folosește un serviciu de Web API service.
Metoda de login este un post request care transmite datele de logare consistând din numele de utilizator și parolă. Vă rog să observaţi că RequestVerificationToken este folosit pentru a se evita cross-site request forgery attacks.
When the user clicks login button, the form data is sent to the account controller. Using the authentication service, the data is sent in a POST request. In case of success we use the user service to store the data and redirect the user to the desired page, other-wise we show an error message and keep the user on the login page.
// in AccountController.jsmyApp.controller(‚AccountController’, function AccountController($scope, $cookies, $log, $location, au-thenticationService, toaster, userService) {
$scope.login = function (userData, loginForm) { if (loginForm.$valid) { authenticationService.login(userData, $scope.antiForgeryToken) .success(function (response) { if (response.status) { userService.user.username = response.data.userName; userService.user.isLogged = response.data.isLogged; toaster.pop(‚success’, ‚You are signed in!’, ‚’, 2000, true); $location.path(„/MembersPage”); } else
Acestea sunt lucrurile de care este nevoie pentru a implementa o autentificare rudimentară cu AngularJS.
programareGestionarea autentificării în AngularJS
19www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
O soluție pentru a reduce risipa generată de rescrierea documentelor de specificații ar fi folosirea testelor ca specificații. Acestea verifică deja codul și sunt sincronizate în permanență cu codul de producție. De ce să nu fie scrise în așa fel încât să arate ca un document de specificații?
Cum se scriu specificațiile executabile?Testele pot fi scrise ca specificații executa-
bile respectând câteva reguli:• Testele să fie scrise într-un asemenea fel
încât să poată fi citite în limbaj natural.• Numele testelor să folosească doar
l i m b a j d i n d o m e n i u l de business, fără termeni tehnici. • Testele să
n u i n c l u d ă d e t a l i i d e implementare în nume.
• Testele să se concentreze pe comporta-mentul utilizatorului sistemului.
Mai trebuie și alt fel de documentație?În funcție de tipul de sistem software
dezvoltat este nevoie și de alte tipuri de documentație care nu pot fi generate automat din codul de producție. Iată câteva exemple: manualul utilizatorului, documentație de arhitectură, documentație comercială, pentru operațiuni, etc. .
Evident că acest tip de documentație trebuie să fie scrisă folosind documente sau diagrame specifice.
Specificațiile executabile sunt o modalitate de a folosi testele automate cu scopul de a documenta funcționalitățile unei aplicații. Testele automate sunt tot mai utilizate în industria software cu scopul de a valida funcționarea corectă a unei aplicații. Validarea
funcționării corecte implică evident și un dialog cu persoanele care formulează cerințele (analiști business, product owners, product managers, alți stakeholders) și testele automate nu ne scutesc de documentarea cazurilor de utilizare ale aplicației. Pentru documentarea funcționalităților există câteva soluții, cea mai comună fiind scrierea de documente de specificații. Problemele încep în momentul în care funcționalitățile se schimbă, de cele mai multe ori documentele de specificații nemaiținînd pasul. Motivele sunt variate: aceasta proce-dură este greoaie, adesea de durată si adesea documentele sunt create de alte persoane decât cele care scriu codul pentru aplicație. Apare astfel riscul ca specificațiile să nu arate, pentru o perioadă de timp, modul actual de funcționare.
Programmer. Organizational and Technical Trainer and Coach@Mozaic Works
TODAY SOFTWARE MAGAZINE
20 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
UnelteFitnesse1 este, istoric vorbind, prima
unealtă pentru a scrie teste executa-bile. Folosește tabele și poate fi folosit pe aproape orice tehnologie.
RSpec2 si Cucumber3 au fost dezvoltate inițial pentru ruby, dar acum există și vari-ante în alte limbaje. De exemplu SpecFlow 4este o adaptare pentru .Net, iar JBehave5 a fost dezvoltat pentru tehnologii Java.
Cum se lucrează cu specificații executa-bile
Specificațiile pot să fie scrise de persoa-nele de business (analiști, product owners, product managers, etc.) în limbaj natural într-o formă de genul următor:
Feature: Adition In order to avoid silly mistakes Cashiers must be able to calculate a
sum
Scenario: Simple numbers• I have entered 4 at the calculator
keyboard• I have entered 3 at the calculator
keyboard• I press sum• The screen should display 7 as a
result
Astfel oricine cunoaște limbajul de domeniu poate să înțeleagă și să citească acest test.
1 http://en.wikipedia.org/wiki/FitNesse2 http://rspec.info/3 h t t p : / / e n . w i k i p e d i a . o r g / w i k i /
Programatorii vin apoi și leagă acest text cu funcții din cod, care apelează codul de producție, într-un mod foarte similar ca testele scrise în JUnit/NUnit/xUnit , dar puțin altfel structurate. Aceste teste vor pica la început, urmând să treacă pe măsură ce funcționalitățile sunt implementate.
Avantaje specificațiilor executabile?• M i n i m i z e a z ă m u n c a d e
documentație, legând-o cu testarea automată.• Feed-back foarte rapid pentru persoa-
nele care creează cerințele pentru produs. Pot să știe oricând ce funcționează și cum, cu condiția să ruleze un set de teste.• Feed-back foarte rapid pentru dez-
voltatori. Înțeleg repede unde trebuie să modifice sistemul actual pentru a adăuga noile funcționalități.• O unealtă de dialog foarte utilă între
persoanele de business și persoanele tehnice. Specificațiile sunt înțelese de ambele grupuri de persoane și evităm situațiile “noi vs. ei”.• Crește încrederea echipei că au un
produs care face ce trebuie.
Dezavantaje?• Nu se poate realiza dacă nu avem
teste automate pentru toate cazurile de utilizare a sistemului software.• Trebuie menținută o disciplină
riguroasă în echipele care scriu testele pentru a se concentra asupra compor-tamentuluidin partea utilizatorului și pentru a folosi doar nume din limbajul de domeniu.
ConcluziiSpecificațiile executabile sunt o soluție
foarte bună pentru a avea un feed-back constant și pentru a verifica dacă aplicația se comportă precum se așteaptă utilizato-rii. Pentru a scrie specificații executabile trebuie ca programatorii să stăpânească scrierea de teste unitare, de teste de acceptanță și folosirea limbajul din dome-niul business pentru care lucrăm.
Tranziția către specificații executabile poate să fie treptată, în pași mici, până ce dialogul între persoanele de business și dezvoltatori devine eficient.
Folosind specificațiile executabile, analiștii business pot să scrie în limbaj natural cerințele pe baza cărora poartă un dialog cu dezvoltatorii, în același timp cre-ând testele de acceptanță pentru aplicație.
arhitecturăSpecificații executabile
21www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE management
Îmbunătățirea Continuă –
o practică de luat în serios
În Cluj, dacă vei întreba persoane care lucrează în companii de dezvoltare software ce profesie consideră că au, o bună parte vor răspunde ”inginer software”. Sună bine, dar mulți dintre ei doar după ani buni de experiență în IT ajung să înțeleagă ce e cu adevărat ingineria software și ce implică ea. Motivul principal pentru care studenții nu înțeleg însemnătatea diverselor aspecte de inginerie software nu are legătură cu conținutul. Revizuind acele materii după ani de experiență în IT, descoperi că erau de fapt relevante și interesante. Chestiuni precum CMMi par foarte captivante și clar expli-cate. De ce nu aveam același sentiment și în momentul respectiv, când eram în facultate?
În acest articol mă voi concentra pe îmbunătățirea continuă (Î.C.), una dintre cele mai puțin înțelese practici din cadrul ingineriei software; e demn de menționat
că, în mare parte, se poate aplica foarte bine și altor concepte (management de proiect, ana-liză și design software, arhitectură software, specificarea cerințelor software). Voi încerca să expun pe scurt unele din motivele res-ponsabile pentru situația menționată, dar apoi mă voi concentra în principal pe soluții care s-au dovedit a fi eficace și care ar putea să îmbunătățească situația într-o oarecare măsură.
Fără îndoială, una dintre cauzele prin-cipale ale conceptelor neînțelese este educația. Educația, după cum am menționat deja, oferă acces către o sursa valoroasă de conținut, dar care din nefericire nu este întot-deauna transmisă eficient. Când vorbesc de educație, includ atât experiența școlară (pre-absolvire) cât și educația din cadrul organizației, deseori numită dezvoltare pro-fesională. Îmi voi îndrepta atenția mai mult
Programele de studiu superior din România orientate spre informatică și calculatoare deseori includ cursuri de inginerie software, analiză și design software și manage-mentul proiectelor. În ciuda aspectului inițial atractiv pe care cursuri de tipul acesta
îl arată, studenții deseori devin ușor dezamăgiți către finalul lor, sau cel puțin în comparație cu alte cursuri (limbaje de programare, hardware, chiar și fizică, matematică), acestea fiind văzute mai puțin interesante sau utile. În realitate, nu e vorba de o lipsă intrinsecă pe care o au studenții în legătură cu aceste subiecte. O parte din problemă constă în abordarea teore-tică a acestor materii și dificultatea pe care o au studenții în a înțelege în mod fundamental conținutul. Aceasta rezultă în nevoia de a învăța pe de rost o parte bună din cursuri, fără a înțelege cu adevărat principiile din spate.
spre aceasta din urmă deoarece este una în care avem mai mult control și flexibilitate, astfel încât mă aștept să descoperim soluții pragmatice cu rezultate imediate.
Un motiv deseori invocat pentru educația ineficientă este lipsa abilităților didactice. Studenții sau începătorii nu se simt atrași sau inspirați de la bun început. De asemenea, lipsa entuziasmului profe-sorului sau mentorului se transmite foarte repede. Un alt motiv (și din punctul meu de vedere) deși mai rar invocat, este unul care contribuie mult mai mult. Acesta e lipsa unui context atașat materiei. În universitate, lipsa contextului uneori devine ridicolă. Subiecte precum CMMi – un model foarte abstract a cărui esență implică un program real de Î.C. – poate fi înțeles doar în con-textul vieții în organizație. Aceasta însă este necunoscută majorității studenților la momentul respectiv (unii vor avea locuri de muncă în IT când sunt încă la facultate, dar și așa abia au început să descopere ce înseamnă viața în organizație).
În facultate este foarte dificil să oferi acest context, dar chiar și când vorbim de dezvoltare profesională într-o organizație, prea des vedem aceeași lipsă. Î.C. tre-buie cultivată într-un cadru potrivit, și din păcate chiar și organizațiile care par să înțeleagă foarte bine conceptul tind să impună practica în loc să învestească în educație și în oferirea unui mediu prielnic. Şi aici se află de fapt cheia. Propunerea mea pentru Î.C. este să o luăm în serios. Aceasta presupune o serie de schimbări și ajustări pe care trebuie să le facem în organizație, iar eu cred că cea mai bună abordare este bidirecțională (pornind atât de sus, cât și de jos, în același timp).
Privind de sus, principala schimbare este practicarea Î.C. într-un mod cât mai transparent posibil. Cu siguranță managementul senior din echipa de lea-dership practică Î.C., dar când și cum? Asigurați-vă că devine clar pentru organizație. Managementul senior ar tre-bui să-și facă un țel din a fi cei mai buni la Î.C. Oamenii vor să afle despre deciziile luate la nivel înalt într-un mod bine cal-culat și informat (mai ales cele dificile), despre planificarea strategică, retrospec-tive care iau în considerare date istorice (colectate de-a lungul timpului), riscuri calculate, managementul proceselor și al calității la nivele de management senior, și așa mai departe. Dacă e posibil, oamenii ar fi plăcut surprinși să vadă chiar dovezi concrete ale acestor activități: documente ajutătoare (de exemplu, analiza de deci-zie), rapoarte ale întâlnirilor, măsurători, liste și log-uri, orice poate inspira nivelele de mai jos. Conducerea prin exemplu se dovedește a fi unul dintre cele mai bune moduri de a induce schimbarea în cul-tura organizațională. Din păcate, aceasta funcționează și în cazurile în care practicile arătate sunt slabe.
Privind de jos în organizație, atenția pe educație trebuie întărită. Majoritatea angajaților este dispusă să învețe și să înțeleagă, dar majoritatea profesioniștilor IT este sceptică de la natură (și e foarte bine să fie așa). Pentru a-i câștiga, e impor-tant să vorbim concret, ceva ce poate fi cu adevărat solicitant când subiectul este Î.C. O metodă bună e aceea de a spune povești de succes. Identifică cele mai bune proiecte unde Î.C. merge foarte bine și oferă cadrul potrivit pentru ca oamenii din aceste proiecte să-și spună povestea.
Încurajează promovarea succesului prin Î.C prin metode gen sesiuni deschise, „târ-guri” interne, workshop-uri, și schimburi de experiență între echipe. O abordare de tip târg intern a fost folosită de câteva ori în ISDC. Este un loc în care oamenii pot să arate ceva de care ei sunt mândri din viața profesională. Poate fi o arhitectură inteli-gentă, un design funcțional interesant din produsul la care au lucrat, o componentă re-utilizabilă sau, pur și simplu, practici bune pe care le-au colectat de-a lungul timpului – ponturi utile într-un context sau altul. În orice caz, este o metodă eficientă și relativ ieftină de a-i aduce pe toți într-un loc și a genera un cadru prielnic dialogului. Un mediu informal e perfect pentru a încu-raja conversațiile prietenoase și deschise. Nu numai că un eveniment de genul acesta e o sursă de motivație, dar e incredibil să vezi câte lucruri noi și deseori relevante află angajații despre ceea ce fac colegii lor din alte proiecte și echipe.
Alteori, metode mai puțin intuitive se dovedesc a fi foarte productive. Un exem-plu este încurajarea oamenilor să învețe de la colegii lor. Aceasta presupune o oarecare împuternicire a întregii organizații și, în loc să îi implici mereu pe aceiași seniori susținători puternici ai Î.C., implică-i și pe ceilalți. Descoperă persoane care vor face publicitate gratis și încurajează-i în mod conștient (mai ales dacă sunt persoane cu putere informală). Încurajează de asemenea dialogul, nu îi cenzura sau ascunde pe cei care au o opinie mai puțin pozitivă despre Î.C. Cu cât se vor simți mai puțin ascultați, cu atât va fi mai greu să-i convingi. Deci e important să nu neglijăm acest aspect, pen-tru că și aceștia pot fi persoane cu putere mare informală. În cazuri de conflict de
managementÎmbunătățirea Continuă – o practică de luat în serios
23www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
opinie, organizează dezbateri publice. O practică de genul acesta e foarte productivă în ISDC. O numim „Mythbusters” și este de fapt o dezbatere deschisă pe un subiect controversat. Participanții sunt încurajați să se implice și avem voturi înainte și după dezbatere astfel încât să vedem ce convin-geri au fost schimbate pur și simplu prin discuții raționale, argumentarea și prezen-tarea unor fapte și date reale, descoperite prin cercetare prealabilă.
Î.C. se află într-o perioadă grea. Acum aproape un secol, când a pornit totul, Japonia era una dintre țările cu cea mai slabă calitate a produselor. În perioada respectivă a apărut o inițiativă nouă sub numele de „Kaizen”. Aceasta însemna pur și simplu „schimbare bună” (kai = schimbare, zen = bun). O filozofie simplă a revigorat complet economia și a făcut Japonia una dintre țările cu cea mai bună calitate în era modernă. Î.C. a explodat în diverse forme și locuri, de la producție la servicii și de la produse tangibile la pro-duse abstracte și creative. Diverse industrii au adoptat conceptul și l-au adaptat nevo-ilor lor. CMMi este de exemplu un model de Î.C. specific gândit pentru IT. În timp ce pentru industriile cu rezultate tangibile și repetitive ( de exemplu: construcție de automobile) standardele concrete merg bine, în IT a fost nevoie de un model mai abstract și flexibil, unul care întotdeauna solicită adaptarea la context (tailoring). Așadar, natura modelelor de Î.C. în IT este unul dintre motivele pentru care sunt difi-cil de înțeles și aplicat. Dar nu e vorba doar de IT.,industriile în general tind să devină tot mai puțin tangibile în ceea ce privește implicarea umană. Automatizarea preia tot mai mult din munca repetitivă, pre-dictibilă și tangibilă, ignorând implicarea umană tot mai importantă în arii precum: creativitate, inovare, strategie, planificare complexă, management, comunicare și interacțiune umană. Tocmai de aceea acum începem să vedem un declin în Japonia. În
ultimii ani, calitatea a început să scadă în comparație cu alte țări care încep să iasă pe piața internațională tot mai mult (China sau Coreea de Sud). Acestea încep să preia conducerea. De ce? Din exact același motiv pentru care Japonia a preluat conducerea secolul trecut: au descoperit o metodă mai bună de a face lucrurile. Dar acum țările care nu demult au început să aprecieze Î.C. o aplică direct pe industrii puțin tangibile, ceea ce le dă un avantaj în comparație cu Japonia unde există încă o oarecare inerție.
Ce e de învățat de aici? În primul rând să nu renunțăm la Î.C. În schimb, trebuie să învățăm să o aplicăm bine, să educăm începătorii în domeniu prin prezența unui context favorabil și, de fapt, să o luăm în serios. Trebuie să fim sceptici, să punem întrebări relevante, să fim deschiși, să adap-tăm Î.C. în funcție de situație. Lumea este tot mai dinamică, iar practicile noastre tre-buie adaptate acesteia.
24 nr. 18/Decembrie | www.todaysoftmag.ro
Alinierea partițiilor în medii virtuale
Concepte de storageProblema alinierii partițiilor a apă-
rut odată cu conceptul de virtualizare și presupune folosirea de storage partajat de mașinile virtuale.
Vom prezenta pe scurt principalele platformare de virtualizare (VMware și Hyper-V) și modul cum tratează fiecare problema alinierii corecte a partițiilor.
Vom descrie pe scurt și unele concepte pe care le vom folosi ulterior:
Alinierea sistemului de fișiereÎn cadrul storage-ului există mai multe
straturi implicate în procesul de aliniere. În principiu, fiecare strat este împărțit în structuri de blocuri (blocks sau chunks).
Fiecare vendor poate să folosească blocuri de mărimi diferite, acest lucru nereprezentând o problemă. Pentru noi este important să știm unde începe acel bloc (starting offset). Pentru a avea o performanță maximă, offset-ul de început al sis-
temului de fișiere ar trebui să fie aliniat cu blocul din nivelul inferior de storage.
Nealinierea celor două limite va duce la operații I/O adiționale și la degradarea performanței.
Articolul Wikipedia Cylinder-head-sector1 este un bun început pentru a înțelege conceptele legate de discuri fizice.
În trecut, sistemele de operare nu luau în considerare alinierea corectă a partițiilor. De exemplu, Microsoft a rezolvat această problemă doar începând cu Windows Server 2008. Pentru distribuțiile Linux, cele care folosesc încă utilitarul fdisk sunt susceptibile să aibă această problemă.
Implicit, sistemele de operare moderne vor încerca să se alinieze la primul sector al unui track. Astfel în momentul instală-rii sistemului de operare, acesta va detecta valoarea Cilindru/Cap/Sector (Cylinder/Head/Sector – CHS) de la BIOS care în cazul mașinilor virtuale reprezintă de fapt un BIOS emulat. Problema stă în faptul că informația returnată nu corespunde cu realitatea, probleme apărând de exemplu la LUN-uri de peste 8 GB unde numărul de sectoare per track-uri este întotdeauna raportat ca 63.
Am definit anterior noțiunea de bloc de 1 http://en.wikipedia.org/wiki/Cylinder-head-sector
Odată cu trendul de virtualizare a serverelor din ultimii ani a apărut și problema alinierii greșite a partițiilor. Pentru că mulți dintre noi ignorăm importanța ali-nierii corecte a partițiilor, scopul acestui articol este prezentarea consecințelor
date. Un bloc de date reprezintă unitatea cea mai mică de date care poate fi folosită pentru a stoca date. Blocurile discurilor fizice vor avea întotdeauna 512 bytes, dar din motive de eficiență și scalabilitate, vendori-i de dispozitive storage folosesc valori puteri ale 2 alea unui block fizic????. Arhitectura NetApp folosește blocuri de 4 KB (8 blocuri fizice), HP 3Par de 16 KB, iar EMC Symmetrix de 64 KB.
Luând ca exemplu NetApp, o operație de scriere va folosi cel puțin 4 KB și poate folosi multiple blocuri de 4 KB în funcție de mărimea datelor ce urmează a fi scrise.
Problemele apar în momentul în care schema de partiționare a sistemului de fișiere a mașinii virtuale nu respectă limita din interiorul LUN-ului (Figura 1).
Dacă sistemul de fișiere al mașinii vir-tuale nu este aliniat, pentru a citi un bloc de date este nevoie de două apeluri la stra-tul inferior. Acest lucru duce la degradarea eficienței deoarece controlorul storage lucrează în plus pentru a realiza o operație de citire/scriere.
MwareÎn cadrul ESXi, există mai multe
modalități prin care un storage partajat poate fi prezentat unei mașini virtuale:
1. Virtual Machine File System (VMFS) folosind Fibre Channel sau iSCSI,
2. Network File System (NFS) exportat către un host ESX,
3. Raw Device Mapping – prezenta-rea directă a unui LUN către o mașină virtuală,
4. LUN mapat direct printr-un iSCSI inițiator
În cadrul ESXi, o mașină virtuală este încapsulată în două fișiere:
• Vmdk – reprezintă imaginea actu-ală a discului aparținând unei mașini virtuale.• Vmx – fișierul conținând setările de
configurare ale mașinii virtuale.
Atât exporturile de tip VMFS cât și NFS sunt referite ca datastores în cadrul ESX. Dacă este folosit NFS, stratul de abstrac-tizare VMFS dispare întrucât directoarele mașinii virtuale sunt ținute direct pe mount point-ul NFS prezentat ca datastore.
În cazul folosirii VMFS, figura anteri-oară are încă un nivel de abstractizare și arată astfel ca în Figura 2
Dacă atât VMFS cât și sistemul de
fișiere al mașinii gazdă sunt nealiniate,
Figura 1 Mașina virtuală cu sistem de fișiere nealiniat
Figura 2
TODAY SOFTWARE MAGAZINE
26 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
numărul de operații I/O adiționale este multiplicat.
VMFS 2 folosea ca offset implicit 63 de blocuri, provocând astfel nealinierea la nivel de I/O. VMFS 3 este aliniat impli-cit întrucât folosește 128 blocuri ca offset. Migrarea de la VMFS 2 la VMFS3 nu duce la alinierea datastore-urilor, pentru a rea-liza acest lucru fiind necesară copia pe un datastore nou.
În cazul Raw Device mapping-urilor și a LUN-urilor mapate direct către o masină virtuală, trebuie să fim atenți doar la alini-erea la nivelul sistemului de operare gazdă.
Conceptul de aliniere nu se aplică NFS decât la nivelul sistemului de operare gazdă.
Hyper-V În cadrul hyper-vizorului de la
Microsoft, acesta suportă următoarele modalități de a partaja storage către o mașină virtuală:
• LUN-uri cu sistem de fișiere NTFS (VHD cu dimensiune fixă, dimensiune expandabilă dinamic și diferențial).• Pass-through disk – discuri atașate
partiției părinte Hyper-V și asignate direct unei mașini virtuale, • LUN-uri mapate direct prin folosirea
unui inițiator iSCSI.
Așadar, o mașină virtuală în Hyper-V trece prin trei nivele de storage:
1. Sistemul de fișiere gazdă,
2. Partiția părinte Hyper-V,3. Storage array.
Se recomandă folosirea de VHD-uri cu dimensiune fixă, întrucât în cazul dis-curilor expandabile alinierea nu poate fi garantată și există oricum o penalitate în performanță în momentul folosirii lor.
Detecție și corecțieExistă un număr mare de utilitare care
permit detecția și corectarea nealinierii partițiilor.
În cazul Windows cel mai ușor putem verifica offset-ul din System Information (Start > msinfo32). Dacă navigăm către Components Storage Disks, în partea de jos putem vedea partition starting offset.
Pentru Linux se poate folosi utilitarul fdisk astfel : fdisk -u -l /dev/sdX
programareAlinierea partițiilor în medii virtuale
27www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE programare
De nenumărate ori am observat că echipele ajung să își definească un număr foarte mare de extension points la aplicația la care lucrează, chiar dacă acest lucru nu este necesar. Putem foarte ușor să compa-răm aceste puncte de extensie cu filoanele de aur. Fiecare filon de aur este extrem de valoros, crescând valoarea minei (aplicației)), dar în același timp echipa poate să ajungă să sufere de febra aurului și să încerce să definească puncte de extensie și în locuri unde nu avem nevoie de acest lucru.
Punctele de extensie îți permit să creezi aplicații software care să nu aibă legături strânse între componente sau dependințe externe. În cazul în care componentele sunt strâns legate între ele, va fi foarte dificil să înlocuim sau să modificăm o componentă din aplicație. Dacă nivelul de cuplare este ridicat, în momentul în care înlocuim o componentă din aplicația noastră cu o altă implementare, putem să generăm un efect de domino și să fie necesar să modificăm nenumărate alte componente.
Există diverse moduri prin care putem să creăm puncte de extensie. De la cele mai simple, care nu necesită modificări majore ale claselor până la cele complexe care implică la rândul lor crearea diferitelor
clase ajutoare. În rândurile următoare vom prezenta câteva moduri de creare a puncte-lor de extensie.
Cel mai simplu exemplu de creare a unui punct de extensie este ilustrat la un exercițiu de TDD Kata. În cadrul exem-plului respectiv era nevoie ca valoarea unui parametru să fie validată, iar în cazul în care această valoare făcea parte dintr-un domeniu predefinit, atunci trebuia să se execute o anumită acțiune.
public class Calculator{ private string baseValue; ... public void Add(string value) { if (value==null || value.Count == 0 || value == „-”) { baseValue = baseValue + „-”; } ... }}
În acest caz, din momentul în care începem să scriem validarea ne dăm seama că domeniul s-ar putea modifica. Pentru a fi pregătiți în fața schimbărilor care se pot declanșa în viitor, putem să extragem
validarea într-o metodă separată. Deși acesta pare să fie un pas extrem de mic si simplu, acesta poate să fie primul pas spre crearea unui punct de extensie mult mai complex, folosind o metodă virtuală, un serviciu extern sau un modul separat care să se ocupe doar cu validarea datelor.
public class Calculator{ private string baseValue; ... public void Add(string value) { if (ContainsDefaultValue(value)) { baseValue = baseValue + „-”; } ... }
Este extrem de important să apreciem corect momentul creșterii complexității unui punct de extensie. În momentul în care remarcăm necesitatea unui punct de
Extension Points
În acest articol vom descoperi punctele de extensie într-o aplicație enterprise. Bineînțeles că aceste puncte de extensie se aplică pentru orice fel de aplicație, indiferent de mărimea acestora. Cu cât o aplicație este mai mare, cu atât aceste puncte de extensie devin mai importante pentru a păstra calitatea codului ridicată, iar costul unei schimbări să fie cât mai redus. De foarte multe ori,
adăugarea unui număr prea mare de puncte de extensie într-o aplicație simplă va duce doar la creșterea complexității codului, fără a aduce o valoare reală aplicației în sine. Despre over-engineering , vom completa cu mai multe detalii în rândurile următoare.
28 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
extensie la codul pe care l-am scris, am putea într-o primă etapă să îl extragem într-o metodă separată, după care să luăm în considerare eventualitatea creării unui punct de extensie.
Bineînțeles, când începem să lucrăm la o aplicație de dimensiuni mari, știm de la bun început funcționalitatea pe care fiecare componentă trebuie să o ofere și modul prin care acestea trebuie să fie pre-gătite pentru a putea să fie modificate cât mai ușor.
Moduri prin care putem să creăm punct de extensie sunt nenumărate și de foarte multe ori când definim un punct de extensie ne folosim de mai multe meca-nism, nu doar de unul singur.
InterfețeUna sau mai multe interfețe defi-
nesc contractul. Prin intermediul acestui contract se facilitează înlocuirea unui componente cu o altă componentă fără să fie necesar să facem modificări în compo-nentele care o foloseau.
Clase abstractePrin intermediul claselor abstracte
putem să definim punctele de extensie într-o manieră asemănătoare cu cea a interfețelor. Diferența majoră pe care o avem în momentul care folosim clase abs-tracte este că limităm funcționalitățile pe care o componentă le poate expune prin intermediul unei clase (în cele mai multe limbaje de programare, o clasă poate să extindă cel mult o clasă abstractă). Totodată acestea ne ajută pe partea de versionare, având posibilitatea oricând să adăugăm o funcționalitate nouă în clasa de bază fără breaking code.
Metode virtualeNe permit definirea unui comporta-
ment default pe care un punct de extensie poate să îl aibă. Dacă este nevoie, cel care creează un punct de extensie poate să suprascrie metoda virtuală și să definească un alt comportament.
ModuleUn punct de extensie poate să fie repre-
zentat printr-un modul care să permită ușor înlocuirea altor componente , fără să fie necesară recompilarea sau reinstalarea aplicației. Putem să avem unul sau mai multe module care să fie pentru același punct de extensie al aplicației noastre. În orice moment, aplicația poate să decidă ce modul înregistrat să folosească pe baza unei
comenzi externe sau pe baza unei logici interne pe care o are deja implementă.
ServiciiServiciile pot să ruleze în același proces
ca și aplicația noastră sau pot să ruleze într-un proces separat pe aceeași mașina sau pe o mașină diferită. În momentul în care se ajunge la declararea unui astfel de punct de extensie, de foarte multe ori suntem deja în faza când o altă echipă poate să lucreze la implementarea unui serviciu fără să fie nevoie să discute cu echipa de bază.
Fișiere de configurareDeși pare ciudat, un fișier de confi-
gurare în format XML sau JSON poate să conțină definiția unui punct de extensie și comportamentul pe care dorim să îl avem. De exemplu, putem să avem mai multe fișiere de configurare, unde fiecare fișier conține o expresie regulară pentru valida-rea aceluiași șir de caractere. În funcție de fișierul folosit, validarea și acțiunea în sine poate să difere.
La baza punctelor de extensie stau design patern-urile, fără de care ne este aproape imposibil să le creăm și să le folosim.
Atunci când lucrăm la o aplicație, este important a nu se forța apariția punctelor de extensie. În acest mod, menținem com-plexitatea aplicației la cel mai mic nivel posibil. Totuși, în timpul dezvoltării va fi necesar ca de nenumărate ori să refacto-rizăm aplicația pentru a putea adăuga și suporta punctele de extensie de care avem nevoie.
Din această cauză este bine să identifi-căm punctele de extensie într-o fază cât mai incipientă, pentru a putea reduce cât mai mult costurile și pentru a le putea extrage într-un mod optim. E important ca punc-tele de extensie majore să fie identificate la faza de design, nerecomandândiu-se desco-perirea lor în momentul în care s-a început implementarea acestora.
În general, toate dependințele externe pe care o aplicație poate să le aibă trebuie văzute ca puncte de extensie. Din păcate această abordare poate să crească mult complexitatea sistemului. Un bun exemplu sunt operațiile I/O. Deși teoretic, putem în orice moment să schimbăm stack-ul pe care îl folosim pentru a accesa discul, în general acesta nu se schimbă. Totuși operațiile de I/O se grupează într-o com-ponentă unică din mai multe motive, dintre care menționăm reutilizarea codului sau simplificarea acestuia.
În cazul aplicațiilor de dimensiuni mari, pe lângă crearea de puncte de exten-sie pentru fiecare librărie sau serviciu extern care este folosit de către aplicație, există deja o listă de puncte de extensie despre care putem afirma că sunt canonice. Aceste puncte de extensie nu lipsesc din aplicațiile de dimensiuni mari și este nece-sar să ne gândim la ele din faza de design.
TracingOrice aplicație, indiferent dacă rulează
sub Linux sau Windows, are nevoie de un sistem de logging. Acesta trebuie să ne permită să logăm orice fel de conținut din cadrul aplicației noastre indiferent de modulul în care suntem. Totodată este necesar să putem controla locația unde acest conținut se scrie. Un sistem de logare ideal ar trebui să ne permită să schimbăm locația unde informația se scrie și să adă-ugăm locații noi cu modificări minime asupra codului. De exemplu, să putem scrie informația atât în fișiere, cât și într-o bază de date sau într-un serviciu precum Service Bus. Pe lângă aceste proprietăți, acesta tre-buie să ne permită să formatăm textul și să îl filtrăm. Din această cauză, este bine să abordăm sistemul de tracing ca pe un un extension points și să fim mereu pregătiți să îl putem înlocui cu costuri minime. Acest punct de extensie ar trebui să ne permită să controlăm formatarea textului, ascultătorii (să putem adăuga 1..n listeneri) și să filtrăm informația care se logează.
Data accessUn alt punct de extensie extrem de
important într-o aplicație este data access provider. Orice aplicație are nevoie de o bază de date, indiferent de tipul ei – relațională/non relațională. Chiar dacă la prima vedere, am putea să spunem că nu va fi nevoie niciodată nevoie să înlocuim o bază de date cu o altă bază de date, trebuie să fim conștienți că la un moment dat va trebui să facem upgrade la o nouă versiune de bază de date. Acest update s-ar putea să cuprindă și modificări ale provider-ului, care vor putea fi mult mai ușor făcute, dacă punctul de extensie este pregătit cum trebuie.
CachePe lângă o bază de date vom avea
nevoie și de un layer de cache. Pe piață, la ora actuală există nenumărate soluții, dar în comparație cu o bază de date, ris-cul schimbării provider-ului de cache este destul de mare când dezvoltăm o nouă
Extension Points
programare
29www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
versiune a aplicației. De aceea, de la înce-put este necesar să ne gândim la un punct de extensie pentru sistemul de cache, care să ne permită să facem management la entități într-un mod cât mai generic, să putem controla modul în care datele expiră și mecanismul de encriptare, dacă este necesar. Dacă folosim un provider extern pentru cache atunci s-ar putea să dorim să encriptăm toate datele pe care le salvăm în cache.
Criptare Partea de criptare a datelor apare în
orice aplicație care lucrează într-o formă sau alta cu date. Există nenumărate moduri prin care putem să criptăm datele folosind chei simetrice sau să algoritmi de hash. Din această cauză este bine să pornim de la premisa că acest algoritm va fi schimbat cel puțin odată. În funcție de date, s-ar putea să ne trezim că este nevoie să folosim ser-vicii care se ocupă de criptarea datelor. În acest cazuri, punctele de extensie definite din prima fază a dezvoltării ne vor fi foarte utile.
ValidareValidarea datelor și a comenzilor face
parte din fiecare aplicație cu sau fără UI.
La un moment dat, fiecare aplicație are nevoie să facă o validare a datelor de input pe care poate să le primească de la un ser-viciu, să le citească dintr-un fișier sau de la utilizator. Dacă știm că procesul de vali-dare este complex sau este mai mult decât o validare trivială, atunci definirea unui punct de extensie pentru acest lucru este necesară. În faza inițială putem să avem o interfață, atribute sau o clasă generică care să se ocupe de validare, pentru ca ulterior să complicăm punctul de extensie cu noi funcționalități.
SecuritateAutentificarea, autorizarea și accesul
la date și diferite funcționalități se face aproape întotdeauna controlat. Totodată, la ora actuală trebuie să fim pregătiți să suportăm diferite modalități de autentifi-care, de la Active Directory, la Facebook sau la cel clasic cu user și parola. Din acest motiv, avem nevoie de un puncte de exten-sie care să ne permită să facem autentificare și autorizarea utilizatorilor.
Managementul și controlul la punctele de extensie se poate face în diferite moduri, de la diferite factory-uri până la diferite framework-uri de dependency extesion. Niciodată o componentă ce folosește un
punct de extensie nu ar trebui să știe detalii de implementare ale acestuia sau numele său specific. Un sistem de dependency injection sau factory ar trebui să rezolve aceste probleme. În caz contrar, nu am rezolvat nicio problemă prin crearea punc-tului de extensie.
ConcluzieLista cu toate punctele de extensie pe
care le putem defini este extrem de lungă. Cu cât o aplicație este mai mare, cu atât componentele ar trebui să fie mai decu-plate, iar punctele de extensie mai clar definite.
Articolul este structurat în jurul con-ceptelor uzuale din Scrum. Majoritatea conceptelor apar în ordinea în care am început să lucrăm cu ele.
ContextÎnainte de toate cred că este important
să stabilim contextul în care Scrum fost aplicat în cazul nostru. Echipa noastră a fost solicitată să transfere o suită de aplica-ţii consacrate spre tehnologii și platforme noi. A fost clar de la început că acesta este un proiect pe termen lung. Mai mult decât atât, nu a fost preconizată o lansare oficială în primul an de dezvoltare.
Am avut timp să investigăm noile teh-nologii și să implementăm un prototip. În timpul acestei faze nu am avut planning și nu am lucrat în sprint-uri. Părți ale proto-tipului au fost ulterior preluate în proiectul propriu-zis.
PlanningScopul planificării a fost să oferim un
fel de predictibilitate pentru product owner. Odată ce am avut un set de cerințe bine definite aveam nevoie de o estimare: cât de mult timp ne va lua să le implementăm? Pentru că, desigur, product owner-ul apre-cia o estimare doar în timp. În
plus, ne-am dorit să susținem estimarea cu date statistice, pentru că așa ar deveni mult mai plauzibilă.
Product backlogCerințele pentru proiect au fost
descrise în OneNote încă din faza de pro-totip. Informația este organizată într-un notebook partajat pe care OneNote îl sin-cronizează automat astfel ca toți utilizatorii să vadă modificările. Acest depozit cen-tral este, de asemenea, util atunci când se analizează cerințele și se împart în sarcini (sau task-uri). Stochează întrebări și răs-punsuri, rezumatele meeting-urilor în care am discutat problemele deschise cu product owner-ul sau cu alte persoane familiare cu domeniul, cu aplicația existentă și cu funcționalitatea cerută.
Backlog-ul este extras din OneNote. Funcționalitățile (sau feature-urile) sunt prioritizate de către product owner în funcție de cât de apreciate vor fi acestea de către client, deci pe baza beneficiilor aduse clienților. Product owner-ul este, totodată, cel care decide câte funcționalități ar trebui să intre într-o livrare. Noi facem planifica-rea numai pentru funcționalitățile selectate pentru o livrare. Acest lucru nu se întâmplă
Se spune că adoptarea unei abordări agile a gestionării proiectelor software este o călătorie. Aceasta este povestea călătoriei de până acum a echipei noastre din cadrul firmei evoline. Fiind un studiu de caz, nu este o introducere în Scrum și nici
o colecție a celor mai bune practici, ci mai degrabă o prezentare a modului în care aplicăm noi Scrum.
neapărat la începutul fiecărui sprint. De reținut aici este faptul că product owner-ul nu este influențat de planificarea noastră atunci când selectează funcționalitățile. Aceasta este o abordare bazată pe valoare (susținută astăzi de exemplu de mișcarea #NoEstimates) , și nu una bazată pe cost.
Story point-uriUnul dintre avantajele proiectelor
pe termen lung, este că echipa își poate permite utilizarea story point-urilor pen-tru planificare. În echipa noastră story point-urile au fost introduse pornind de la următoarele ipoteze:
• nu vom ști întotdeauna în avans care membru al echipei va lucra pe un anumit task.• planificarea se va face de către
întreaga echipă .
Având în vedere că echipa era și este eterogenă, formată atât din juniori cât și programatori cu experiență, aceste ipoteze ar fi făcut ca estimările în timp să fie foarte dificile. Estimările noastre, sau mai degrabă măsurătorile, bazate pe story point-uri sunt menite să exprime complexitatea, efortul și incertitudinea implicate în finalizarea unei sarcini, indiferent de programatorul care va lucra la sarcina respectivă.
Să presupunem că două pietre, fiecare cântărind 1 kg, trebuie să fie transportate dintr-un punct A într-un punct B, aflate la 100 de metri distanță una de cealaltă, de o “echipă” formată din două persoane, un copil de 3 ani și un adult de 30 de ani. Îi va lua mult mai mult timp copilului să transporte o piatră în comparație cu tim-pul necesar adultului. Cu toate acestea, fiecare piatră este de 1 kg. Lucrurile stau asemănător și cu sarcinile de programare. În consecință, este foarte posibil ca durata implementării unor task-uri măsurate de către echipă ca având 1 story point să fie variabilă.
Task-uri de referințăÎnainte de a începe planificarea am
căzut de acord asupra unor task-uri de referință. Acestea sunt task-uri la care sunt raportate toate celelalte. Am ales niște task-uri implementate deja în prototip, des-pre care întreaga echipă avea o înțelegere comună și le-am asignat story point-uri din secvența de numere utilizată în planning poker. Întreaga secvență este 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 și 100, dar am folosit numai valori sub 5.
Valorile din secvență sunt considerate
categorii sau mărimi cuantificate.
Măsurarea task-urilorPentru măsurarea task-urilor inițial
ne-am decis să utilizăm planning poker. Aceasta este o tehnică binecunoscută pe care nu am de gând să o prezint aici. Am început însă să ne lovim de limitările sale pe măsură ce echipa creștea: ne lua din ce în ce mai mult timp. Din fericire, am dat peste o alternativă numită Silent Grouping prezentată de Ken Power. Din descriere reieșea că este o metodă mult mai rapidă decât planning poker, așa că am decis să o încercăm și noi. Şi a funcționat. Silent Grouping este descris în detaliu în [1].
Pe scurt, iată cum se aplică. În primul rând trebuie aleasă o secvență de numere pentru măsurători. De obicei aceasta este șirul lui Fibonacci, dar am preluat variația ușor modificată de la planning poker menționată deja în paragraful precedent. Fiecare număr al secvenței este reprezentat de o coloană pe un panou sau whiteboard. O zonă suplimentară numită parcare este, de asemenea, introdusă pentru task-uri la care nu se ajunge la un consimțământ. Toate task-urile care vor fi măsurate sunt scrise pe stickere. După această pregătire, urmează trei runde facilitate de un coor-donator. Primele două se desfășoară în liniște, discuțiile nu sunt admise, de unde și numele.
În prima rundă, fiecare membru al echipei se deplasează, unul câte unul, până la whiteboard și pune un task în coloana în care crede că își are locul. În acest fel toate task-urile vor ajunge pe whiteboard într-o coloană inițială. În a doua rundă toți mem-brii echipei sunt prezenți la whiteboard și pot muta task-uri din coloana în care se află în cea în care cred că se potrivesc mai bine. În cazul în care un task este mutat frecvent coordonatorul îl va parca, firește, în par-care. Noi înregistrăm mutările pe sticker: la fiecare mutare tragem o linie. Ultima rundă este rezervată pentru discuții. În cazul în care parcarea nu este goală acum este momentul pentru a diseca task-urile din aceasta și pentru a găsi coloana cores-punzătoare fiecăruia.
Mai trebuie menționat faptul că ne rezervăm o zi sau două pentru a identifica task-urile care urmează a fi măsurate pe baza cerințelor. Mai mult decât atât, fiecare task este prezentat pe scurt echipei în prin-cipal din punct de vedere funcțional înainte de sesiunea de planificare.
Nu toate task-urile sunt distribuite la întâmplare membrilor echipei în timpul
primei runde. În cazul unor task-uri foarte specifice, cum ar fi cele legate de baza de date sau de interfaţa grafică, știm în avans cine va lucra la ele și lăsăm aceste persoane să plaseze task-urile în coloana inițială. De obicei, aceste task-uri nu-și schimbă poziția în runda a doua.
VelocityVelocity-ul este cea mai importantă
metrică pe care o folosim. Îl măsurăm continuu în scopul de a prognoza și de a colecta datele istorice necesare pentru a susține estimările noastre.
Având în vedere mărimea backlog-ului și velocity-ul, ambele exprimate în story point-uri, putem calcula numărul de sprint-uri necesare pentru implementarea backlog-ului. Am profitat de acest lucru atunci când a fost specificată pentru prima oară o dată de lansare. L-am informat pe product owner că cel mai probabil nu vom putea livra întregul backlog pănă la data respectivă. Nu a fost prea fericit când a aflat, dar în cele din urmă am analizat împreună backlog-ul și am amânat task-urile pe care le-a considerat mai puțin importante pen-tru prima versiune.
Alegerea velocity-ului pentru calculul de mai sus nu este întotdeauna clară după mai multe sprint-uri. Voi descrie două metode.
În cazul de mai sus în care a fost spe-cificată data lansării primei versiuni, am ales cea mai recentă valoare. Până atunci, velocity-ul crescuse continuu, astfel argu-mentul meu a fost: “Uite, chiar și cu cel mai mare velocity al nostru de până acum ne va lua cel mai probabil cinci sprint-uri să terminăm backlog-ul și sunt doar trei dis-ponibile până la data limită”. Cea de a doua metodă ia în considerare mediana valorilor
32 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
măsurate de-a lungul sprint-urilor.În opinia mea, cea de-a doua metodă ar
trebui să ia în considerare doar sprint-uri în care componența echipei a fost în mare aceeași. În cazul în care echipa crește de la 5 membri la 10, velocity-urile anterioare obținute de echipa de cinci persoane sunt foarte puțin relevante.
Feed-backPrimim feed-back cel puțin o dată la
două săptămâni în meeting-urile de follow-up, în care facem demo la ce am lucrat recent. În acest fel putem prezenta evoluția funcționalităților pe parcursul imple-mentării lor și avem posibilitatea de a ne adapta la modificările de cerințe sau chiar la cerințe noi intervenite.
Înainte de fiecare follow-up trimitem un mail product owner-ului care conține dezvoltările recente din proiect. Acest mail descrie tot ce merită prezentat, deci joacă rolul unei agende pentru follow-up. Toată echipa participă la follow-up-uri și fiecare membru al echipei își prezintă contribuția.
Principalul beneficiu al implicării între-gii echipe în aceste întâlniri periodice este că dezvoltatorii și product owner-ul pot interacționa. Sunt clarificate probleme deschise, sunt transmise informații con-textuale legate de funcționalități în curs de implementare iar reacțiile, feed-back-ul sunt recepționate în mod direct și la cald.
System TestAvem sprint-uri dedicate system test-
ului și fixării bug-urilor. Nu avem backlog pentru acest tip de sprint-uri, deoarece majoritatea task-urilor apar în decursul sprint-ului. Folosim un action list în loc de backlog. Acesta este un fișier Excel în care gestionăm bug-urile. Fiecare punct din action list are o prioritate care specifică ordinea în care acestea urmează să fie abor-date. Atunci când este găsit un bug, înainte de a fi introdus în action list, se discută la fața locului cu programatorul căruia i-a fost alocat task-ul aferent pentru a vedea dacă bug-ul poate fi fixat rapid. Dacă se poate, atunci bug-ul nu va mai fi înregistrat. Am preluat această metodă de la Henrik
Kniberg, descrisă în [2]. Scopul urmărit este evi-tarea action list-urilor uriașe, care sunt greu de gestionat și care inti-midează programatorii.
RetrospectivăAm încercat s ă
ținem retrospectivele sprint-urilor în mai multe moduri. Inițial au fost cuplate cu sesiunile de planificare, cu alte cuvinte am încercat să reflectăm asupra sprint-ului trecut înainte de a face planificarea pentru următorul. Am expe-rimentat și cu combinarea retrospectivei cu un team lunch. Aceste încercări nu s-au dovedit prea eficace. În prezent încerc să obțin subiecte pentru retrospectivă într-un mod cât mai puțin sâcâitor. Avem un spațiu dedicat pe un whiteboard unde membrii echipei pot specifica lucruri care:
• ar trebui menținute,• ar trebui îmbunătățite.
Subiectele care apar pe whiteboard în timpul unui sprint vor reprezenta agenda retrospectivei.
Feature ownershipDupă aproape un an de dezvoltare,
în cadrul proiectului au fost identificate o serie de activități la nivel de feature: înțelegerea cerințelor, divizarea acestora în task-uri, identificarea task-urilor care pot fi implementate în paralel, comunicarea în exterior cu părțile implicate în proiect, pentru a numi doar câteva. Cum de-a lun-gul anului și echipa a crescut considerabil, mi s-a părut că a sosit momentul oportun
pentru introducerea unui nou rol care să acopere aceste activități, rolul de feature owner. În prezent un feature owner are o privire de ansamblu asupra unui feature și este la curent cu task-urile asociate, cea ce ajută echipa în a fi auto-organizată.
Ce urmează?Cred că transparența și previzibilitatea
de care am dat dovadă a dat roade. Product owner-ul pare să aibă încredere în noi, din moment ce ne-a solicitat de curând proto-tipuri pentru proiecte noi, complementare. În cazul în care aceste proiecte se vor mate-rializa, ele vor reprezenta oportunități excelente de creștere în cadrul departamen-tului nostru.
Există, desigur, mai multe aspecte care pot fi îmbunătățite. Una dintre ele este divizarea funcționalităților în task-uri mai mici, având aproximativ aceeași mărime. Până acum am reușit doar să evităm task-urile de peste 13 puncte, dar mai este până la obținerea unui backlog care să conțină doar task-uri de două sau trei story point-uri sau chiar mai mici. Cu un asemenea backlog,velocity-ul ar putea fi calculat ca și numărul de task-uri implementate într-un sprint. În scopul exersării divizării funcționalităților în task-uri foarte mici îmi propun să folosim exercițiul Elephant Carpaccio, inventat de Alistair Cockburn. Henrik Kniberg a scris un ghid de facilitare al acestui exercițiu disponibil în [3].
Follow-up-urile iau din ce în ce mai mult timp, asemănător cu sesiunile de planning poker pe care le-am avut în trecut. Suntem pe cale de a introduce follow-up-uri la nivel de feature, care să se concentreze asupra unui singur feature și la care să
managementScrum în practică: un studiu de caz
33www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
participe doar membri din echipă care sunt implicați în dezvoltarea feature-ului respec-tiv. Vom organiza, de asemenea, demo-uri interne mai informale pentru a ține echipa la curent cu evoluția proiectului.
Story map-ul, o tehnică descrisă de Jeff Patton în [4], ne va permite să vedem ima-ginea de ansamblu a proiectului.
Story map-ul încearcă să mențină contextul în care task-urile trebuie imple-mentate. Acest context reiese în urma discuțiilor cu product owner-ul și cu alte părți implicate în proiect, discuții în care devine clar de ce anumite funcționalități sunt necesare și ce capabilități acoperă acestea. În plus funcționalități mari sunt descompuse în unele mai mici, în sco-pul de a le capta mai bine. Tot acest context este deseori pierdut atunci când funcționalitățile sunt divizate în task-uri care sunt introduse într-un backlog „plat”.
Steve Rogalsky ne oferă un ghid despre cum să creăm un story map în [5] (ilustrația este de acolo).
Referințe[1] Power, K. Using Silent Grouping to Size User Stories. (2011) http://systemagility.com/2011/05/22/using-silent-grouping-to-size-user-stories/[2] Kniberg, H. Scrum and XP from the Trenches. (2007) [3] Kniberg, H. Elephant Carpaccio faci-l i t a t i o n g u i d e . ( 2 0 1 3 ) h t t p : / / b l o g .c r i s p . s e / 2 0 1 3 / 0 7 / 2 5 / h e n r i k k n i b e r g /elephant-carpaccio-facilitation-guide[4] Patton, J. The new user story backlog is a map. (2008) http://www.agileproductdesign.com/blog/the_new_backlog.html[5] Rogalsky, S. How to create a User Story Map. (2012) http://www.agileproductdesign.com/blog/the_new_backlog.html
34 nr. 18/Decembrie | www.todaysoftmag.ro
startups
În mod natural, creșterea numărului startuper-ilor a generat, în comunitate, o atmosferă ușor competitivă între organiza-torii de evenimente. Atât Startup Weekend, cat și Startup Live au revenit în forță cu câte o a doua ediție, mult mai mari și mai bine organizate decât precedentele. Mai ales că au beneficiat de ajutorul generației anterioare și de vizibilitatea obținută de câștigătorii primelor ediții. Existau și eve-nimente noi, de exemplu Open Connect, care își propunea să acopere partea de identificare și introducere în comunitate a antreprenorilor începători, interesați de startup-uri, completând astfel eforturile Open Coffee.
Pe lângă evenimentele cu agendă clară și format deja consacrat, au apărut inițiative și concepte mai generice, cu scopuri dife-rite: de la facilitarea interacțiunii necesare construirii unei comunități, Startup
Lounge, la obiective educaționale, Tandem, sau chiar și anunțuri ce prevesteau accelera-toare/incubatoare locale: StepUP, Spherik și NextPhase.
În acest context efervescent, artico-lul din primăvară prevestea o perioadă de sedimentare și stabilizare și sublinia nevoia unor programe de termen mediu și lung care să susțină startup-urile în zona Valley of Death, considerând prematură lansa-rea unor acceleratoare sau incubatoare. Previziuni realiste pentru lansarea unor astfel de programe fiind abia 2014-2015.
Meritul principal al agitației din primă-vară a fost încurajarea celor care cochetau cu ideea lansării unui startup s[ facă primul pas. Lansarea noilor startup-uri a dus la apariția unei noi generații care s-a coagu-lat în jurul evenimentelor, iar acum există un număr minim de oameni pe care putem să-l numim comunitate. De aici înainte se
Ecosistemul startup-urilor din Cluj
Acum zece luni scriam un articol în TSM despre ecosistemul startup-urilor din Cluj. Pe scurt, situația din primăvară era caracterizată printr-o agitație browni-ană, în care toți actorii implicați: startup-erii, organizatorii de evenimente pentru
startup-uri și mediul de business erau cuprinși de buzzword-ul startup și încercau diverse inițiative proprii pentru a fi în trend. În urmă cu un an sau doi, nu existau startup-uri cu vizibilitate în piață, iar până acum opt luni, startup-urile clujene erau puține și, relativ, la început, mai cunoscute fiind: Squirrly, TXT Feedback, UseTogether, Mira, KeenSkim și ShareYourCart, care au reușit să atragă atenția comunității, mai ales prin obținerea de finanțare din partea unor acceleratoare internaționale. Un efect benefic, parțial datorat și “hype”-ului din jurul acestora, a fost faptul că au scos la lumină și alte idei cu potențial de startup sau clujeni care deja încercau să pună pe picioare un startup.
Inginer interesat și implicat în diverse activități IT, de la dezvoltare, management, până la educație și jurnalistică în cadrul Epistemio, UTCN și TSM
imprimă o distincție clară mai multor evenimente de calitate pen-tru startup-uri și a investitorilor (bineînțeles, atrași de oamenii din comunitate).
Înainte de a reveni la contextul actual și de a analiza în deta-liu ce se întâmplă în ecosistem, merită să menționăm principalele evenimente și evoluții din ultimele 6-8 luni. Există două evoluții majore: evenimentele formale și interacțiunea informală.
La capitolul evenimente stăm foarte bine, având o gamă foarte largă de teme și organizatori: lansări de revistă, evenimente busi-ness mari organizate de clusterul IT (Cluj IT Innovation Days) sau Business Days, evenimente tehnice sub egida principalelor comunități profesionale din Cluj (de ex. ITCamp), evenimente organizate pentru studenți de către studenți (#defineCluj) și multe altele. Majoritatea acestor evenimente a implicat scena startup-urilor clujene prin sesiuni de pitching și prezentări. Surprinde și diversitatea mare a partenerilor de dialog: mediul de business
local și internațional, universitățile, administrația locală, studenții. Numărul mare de evenimente și actori implicați confirmă statutul de buzzword și vizibilitatea mare a startup-urilor, fără a oferi garanții asupra calității ecosis-temului și măsurii în care acest trend creează plus valoare.
Pe de altă parte, la capitolul interacțiune informală a apărut un salt calitativ. Piața a evoluat la un nou stadiu, mai ales datorită naturii foarte dinamice a startup-urilor. Toți cei care au trecut printr-un proces de accelerare, fie au validat idei și au început să atragă clienți, fie au inva-lidat ideea și au pivotat sau au renunțat. Rezultatul este pozitiv în ambele cazuri, fie prin produse care produc plus valoare, fie prin oameni care au acumulat un set de experiențe și competențe și le reinvestesc într-un al doilea startup sau în mediul de business local. Mai ales în com-paniile IT, care au nevoie de o tranziție dinspre serviciile de outsourcing spre dezvoltarea de produse. Interesant este aici mixul între dinamism și colaborare, cerut de viteza mare de schimbare și adaptare, în contextul unor resurse foarte limitate, rezultând nevoia unui mediu colaborativ cu schimb constant de informații. Practic, în urmă cu doi ani, startup-erii se întâlneau la evenimente mari sau auzeau vag unii de alții, pe când în ultimele șase luni au apărut interacțiuni foarte strânse, ajungându-se la schimb de informații, clienți, recomandări, chiar și la reunirea eforturilor în startup-uri noi.
Concluzia ultimelor șase luni este că majoritatea acto-rilor din mediul social au devenit interesați de fenomenul startup-urilor, iar cei din prima linie, au făcut un salt evo-lutiv spre validarea/ invalidarea ideilor și sedimentarea cunoștințelor pentru a ataca alte idei.
Revenind la statusul actual, există trei mari grupe de actori implicați: comunitatea startup-erilor, organizatorii de evenimente dedicate acesteia și actorii din alte domenii care interacționează cu antreprenorii din startup-uri. În cele ce urmează ne vom opri asupra fiecărei categorii.
Comunitatea de startup-uri, din Cluj, este într-un proces de creștere puternică. Dovada cea mai clară este numărul acestora: cel puțin 35 (față de aprox. 10 știute în primăvară). Număr care reflectă doar startup-urile ce par-ticipă activ în comunitate sau au reușit, prin numărul mare de clienți, să devină cunoscuți. Un exemplu edificator în acest sens este Moqups, un startup prezent pe lista de reco-mandări a lui Steve Blank, vizibil în presa internațională, dar care nu a prea intrat în contact cu comunitatea locală.
Putem doar să presupunem că există mai multe inițiative de acest gen, care fie au succes, fie nu, dar nu sunt vizibile în piață.
Bineînțeles că numărul mare de startup-uri înseamnă și o dinamică mai mare a pieței, iar toamna a adus cu ea și primele startup-uri închise. Era timpul să simțim și noi eșecurile pe pie-lea noastră, nu doar să le citim pe bloguri internaționale. Pentru cei care se plâng de lipsa de bani, momentul adevărului: nu lipsa finanțării a stat în calea reușitei acestor startup-uri. Ce rămâne din aceste eșecuri e experiența celor trecuți prin ele, experiență care va fi un sol mănos pentru următoarele valuri de startup-uri.
O a treia categorie de startup-uri ar fi cele care au pivotat. Sunt mai puține astfel de exemple, dar sunt reprezentative pen-tru reziliența și adaptabilitatea la dinamica constantă, atât ai factorilor interni (echipa, finanțarea, viteza de execuție), cât și ai celor externi (adopția în piață, nevoile utilizatorilor, concurența),
36 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
startups
necesare succesului.Bilanțul aproximativ din acest moment
este: 20 startup-uri cu produs lansat pe piață, 16 care își vor lansa produsul în următoarele luni, iar 6 au fost închise. Dintre acestea, 5 au participat într-un accelerator, două au găsit investitori, iar restul sunt bootstrapped sau în căutare de investitori. De menționat că există startup-uri care au echipa formată din membri ai comunității clujene (în special partea de development) în combinație cu oameni din alte orașe din România sau alte țări (vestul Europei și SUA).
Evenimentele dedicate startup-urilor au suferit și ele transformări. După o pauză de mai multe luni, Open Coffee renaște sub o altă formă, mai structurat și mai apro-piat de nevoile comunității. Cluj Hub nu a mai organizat Startup Lounge în această toamnă, dar va încheia în curând prima ediție a programului Step Up. Cluj Cowork e din ce în ce mai deschis startup-urilor și evenimentelor dedicate (mărturie fiind organizarea primei ediții Startup Pirates din România). Spherik Accelerator se lan-sează în doar câteva zile și are planificate deja câteva workshop-uri. Tot în decembrie se va deschide și Chaos Computer Club care se poziționează ca un spațiu pentru IT-isti și startup-eri. Iar Startup Weekend și Startup Live sunt deja binecunoscute și își anunță edițiile de primăvară.
Pentru cei familiari cu ecosistemul, se remarcă lipsa Open Connect. Era de așteptat încă din primăvară, ca în procesul de sedimentare și maturizare al inițiativelor, unele să se piardă, atât ca focus, cât și ca relevanță. În momentul de față comunita-tea începe să acopere implicit unele nevoi, cum ar fi atragerea altor startup-eri, iar eve-nimentele mari oferă suficiente ocazii de pitching (Business Days, ITDays, etc), rolul evenimentelor de nivel introductiv fiind mai degrabă unul de facilitare al comuni-cării între membrii existenți si cei noi.
Înainte de a trece la a treia mare cate-gorie de actori, merită menționat că există și programe de nivel regional, național și internațional care influențează comunitatea clujeană. La nivel regional apare interes din partea unor programe de dimensiuni mari, de exemplu Cluj Youth Capital 2015, care vrea să dedice un program startup-urilor. Există și programe naționale care au ales să facă prezentări la Cluj, de exemplu RICAP și Google Export, programe ce ajută pro-iectele de cercetare să facă tranziția spre comercializare, în parteneriat cu companii americane. Startup-urile pornite din zona
de cercetare fiind și unul din principalele subiecte de discuții la conferințele de pla-nificare strategică a investițiilor din fonduri europene, dedicate cercetării, în următorul exercițiu financiar 2014-2020. Dar pe lângă aceste programe formale, startup-erii clu-jeni profită și de evenimentele din regiune, participând la How to Web, ediții Startup Weekend și Startup Live din alte orașe, și chiar la evenimente internaționale, gen Pioneers Festival.
A treia parte componentă a ecosiste-mului o reprezintă partenerii care încep să interacționeze cu startup-urile. Cei mai activi, în această categorie, sunt par-tenerii din mediul educațional, mai exact universitățile. Acestea au răspuns prompt diferitelor oportunități de implicare, por-nind de la aderarea la cluster, până la prezența la evenimente, participarea la discuții și chiar construirea și susținerea unor echipe de studenți, care au avut un real succes la competiții internaționale pre-cum Imagine Cup, Digilent, și au continuat proiectele sub forma unor startup-uri.
O discuție interesată a avut loc la #defi-neCluj (eveniment orientat spre studenții tehnici doritori să înceapă un startup), unde s-a abordat subiectul implicării universităților (UTCN, UBB) în educația antreprenorială. Practic o nevoie, din perspectiva startup-urilor, este găsirea de angajați sau co-fondatori, și neputând concura cu salariile firmelor de IT, sunt obligați să se orienteze spre studenți dori-tori să încerce o inițiativă, înainte de a fi sub presiunea angajării. Pe de altă parte, există proiecte de cercetare care pot deveni startup-uri cu inovații solide, dar în lipsa experienței antreprenoriale în echipă, rămân doar cu obiectivele de cercetare atinse, dar cu potențialul de business nefructificat. O soluție propusă a fost insti-tuirea unei catedre private, în colaborare cu Internațional Business Club Cluj, care să ofere studenților ocazia aprofundării domeniului antreprenorial cu suportul unor oameni de business de succes din mediul local sau internațional.
Sigur și firmele de IT urmăresc ce se întâmplă pe scena startup-urilor, sau ar trebui s-o facă din două motive. În primul rând, marea majoritate a startup-urilor vor eșua și, fondatorii acestora (în cazul în care nu vor avea alte inițiative), își vor caută un job. În al doilea rând, pe termen lung, este foarte probabil ca industria de outsourcing să se orienteze spre dezvoltarea și marketizarea de produse software pro-prii și atunci vor fi la mare căutare product
manager-ii, adică acei oameni care vor ști cum să construiască un produs, să facă cus-tomer development, să îl lanseze și să câștige tracțiune. Iar aceia care vor fi căliți deja în toate aceste domenii sunt startuperii.
O confirmare a acestui interes vine din deschiderea cluster-ului Cluj IT, în calitate de reprezentat al intereselor companiilor IT, spre colaborări cu startup-urile clu-jene. Membrii clusterului sunt mai mereu prezenți la evenimente, de toate dimensi-unile, atât formal, prin proiecte și strategii, cât și informal, prin implicarea individuală în diverse programe de educație antrepre-norială. Dintre aceste programe menționăm Tandem, organizat de GRASP și workshop-urile organizate de JCI în colaborare cu oamenii de business din Cluj. Aceștia din urmă jucând destul de des rolul de speakeri sau mentori ( de exemplu Philipp Kandal și Călin Văduva). Posibilitățile de colaborare fiind multiple, de la schimbul de informații, până la inițiative de HR sau identificarea oportunităților de parteneriat: finanțări, co-fondatori, spin-offs, intraprenoriat sau chiar consum de servicii/produse create de startup-uri.
În final aș menționa administrația locală, care a început să participe la eve-nimente și să gestioneze programe cu vizibilitate mare. Am mai pomenit Cluj Youth Capital 2015, dar să nu uităm gradul foarte mare de accesare al finanțărilor pe SRL-D, cel mai mare din țară cu un total de 1267 din 10220 (locurile doi si trei 1091, 669, fiind ocupate de București și Timiș). Deși lipsesc proiectele de colaborare con-cretă, există vizibilitate și deschidere spre dialog.
Încă lipsesc multe elemente pentru a avea un ecosistem cu adevărat călit. În primul rând nu există povești de succes, obținerea finanțărilor seed (10-50 de mii de euro) care pot fi considerate doar un pas spre succes. Nu s-a ajuns încă la finanțare de tip series A (200-500 de mii de euro) și probabil va mai dura până să vedem una la un startup din Cluj, deoarece un startup în această situație necesită tracțiune și pro-duct-market fit. Nici la partea de clienți și cashflow sănătos nu avem încă startup-uri care să se remarce. Poate Moqups e excepția care generează venituri și este recunoscut în piață. În materie de evenimente și pro-grame suntem pe drumul cel bun, dar mai e nevoie de timp ca aceste inițiative să câștige constanță și să continue să crească nivelul calitativ al conținutului.
După cum menționam la început, piața încă nu este pregătită să alimenteze constant
Ecosistemul startup-urilor din Cluj
37www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
acceleratoare locale, fie prin startup-urile pornite în Cluj, fie prin atragerea altor startup-uri din regiune. Un model care nu a apărut la noi este cel implementat de bul-gari: deși nu aveau o comunitate puternică locală, au înființat două acceleratoare care au trezit interesul masiv al comunităților din regiune, generând un ecosistem activ.
Anul trecut exista o mișcare browni-ană în zona de generare a startup-urilor și lipseau activități în zona “valley of death” (perioada dintre început și monetizare/investiție). Acum se pare că cei care vor să înceapă un startup află ușor la cine trebuie să apeleze pentru îndrumare și intră astfel în comunitate. Activitățile de suport din “valley of death” s-au înmulțit, existând o continuă agitație pe acest palier, atât prin evenimente, cât și prin activități ad-hoc, motiv pentru care ar trebui încurajate în continuare. Ne încadrăm încă în previziu-nile din primăvară, cu o comunitate locală în plin avânt, o simbioză bună cu activitățile din București, clujenii având acces la ceea ce se întâmplă în capitală: How To Web, TechHub, VentureConnect, și deschidere către piețele internaționale, existând con-tacte cu investitori din Germania, Anglia, Israel și SUA, care vor duce la apariția unor
colaborări în următoarele luni.La nivel de comunitate agitația trebuie
să se mai cimenteze, iar evenimentele și programele să crească calitativ, reflectând astfel experiența acumulată a comunității (ca și consecință benefică va fi apariția/aducerea factorilor investiționali atât internaționali, cât și locali). Un alt aspect care merită îmbunătățit este folosirea mai inteligentă a resurselor existente local. Deși a reușit să capteze atenția universităților, mediului de afaceri și chiar a administrației, comunitatea de startup-uri încă nu a reușit să capitalizeze pe acest interes. Practic avem local un mix între cercetare, educație, resurse financiare și execuție, în zona tech, care ar putea ataca teme și proiecte mult mai ambițioase și inovative, dar încă nu avem experiența necesară să le legăm într-un tot funcțional. Am încredere că o dată trecuți de primele încercări (eșecuri/pivo-tări/exit-uri), startuperii clujeni vor reuși să se orienteze spre astfel de proiecte cu succes.
TODAY SOFTWARE MAGAZINE
38 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
SpotTune a pornit de la o idee simplă care mi-a venit în timpul facultății. După cum bine știți, în perioada aceea toți sun-tem persoane foarte ocupate – și voiam să fac ceva în privința asta. Mi-am lasat imaginația să zboare și așa a apărut, ei bine, ideea – SpotTune. Aveam nevoie de o aplicație cu adevărat inteligentă care să știe să facă lucruri personalizate pentru mine. Voiam să îi pot trimite un mesaj automat prietenei când ieșeam de la facultate pen-tru a ne vedea, sau mamei pentru a pregati masa. Voiam să am telefonul pus pe silent automat în toate locurile pe care le frecven-
tam și cereau asta – conferințe, cursuri, biserică. Voiam să îmi anunț prietenii prin mesaje/mail-uri când ajungeam în anumite locații. Voiam să mi se pornească Wifi automat când ajungeam acasă, pentru că aveam un router – și să mi se oprească conexiunea de date. Poate deja vă regăsiți într-una din aceste situații.
Scenariile de mai sus sunt numai câteva din multele ‘mini-task’-uri care, fără să ne dăm seama, ne mănâncă într-un mod subtil din timp. De aici și ideea SpotTune – tune your spot. Ideea aplicației este de a seta diferite evenimente/acțiuni care să se întâmple în diferite locații și/sau la anumite intervale de timp. Simplu și eficient.
SpotTune încearcă să automatizeze aceste procese șisă intro-ducă fluența în user experience-ul oferit de noile telefoane mobile. Principiul e simplu: setezi o dată, te bucuri de mai multe ori.
Un exemplu simplu. În medie, un posesor de ‘smart-phone’ (de orice fel) își activează sau dezactivează WiFi-ul sau tra-ficul de date de minim patru ori pe zi din diverse motive. Procesul e unul relativ scurt , dar care după foarte puține repetări devine laborios: deblochează ecranul, trage în jos de bara de notificări, apasă pe butonul de WiFi, așteaptă. Durata procesului e de aproximativ 15 secunde, presupunând că nimic nu inter-vine. După un calcul simplu vedem că omul nostru cu ‘telefon deștept’ cheltuie aproxima-
tiv 7 minute pe săptămână ceea ce echivalează cu aproximativ 6 ore pe an de pornit și oprit WiFi-ul telefonului. Cam ciudat să știi
că după un an de zile ai sacrificat 2-3 filme bune pentru a-ți porni sau opri WiFi-ul de la telefon, nu?
Te-ai trezit vreodată în timpul unei opere, în mijlocul celei mai frumoase arii din acea operă, cu telefonul din buzunar dornic să acompanieze orchestra? SpotTune va putea oferi utilizatorului și opțiunea de a-și pune pe silențios telefonul și / sau a trimite un mesaj automat oricărei persoane care încearcă să te contacteze într-un interval prestabilit de timp.
SpotTune îți va oferi posibilitatea să setezi un astfel de proces automat cu doar câteva tap-uri. Singurul scop este acela de a face viața mai ușoară utilizatorului.
Pe lângă aceste opțiuni, aplicația va înregistra și timpul pe care utilizatorul l-a salvat, automatizându-și procesele. Fiecărei acțiuni îi va fi asociat un anumit număr de secunde care va fi adunat și stocat local. Feed-back-ul acesta e un element important care nu trebuie neglijat.
Următorii pași în dezvoltarea aplicației este de a crea aplicația web – pentru a permite utilizatorului de a-și introduce aceste eve-nimente de pe aplicația web, ca mai pe urmă să fie sincronizate cu telefonul.
SpotTune este menit pentru a face viata mai buna utilizatori-lor. Task-urile pe care știe să le facă pot fi combinate – posibilitățile sunt variate. De aceea, pe website-ul aplicației www.spot-tune.com se pot aduce orice sugestii de task-uri care ție, ca utilizator ți-ar face viața mai bună. Lăsați-vă imaginația să zboare!
Un bun profesor mi-a spus o dată: “Dacă trebuie să faci ceva de mai mult de două ori, fă un program care să facă asta pentru tine!” Nu am fost convins în totalitate de acest adevăr la momentul respectiv, dar pătruzând tot mai mult în era tehnologiei am început să fiu din ce în ce mai convins de acest adevăr. Adevărul pe care l-am constatat este că noi „oamenii” stăm foarte
prost la capitolul task-uri repetitive. Şi așa și trebuie să fie – să lăsam tehnologia să se ocupe de ele și noi să ne bucuram mai mult de lucrurile cu adevărat importante.
O scurta recapitulare:Învățarea securității informaționale
prin gamificare nu este un concept nou. De fapt, este chiar destul de vechi, de la începutul internetului. Se numeste CTF-Capture the Flag. Renumita conferință pentru securitate informațională DefCon, are una dintre primele competiții CTF. Dacă doriți un portal de CTF-uri puteți verifica CTF Time pentru a vedea unde are loc o competiție CTF (în industria securității informației). Astfel de competiții sunt organizate de Facultăți de Informatică, companii internaționale sau chiar agenții guvernamentale.
De ce CTF?Cel mai bun mod de a învăța este acela
de a învăța prin practică (hands-on), iar gamificarea excelează la acest capitol, având rezultate foarte bune când vine vorba de îmbunătățirea abilităților/competențelor, educație și pregătire (antrenament).
Învățarea securității informaționale prin gamificare ar spori implicarea studenților/angajaților, ar crește capacita-tea de reținere a informațiilor și ar accelera procesul de învățare.
Pe lângă aceste avantaje, pentru student și/sau angajați este ceva distractiv, provoca-tor și practic.
Competițiile CTF din ziua de azi sunt foarte răspândite și diferite prin concept și design. Pe lângă frumusețea și atmosfera din jurul lor, de apreciat sunt dedicația și efortul echipelor participante la fie-care competiție CTF , dar mai ales efortul celor care concep sistemele și aplicațiile respective.
Cu toate acestea, competițiile au câteva probleme, dar majore care țin de modul în care sunt concepute și organizate:
• Nu durează foarte mult- În ziua de
azi, competitiile CTF durează între 24h și câteva zile, săptămâni cel mult.• Răsfirate și izolate- Nu se organi-
zează întotdeauna pe internet și trebuie să fii prezent în acea cameră/clădire.• Împrăștiate -Se întâmplă peste tot
în lume dar, fiind împrăștiate și scurte, implicit sunt și mici.• Nu au nici o valoare/Nu contează
- Deoarece nu durează foarte mult și sunt izolate, departamentele de Resurse Umane nu cer experiență în asemenea acțiuni când angajează în domeniul securității informației.• Competiții bazate pe un scenariu cu
foarte multe restricții și reguli.• Nu sunt scenarii bazate pe realitate.
O altă competiție CTF ?Noi, echipa din spatele CTF365, am
decis că este timpul pentru a schimba modul în care CTF este conceput și orga-nizat printr-o nouă abordare propulsând jocul la scară mondială.
Scopul nostru este de a crea o replică reală a internetului, unde profesioniști în domeniul securiății informaționale, studenți si entuziaști ai domeniului să aibă posibilitatea de a se antrena continuu pe servere și infrastructuri adevărate create de profesioniști, și nu pe niște servere vul-nerabile. Practic construirea unui internet în Internet unde user-ii pot ,,hăcui,, în voie pe orcine oricând și oricât fără restricțiile internetului real.
Pentru cine este acest proiect?• Red & Blue Teams, specialiști
CERT/CSIRT – Specialiști în securitate ofensivă și defensivă își pot îmbunătăți abilitățile cu ajutorul unor scenarii bazate pe realitate.• CTOs, Administratori de Sistem
– Pot experimenta noi configurații de server și pot vedea dacă acestea pot fi vulnerabile.• Companii de Securitate – Pot testa
WAFs (Web Application Fiewall) sau orice software în dezvoltare, precum și echipamente hardware de securitate• C om p a n i i l e d e For m a r e i n
Domeniul Securitatii – Pot îmbunătăți capacitățile studenților prin testarea lor în situații reale/bazate pe realitate.• Re cr utori – C er t i f icate le de
Securitate sunt foarte importante, dar performanțele candidaților și realizările acestora ca profesioniști în domeniul securității contează cel mai mult într-un interviu.• Organizații de securitate, precum
OWASP – promovează informații legate de securitatea informațională printre web developers .• C o n f e r i n t e l e I N F O S E C –
Participanții vor cu adevarat să se distreze și mai mult, vor ca realizările lor să nu fie în zadar.
Cum e posibil să creezi un internet in Internet?
Ne-am întrebat și noi același lucru, dar se pare că am reușit să ne descurcăm până acum. Deși mai sunt multe lucruri de făcut, Iaas-ul (Infrastructure as a Service) nostru este destul de flexibil și capabil pentru a imita lumea reală.
Flexibilitatea platformei CTF365 per-mite utilizatorilor să-și conecteze propria infrastructură, fie că este cloud based, pri-vată sau stocată pe servere dedicate.
Am demonstrat și în trecut că este posibil să testezi serverele din cloud . Mai mult de atât, am avut un Metasploitable în cloud. Puteți citi acest articol chiar aici pe Rapid7Community.
În Octombrie 2011, am început proiectul HackaServer, o platformă de testare a securității web folosind puterea crowdsourcing-ului.În timp ce dezvoltăm aplicația HaS, am fost nevoiți să căutăm un mod prin care să pregătim un spin-off ( produs secundar, nou,
derivat) în caz că lucrurile nu decurgeau așa cum am planuit. Trebuie să menționez că proiectul HaS nu este încă deschis pentru afaceri din cauza unui simplu motiv: Suntem o echipă foarte mică.
CTF365
startups
TODAY SOFTWARE MAGAZINE
40 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
Companiile și organizatiile pot obține propria lor infrastructură CTF în câteva minute și toate obiectivele atinse de utili-zatorii lor pot fi adăugate la performanțele generale ale angajaților.
Unde suntem acum? În acest moment, CTF365 este în alfa
testing, ceea ce înseamnă că rulează cu un număr mic de echipe (peste ~100 de echipe) și de asemenea există peste 11000 de utilizatori și peste 900 de echipe din toată lumea care sunt gata de joc.
Fiind în stagiul alfa înseamnă că sun-tem încă în faza de dezvoltare, iar cei care au primit acces la stagiul alfa și la viitorul stagiu beta pot experimenta și vedea cum va arăta versiunea versiunea finală .
Mai târziu, când vom începe a îmbunătăți capacitatea hardware vom fi gata de a lasa pe toată lumea să participe.
În etapele alfa și beta majoritatea uti-lizatorilor/jucătorilor sunt experți în securitate de la diferite companii de testare a securitatii, companii de training pe secu-ritate .
Printre recomandări, acceptăm de asemenea și experți Infosec, precum și instructori/profesori Infosec care solicită-acces la faza alfa.
În cazul în care doriți accesul mai devreme, vă rugam să ne informați și vom încerca să vă oferim acest lucru.
Concluzii“Securitatea nu va fi niciodata perfectă,
dar poate tinde către perfecțiune”.Potrivit sursei Frost&Sullivan, se pre-
zice că ocuparea locurilor de muncă în cadrul experților în securitatea informației va crește cu 332,000, încheind anul cu un număr de 3.2 milioane de experți în secu-ritate și ajungând în anul 2017 la un număr
de 5 milioane. Pe lângă profesioniști cu diplomă, există peste 25 milioane de uti-lizatori ai forum-urilor de administrare/securitate/hacking.
Așa cum am mai spus înainte într-un interviu, internetul se dezvoltă mult mai repede decât capacitatea lumii de a oferi administratori de sistem bine pregătiți, precum și programatori profesioniști bine pregătiți în domeniul securității. Există un decalaj tot mai mare între aceste două lucruri, iar cineva trebuie să-l rezolve sau cel puțin să încerce.
CTF365 nu este un joc. Este o platformă de formare pentru experți în securitate și pentru industria TIC, care implementează concepte CTF și influențează mecanicile gamificării pentru a îmbunătăți rata de retenție și a accelera procesul de învățare/antrenare.
CTF365 este un internet în interiorul Internetului unde utilizatorii își vor crea propriile servere și unde vor experimenta servicii ale vieții reale, cum ar fi platformele de microblogging precum Twitter, rețele de socializare precum Facebook sau Google+, servicii de e-mail precum Gmail și Yahoo, pentru ca în final, ei să poată face orice doresc cu aceste servicii.
Spre exemplu, în lumea reală există GoDaddy când vine vorba de înregistrarea domeniului, nu? Noi avem GoGrandpa.365 unde utilizatorii își vor putea înregistra propriile domain.ctf sau domain.365.
Utilizatorii pot învăța noi tehnici ofen-sive sau pot învăța de asemenea și tehnici defensive. Dezvoltatorii Web își pot antrena abilitățile de a crea aplicații stabile și pot învăța cum să îți apere aplicațiile împotriva atacurilor cibernetice.
Experților în securitate, studenților în acest domeniu, dar și dezvoltatorilor web și administratorilor de sistem, CTF365 le
oferă oricând soluții eficiente. Apelând la comparații sugestive- CTF365 este ca un spațiu imens de antrenament al armatei sau ca un simulator foarte scump unde piloții sunt puși în mijlocul unor situații neașteptate/critice, fără a fi vătămați.
Care este secretul succesului aces-tui joc marca King, în contextul în care industria de gaming este într-o continuă creștere, competiţia devenind din ce în ce mai puternică, iar jocuri cu mecanici, design și modele de business noi apar în mod constant? Nu cred că se poate vorbi despre o reţetă care să garanteze succesul, dar uitându-ne la alte aplicaţii (indiferent de specificul lor), putem cel puţin învăţa din greșelile altora, fiind atenţi mai ales la modul în care au reușit să treacă peste pie-dicile inerente în dezvoltarea de software.
Încă dinainte de lansare, se știa că Bubble Witch Saga va fi un joc cu o meca-nică deja clasică. De aceea, am încercat să aducem un element de noutate, și anume povestea. Călatoria (saga) jucătorului a avut un scop multiplu: diferenţierea de alte jocuri de același gen, dar și o retenţie semnificativ mai bună. Această călătorie se traduce pentru jucător atât printr-o creștere a skill-urilor în joc, prin mărirea graduală a dificultăţii nivelurilor sau prin introdu-cerea de blockers (care nu sunt imposibil de depășit), cât și prin interacţiunea cu alţi jucători – prietenii de pe Facebook.
Partea de interacţiune socială a fost unul dintre factorii care a menţinut Bubble Witch Saga mai bine de doi ani în topuri. Prietenii se ajută în joc: își trimit unul altuia elemente ajutătoare precum vie-ţile (sau energie) sau booster-e pentru a trece peste anumite bariere. Elementul
de competiţie este și el prezent, iar unii jucători pot fi motivaţi de obţinerea unui scor mai bun pe un anumit nivel sau de a recupera poziţia de lider atunci când sunt depășiţi de prieteni.
În cazul Bubble Witch Saga, a fost foarte importantă atenţia acordată jucători-lor și mai ales acţiunilor lor din joc. Niciun joc nu este perfect și bug-uri vor continua să apară, iar cum menţionam la început, opţiunile jucătorilor sunt din ce în ce mai multe. Dar prin păstrarea unui dialog con-stant cu utilizatorii, Bubble Witch Saga s-a menţinut sus în topuri. Acest dialog a fost purtat prin mai multe canale, precum gru-purile de fani de pe pagina de Facebook sau rating-urile și comentariile din AppStore și Google Play. Însă cel mai important aspect al acestui dialog a fost existenţa unui sis-tem de tracking bine pus la punct. Foarte mulţi jucători nu sunt dispuși să ofere feed-back în mod direct și pot renunţa la aplicaţie într-o secundă. Bubble Witch Saga a reușit să oprească foarte multe din-tre aceste potenţiale puncte de renunţare la joc tocmai prin acest sistem de tracking. De exemplu, recent am observat că unul dintre nivelurile din joc avea o rată foarte mare de abandon: jucătorii aveau foarte multe încercări la acel nivel, dar cei care reușeau să treacă obţineau cu greu scorul necesar. Soluţia a fost să găsim o nouă versiune pen-tru nivelul respectiv, una nu neaparat mai facilă, dar care a pus mai mult accent pe
folosirea skill-urilor deja dobândite de jucă tor pe parcursul întregii călătorii în joc.
O altă modalitate prin care Bubble Witch Saga se menţine în continuare pe o poziţie puternică este adaugarea în mod constant de conţinut nou. Aici ne referim atât la niveluri noi (la continuarea par-cursului jucătorului), cât și la grafică. De exemplu, pentru Halloween, Bubble Witch Saga a avut o temă nouă sezonieră, în care pe harta de progresie au fost introduse ele-mente specifice acestui eveniment: una din bilele din joc a fost transformată în dovleac, unul din sunetele din joc a fost schimbat într-un râs de fantomă, schelete animate apăreau din loc în loc, iar pe cer zburau lilieci în loc de șoimi.
Şi de Crăciun jocul va fi modificat cu câteva elemente specifice, dar rămâne să descoperiţi voi care vor fi acestea.
De asemenea, este foarte important să se facă o diferenţiere a jucătorilor în func-ţie de punctul în care se află pe parcursul călătoriei lor în Bubble Witch Saga. Pe de o parte, există jucători care ajung aproape de finalul jocului, iar ei vor niveluri noi, vor provocări din ce în ce mai dificile. Pe de altă parte, sunt jucători care se află la începu-tul jocului și care trebuie ajutaţi să ajungă cât mai departe în joc. Pentru aceștia din urmă, de exemplu, un tutorial interactiv care să-i ajute să înţeleagă fără probleme care este scopul jocului este foarte util.
Feature-urile dezvoltate pentru Bubble
Bubble Witch Saga are 26 de luni de la lansarea iniţială pe platforma Facebook și 16 luni de la intrarea pe piaţa de mobile. Cu toate acestea, jocul reușește să se menţină în TOP 10 jocuri pe platforma socială Facebook,iar pe mobile este cel mai popular joc din categoria bubble shooters, bucurându-se în continuare de cele mai bune review-uri și comentarii.
Cum să menţii succesul unui joc mai mult de doi ani
de la lansare?
management
TODAY SOFTWARE MAGAZINE
42 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
Witch Saga s-au axat în primul rând pe jucători, încercând să le ofere o experienţă cât mai plăcută. Una dintre deciziile strate-gice ale companiei King a fost renunţarea la ad-uri în joc, tocmai pentru ca utiliza-torii să se bucure de povestea jocului fără întreruperi.
Această continuitate a experienţei a fost urmărită și asigurată și prin sincronizarea progresului de pe aplicaţia de mobile cu progresul din varianta de Facebook. Bubble Witch Saga a fost primul joc cu acest fea-ture și reprezintă în continuare un exemplu dat de Facebook (despre detaliile tehnice și problemele întâmpinate în implementare v-a povestit colegul meu, Cristi, într-unul dintre numerele anterioare).
Un efect secundar pozitiv al acestei strategii este viralitatea. Jucătorul care revine mai des și se joacă mai mult este mai dispus să recomande jocul prieteni-lor săi, atât prin word of mouth, cât și prin mouse to mouse. Jocul trebuie să îi ofere și această posibilitate și să faciliteze postarea pe Facebook, fără însă a forţa acest lucru și fără ca jucătorul să nu fie conștient.
În același spirit, în momentul în care vrem să dezvoltăm un nou feature pentru Bubble Witch Saga, prima întrebare pe care echipa de dezvoltare o pune este “de ce?” sau, mai degrabă, “ce va câștiga jucătorul din acest feature?” Odată găsit răspunsul la această întrebare, implementarea rămâne o simplă formalitate.
Aici intervine un alt aspect prin care Bubble Witch Saga a reușit să se menţină drept unul dintre cele mai populare jocuri pe Facebook: o echipă extraordinară care lucrează la acest proiect.
Echipa Bubble Witch Saga este destul de mică, fiind formată din zece persoane:
developeri, QA, artist, designer și produ-cer, iar acest lucru reprezintă un avantaj. Fiecare membru al echipei este responsabil de succesul jocului, opinia fiecăruia este ascultată, iar deciziile privind ideile puse în practică în joc sunt luate de comun acord și pot veni de la oricine din cadrul echipei. Mediul de lucru este tot timpul unul plăcut, relaxat, pentru că întreaga echipă știe foarte bine ce are de făcut, iar deadline-urile sunt fixate tot de membrii săi. Mai mult, în momentul în care apare o eroare, este foarte important ca toată echipa să înveţe din greșeli, să comunice transparent și să meargă mai departe.
Cât timp va mai rezista Bubble Witch Saga în această piaţă aglomerată și în con-tinuă creștere? Nu știm, dar cu siguranţă va fi în continuare sus atâta timp cât vom continua să inovăm, să ascultăm și să res-pectăm jucătorii.
George Abramovici
Business Manager @ King România
managementCum să menţii succesul unui joc mai mult de doi ani de la lansare?
43www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE
Datorită acestei instabilităţi provocate de migrarea sau incertitudinea poziţiei pe termen lung a angajaţilor în firmă, s-au ridicat întrebările referitoare la retenţia programatorilor. Ce trebuie să facă manage-rul companiei și departamentul HR pentru a reţine angajaţii valoroși? Cum trebuie să acţioneze și ce trebuie să le ofere pentru a-i stimula să crească odată cu compania și, astfel, să rămână angajaţi stabili?
Într-adevăr, pentru a răspunde la aceste întrebări este nevoie de anumite statistici și experienţe acumulate, însă acestea vor funcţiona sau nu, când vor fi aplicate spre a oferi un răspuns mulţumitor. Altfel spus, angajatorul trebuie să ia pulsul companiei (să își cunoască angajaţii și să fie famili-arizat cu nevoile și dificultăţile pe care le întâmpină aceștia) și să își adapteze per-manent cunoștinţele în domeniu și cele despre piaţa IT în care se desfășoară. Cu toţii știm că în orice sector de activitate principalul criteriu de atragere și păstrare a angajaţilor se referă la factorul financiar. La fel se întâmplă și în sectorul IT, unde pachetul salarial are o însemnătate foarte ridicată. Este foarte interesant, însă, faptul că, spre deosebire de alte domenii, inter-vine un „dar”. Relativismul banilor este dat de o serie de factori care afirmă că pentru un programator nu primează întotdeauna categoric banii. Da, aceștia sunt foarte importanţi (unde nu sunt?) dar, în viziu-nea unui programator pasionat, criteriul material nu se impune aproape niciodată în faţa posibilităţii de a lucra cu tehnologii inovatoare, de ultimă generaţie. De aceea, se poate spune, fără rezerve, că asigura-rea unor tehnologii actualizate la locul de muncă reprezintă o sursă sigură de reten-ţie a angajaţilor și, în oglindă, dezinteresul pentru înlocuirea tehnologiei învechite duce la plecări masive. Dacă privim logic
acest context, putem deduce clar următorul lucru: chiar dacă angajatul nu accentuează la început atât de mult aspectul financiar, ci își focalizează atenţia spre tehnologi-ile noi, tot el este cel care câștigă; nu este vorba de avantaje imediate ci de câștiguri profesionale pe termen lung, întrucât dez-voltarea unor aptitudini conforme cu noile tehnologii conduce la sporirea experienţei, atingerea unui nivel superior de expertiză și, în timp, la creșterea gradată și sigură a salariului.
Pentru companiile care vor să depă-șească barierele dezvoltării determinate de lipsa forţei de muncă este necesar să facă mai mult decât atât. Așa cum au obiec-tive ambiţioase de business, trebuie să aibă îndrăzneala de a investi mai mult în resursele umane. Exemplul Google este binecunoscut și toată lumea acceptă ușor că acolo investiţia în oamenii a adus rezul-tate remarcabile. Cine oare dintre IT-iști nu își dorește să lucreze la Google? Şi totuși, câţi dintre președinţii de companii IT sunt dispuși să facă o investiţie în oameni similară celei de la Google? Google nu s-a bazat pe studii de piaţă privind beneficiile angajaţilor, ci a îndrăznit. A îndrăznit să investească în oameni atât cât a fost nece-sar pentru a crea cultura din care să nu mai vrei să ieși. Google asigură tot ce îţi trebuie ca să trăiești doar în Google, ca în închi-soare sau armată, cu marea diferenţă că la Google îţi dorești să fii “închis”.
Motivele pentru care programatorii aleg să părăsească o companie sunt nume-roase. Ele ţin de pachetul salarial, birocraţia deficitară de la locul de muncă, programul rigid, problemele legate de management, îngrădirea creativităţii sau, de cele mai multe ori, greutăţile întâmpinate în cadrul echipei de proiect în lipsa unui dialog efi-cient, așadar, atmosfera este una opresantă
și sufocantă. Pentru a depăși aceste incon-veniente, board-ul managerial al companiei demarează mai multe strategii în scopul retenţiei angajaţilor. În cele ce urmează, diferite strategii și metode de retenţie vor fi trecute în revistă pentru a vedea viabilitatea lor și, dacă este cazul, pentru a identifica și sugera noi astfel de metode.
Sectorul IT este în prezent unul dintre motoarele economiei, care a reușit să explo-deze în perioadele în care celelalte sectoare erau afectate puternic de criza economică. În condiţiile unui sistem educaţional insu-ficient adaptat la cererea pieţei, creșterea domeniului IT în România a fost susţinută prin două pârghii. Pe de o parte, se anga-jează persoane care abia au absolvit, deci este vorba de angajaţi pregătiţi, dar care mai au de dezvoltat multe aptitudini și de dobândit experienţă. Retenţia în cazul lor trebuie să se manifeste programat, chiar de la începutul jobului (păstrarea lor în firmă, în acest caz, este sinonimă cu „fabricarea” unui profil de angajat calitativ – de fapt angajatorul, prin diverse mijloace, prin formarea personalului își asigură loialitatea pe termen mediu și lung). Pe de altă parte, există persoanele angajate de ceva vreme care au acumulat destulă experienţă ast-fel încât să constituie un target important pentru conducerea firmei. Aceste persoane fiind experimentate, instruite și, de ase-menea, prestând servicii de calitate sunt mult mai greu de reţinut în firmă deoarece cunosc alternativele și standardele dome-niului. În consecinţă, reţinerea lor este mai dificilă în sensul în care sunt cei mai cău-taţi, iar nemulţumirile lor sunt mai greu de satisfăcut. În urma delimitării celor două categorii, putem să caracterizăm angajaţii astfel: cei lipsiţi de experienţă, novicii, se dovedesc a fi adesea egoiști și capricioși (de aceea, mulţi dintre ei nu rezistă foarte
Păstrarea angajaţilor talentaţi, o temă recurentă în IT
Domeniul IT s-a confruntat cu veritabile crize de angajare a programatorilor. Acest fenomen poate fi interpretat ca un paradox întrucât, cel puţin la nivelul opiniei publice (mai mult sau mai puţin avizată), piaţa IT este văzută ca fiind una încă foarte primitoare, nefiind saturată de angajaţi și absorbind în continuare programatori bine pregătiţi care să asigure o infrastructură
solidă acestui domeniu mereu expansiv și din ce în ce mai ramificat. Totuși, la fel ca în politică, s-a înregistrat și în domeniul IT un proces de migrare sau, într-o notă peiorativă, un traseism al programatorilor generat de boom-ul pieţei IT. Acest fenomen migraţionist a apărut în perioada 2006-2008, odată cu venirea în România a unor mari companii precum IBM, Apple, Sonny-Erickson sau Alcatel. Dacă în acea perioadă piaţa era plină de programatori, în prezent sectorul IT este supranumit sectorul cu rată de șomaj zero.
programareprogramare
TODAY SOFTWARE MAGAZINE
44 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
mult sau manifestă un pelerinaj susţinut, de la o firmă la alta) și cei experimentaţi, cu vechime, loialii, care nu migrează de la un proiect la altul sau de la o firmă la alta deoa-rece deja au un anumit statut și au dobândit o anumită maturitate profesională.
Un factor deosebit de important pen-tru a ţine programtorii în priză și la un nivel de mulţumire ridicat este motivarea. Fiind vorba de persoane pragmatice care lucrează după niște pattern-uri fixe, aces-tea au nevoie permanent de imbolduri și de motivare pentru a continua munca fără a scădea ritmul și calitatea. Motivarea intrin-secă ţine de adaptabilitatea fiecăruia și fluctuează, însă, cea extrinsecă, venită din-spre liderii companiei, are un impact mai mare. În acest fel, compania trebuie să ofere un planning provocator, proiecte din care fiecare poate să înveţe lucruri noi și utile. De asemenea, procesul de organizare al proiectului trebuie să fie unul riguros, schi-ţat într-o manieră exactă și profesionistă și bazat pe cele mai inovative tehnologii. Dacă în completarea celor spuse se mai adaugă un mediu de lucru și interacţionare pozitivă, constructivă între programa-tori, cu siguranţă se poate vorbi de încă o metodă de păstrare a angajaţilor în compa-nie. Pentru a evidenţia această metodă de retenţie, este suficient să privim compara-tiv următorul exemplu asupra modului de organizare a proiectelor (metodologia de proiect). Mai demult, pentru a se ajunge la un produs finit, proiectele treceau prin faze numeroase și oarecum „înţepenite”: în ceea ce privește delimitarea temporală, de obicei era vorba de un termen lung; plănuirea în detaliu de la care nu prea existau ulterior portiţe pentru soluţii alternative; arhitec-tura aplicaţiei; implementarea. Această metodologie desuetă poartă numele Watterfall și nu este un bun exemplu pen-tru păstrarea angajaţilor, deoarece intervine plictiseala, rutina și acea constrângere ino-vativă trasată de reguli. În schimb, tehnica metodologiei Agile funcţionează perfect ca modalitate de reţinere a programatorilor – este o metodă de dezvoltare a proiectelor actuală, modernă, care se caracterizează prin perioade scurte de executare, relaţie strânsă între membrii proiectului și coor-donatorul de proiect, comunicare deschisă și adaptativă, atât între angajaţi, cât și cu deţinătorul produsului (designerul produ-sului, cel care a realizat comanda).
Perioadele lungi petrecute de angajaţi în cadrul unei firme sunt date, mai pre-sus de orice, de calitatea umană și socială a grupului și a celui (celor) care conduc/manageriază grupul. Este clasic și actual
când spunem că „angajaţii se alătură com-paniei și părăsesc managerii”.
Să presupunem că la un moment dat o companie primește un candidat deosebit de serios și de muncitor pentru postul de pro-gramator. Într-un timp scurt, se dovedește a fi un angajat extrem de valoros, cu un comportament ireproșabil cum probabil îl au doar 5% din ceilalţi programatori. Însă, inevitabil, survine problema. Persoana în cauză își dorește un parcurs cât mai lung în cadrul companiei dar, fiind onestă, îi pro-pune angajatorului să îi asigure un program flexibil astfel încât să lucreze în mare parte de acasă, deoarece este un familist convins și are nevoie de mai mult timp pe care să-l dedice familiei. Pe lângă aceasta, deja și-a dovedit eficienţa și calităţile. Cum reacţio-nează compania în acest caz? Majoritatea afirmă că asigură flexibilitatea programu-lui, însă, când este vorba de respectarea acestei sarcini, intervin blocaje. Acesta este un punct de cotitură în care cele mai multe dintre companii nu reușesc să gestioneze situaţia, pierzându-și angajaţii valoroși. În schimb, celelalte companii, cele care înţe-leg și aplică nevoile angajaţilor cu adevărat importanţi, îi vor reţine și vor câștiga ser-vicii de valoare pe termen lung.
Mai există o serie de avantaje și faci-lităţi care au rol decident asupra păstrării angajaţilor. Programul trebuie să fie flexi-bil, adică atât timp cât îţi realizezi norma distribuită, poţi să alegi în ce interval orar să lucrezi. Orele suplimentare trebuie să fie recompensate punctual în diverse moduri. Companiile IT care se respectă, asigură angajaţilor centre de documen-tare personală gratuite, atât la sediu cât și pe cale virtuală. Asigurarea unor abo-namente la sală, bazin sau la alte centre sportive ar trebui să devină o prioritate deoarece viaţa unui programator este sedentară, lipsa mișcării putând conduce la scăderea concentrării și a randamen-tului. Complementar, angajaţii trebuie să beneficieze de training-uri, workshop-uri și conferinţe sponsorizate care să le îmbunătăţească softskill-urile, astfel încât să nu se plafoneze. Pentru că oamenii sunt fiinţe sociale, compania trebuie să le ofere un mediu de lucru plăcut, confor-tabil și prietenesc, echipat cu aparate de cafea și suc, diverse jocuri pentru pauzele de muncă și spaţiu de socializare. Chiar dacă aceste facilitări legate de recreere au devenit o obișnuinţă, nemaireprezen-tând nici pe departe o noutate, mai există totuși cazuri în care, în cadrul unor firme, ele se identifică cu principala (și poate unica) modalitate de motivare și reţinere
a angajaţilor. Nu în ultimul rând, relaţia angajator-angajat trebuie să treacă peste barierele ierarhice, să fie bazată pe colabo-rări amicale, ieșirile în oraș într-un cadru informal să reprezinte o obișnuinţă, iar activităţile sportive asigurate de companie să fie cât mai dese deoarece doar spiritul de echipă spontan dezvoltă colegialitatea și prietenia. Spre exemplu, aniversările anga-jaţilor, celebrarea unei reușite în cadrul companiei, „angajatul lunii” sau ceremoni-ile de premiere anuale a celor mai eficienţi angajaţi din cadrul companiei constituie, fără dubii, evenimente care consolidează grupul și plusează decisiv la reţinerea pro-gramatorilor în companiile IT.
Chiar dacă există o bună înţelegere și interacţionare, secondată de lipsa comple-xului de inferioritate faţă de persoanele poziţionate superior din punct de vedere ierarhic, un element-cheie este reprezen-tat de comunicarea faţă în faţă. Astfel, din momentul angajării și, inclusiv, pe toată perioada deţinerii jobului, este imperios necesar ca interacţiunea și comunicarea între angajator și angajaţi să se facă cât mai direct (luând în considerare că ineficienţa comunicării și lipsa feed-back-ului au gene-rat mereu probleme importante și relaţii șubrede). Acest lucru înseamnă evitarea transmiterii informaţiei prin e-mailuri sau prin intermediul terţilor. Abordarea directă reduce birocraţia și crește nivelul de încredere între persoane, iar relaţiile nu au tendinţa de a se depersonaliza, în sensul în care liderii companiei dovedesc autenti-citate și transparenţă – în acest fel câștigând la capitolul imagine și legitimitate, ceea ce plusează esenţial referitor la problema retenţiei.
După cum se poate observa, scopul principal al companiilor trebuie să fie acela de a îngloba angajaţii în cadrul ei. Ca urmare a implementării tuturor strategi-ilor descrise (de socializare, de implicare, tehnice), echipa de management a compa-niei trebuie să fie capabilă să formeze un colectiv puternic și unit din care să rezide avantaje pentru ambele părţi implicate: pe de o parte, firma câștigă stabilitate și nu se va confrunta cu problema retenţiei angaja-ţilor, iar pe de altă parte, angajaţii, care vor munci mai fericiţi, pasiunea profesională nu le este străină și, cel mai important, nu vor avea tendinţe migraţioniste.
Monica Soaremonica.soare@@artwinconsulting.ro
Manager@ Artwin
Păstrarea angajaţilor talentaţi, o temă recurentă în ITprogramare
45www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE programare
Momentul în care începi un proiect nou sau ai vrea să îți scrii propria ta aplicație web, este de obicei urmat de următoarea întrebare: „Care este cel mai potrivit framework pentru aplicația mea?”. Fiecare programator își va forma deja o opinie în această privință. În mod normal se va merge pe o platformă considerată a fi cea mai eficientă și puternică pentru tehnologia respectivă sau cea mai des folosită de echipă,, pentru a păstra o rapiditate relativ previzibilă în procesul de development a proiectului.
Din punct de vedere al tehnologiilor web, părerile sunt împărțite, dar un lucru e sigur, ne aflăm într-o eră în care tehno-logiile JavaScript sunt într-o continuă creștere, iar utilizarea lor se răspândește nu doar pe platformele web ci și pe platformele mobile. Mai mult decât atât, majoritatea dezvoltatorilor web folo-sesc tehnologii JavaScript în crearea aplicațiilor. Meteor este o platformă pur JavaScript care îți pune la dispoziție câteva facilități extrem de utile, printre care:
• One langauge for both client and server side,• Live page updates,• Powerful data synchronization,• Hot code pushes,• Smart packages.
Crearea unei aplicații MeteorMeteor se poate instala foare ușor folosind următoarea
comandă linux/unix:
$ curl https://install.meteor.com | /bin/sh
După rularea acestei comenzi se va putea accesa de la terminal comanda meteor. Cu ajutorul acesteia se poate crea primul proiect Meteor:
$ meteor create myApp
În momentul acesta meteor a creat directorul myApp care conține aplicația web împreună cu o configurație pentru Node.js prin care vom putea porni serverul local pentru a vizualiza pro-iectul într-un browser web:
$ cd myApp $ meteor => Meteor server running on: http://local-host:3000/
Prin rularea comenzii meteor în cadrul proiectului s-a pornit serverul local, iar aplicația web poate fi accesată printr-un IP local la portul specificat în output.
One language for both client and server side
Meteor reușește să îmbine foarte elegant aceeași tehnolo-gie atât pe partea de server-side cât și pe partea de client-side a aplicației. Acest lucru este posibil prin faptul că aplicațiile Meteor rulează pe o instanță de Node.js. Pentru a putea diferenția codul care rulează pe server față de cel care rulează pe client, Meteor vă pune la dispoziție două variabile boleene care să vă ajute în această situație:
• Meteor.isServer specifică blocul de cod care va rula server-side.• Meteor.isClient specifică blocul de cod care va rula
client-side.
Ca o primă regulă best practice nu este recomandată folosirea excesivă a variabilelor precizate mai sus. Se recomandă folosirea structurii de fișiere descrisă în documentație. Toate fișierele care rulează strict pe server se vor crea sub directorul server, iar cele ce vor rula pe client se vor crea sub directorul client.
Astfel, întreaga aplicație poate fi scrisă sub un singur limbaj de programare. Acest lucru este un mare avantaj pentru programato-rii care sunt expuși în proporție mai mare tehnologiilor JavaScript.
Smart packagesMeteor vine cu un sistem de pachete build in, ceea ce permite
folosirea librăriilor externe în crearea aplicațiilor. Acest lucru este posibil cu ajutorul comenziilor:
Printre pachetele disponibile se numără și cele mai folosite librării și tool-uri: jQuery, Backbone.js, jQuery UI, Bootstrap, Less, Underscore etc. . Mai mult decât atât, există un serviciu numit Atmosphere, unde puteți răsfoi printre toate pachetele disponibile sau puteți cauta pachetele dorite. Pachetele de pe Atmosphere se pot instala cu ajutorul unui utilitar de gestiune a pachetelor numit Meteorite.
TemplatesPlatforma Meteor are instalat default un sistem de șabloane
(templating system) cu numele Handlebars. Cu ajutorul acestui sistem puteți oferi un nivel mult mai dinamic paginilor. Acestea vor putea comunica într-un mod foarte elegant cu datele procesate server-side care urmează să fie transmise către view. Momentan Meteor suportă doar Handlebars, dar pe viitor vor fi implemen-tate mai multe opțiuni.
Pentru a folosi template-uri în Meteor trebuie doar să creați un
Real time web with Meteor
Meteor este o platformă open-source pentru crearea mult mai rapidă a aplicațiilor web, indiferent de nivelul de experiență al programatorului.
TODAY SOFTWARE MAGAZINE
46 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
fișier .html în care să introduceți tag-ul <template> împreună cu atributul name care va primi o valoare sugestivă. În acest moment Meteor va evalua fișerul, iar template-ul creat va putea fi accesat prin intermediul unei variabile globale Template.nume_template. Mai mult decât atât, prin sistemul inteligent de sincronizare, Meteor va menține în orice moment datele din view sincronizate cu cele de pe server, iar orice modificare se va vedea instantaneu pe view.
Exemplu de template:
<template name=”hello”> <b> Hello {{ what }} </b></template>
Acum vom putea popula dinamic conținutul template-ului „hello” accesând expresia handlebars numită „what” din interio-rul acoladelor:
Live page updates În ziua de astăzi menținerea datelor pe client la zi cu cele de
pe server este un task la ordinea zilei. Meteor reușește să scutească programatorul de a reinventa roata, iar mecanismul de auto-update este build in în platformă. Acest mecanism actualizează atât HTML-ul generat automat cât și HTML-ul creat manual prin JavaScript.
Mecanismul din spate constă în folosirea unei funcții de randare care este trimisă către Meteor.render care va returna un fragment de DOM numit nod. Acest fragment de DOM se va auto actualiza singur prin intermediul platformei în momentul în care se detectează o modificare în conținut. Meteor.render folosește un concept numit reactive computation pentru a afla care nod trebuie actualizat cu datele noi. Majoritatea aplicațiilor folosesc automat acest mecanism, iar programatorul nu este nevoit să apeleze în mod direct aceste metode. Astfel, paginile mențin factorul de real time updates, iar conținutul este permanent actualizat.
Hot code pushesÎn mod normal când aplicația trebuie să intre în producție sau
se face un deploy pe un server live, acest lucru poate implica un nivel de dificultate sporit. Există o serie de proceduri care trebuie urmate cu mare atenție printre care: portarea bazei de date, opri-rea și repornirea serverului HTTP, verificarea unor posibile erori de deploy, sincronizarea serviciilor, etc. . Un lucru extrem de folo-sitor și de interesant pe care îl oferă Meteor este Hot code pushes. Acesta este un mecanism complet automatizat pentru efectuarea deploy-ului. Tot ce trebuie făcut este să se execute următoarea comandă în cadrul proiectului existent:
$ meteor deploy <host>
Atât! În acest moment proiectul a fost încărcat cu succes pe serverul dorit. Mai mult decât atât, aplicația nu se oprește în tim-pul unui deploy. Meteor se ocupă de toată partea de updates și de menținere a serverului, iar clienții nici nu vor simți deploy-ul.
CollectionsMeteor folosește baza de date de tip NoSQL numită mongoDB.
Aceasta este singura suportată momentan, dar pe viitor vor fi implementate și alte baze de date. Pentru partea de client-side , Meteor folosește un emulator de mongoDB numit minimongo. Cu ajutorul colecțiilor putem manipula documentele din baza de date.
Pentru declararea unei colecții se folosește următoarea sintaxă:
Members = new Meteor.Collection(“members”);
Prin apelarea acestei funcții s-a creat un obiect de tip EJSON care este de fapt un model tradițional dintr-un framework ORM (Object-Relational-Mapper). Colecția Members este declarată glo-bal și este accesibilă atât din partea de client-side cât și din partea de server-side. Asemenea paginilor HTML, modificările colecțiilor sunt propagate în timp real către toți clienții. Astfel, orice modi-ficare asupra bazei de date va declanșa actualizarea colecțiilor distribuite clienților.
Pentru manipularea obiectului collection se va folosi urmă-toarea sintaxă:
În stagiu de dezvoltare baza de date poate fi modificată chiar și de pe partea clientului. Acest lucru este foarte folositor pentru debugging și testare, dar odată ce aplicația atinge un stagiu gata de producție se vor dezactiva pachetele autopublish și insecure care oferă această facilitate.
ConcluzieMeteor este clădit peste o serie de tehnologii de ultimă oră ,
care îmbinate într-un mod foarte elegant, scutesc programatorul de muncă și timp în plus. Astfel, reușește să se concentreze mai mult la alte aspecte ale aplicației decât asupra task-urilor care sunt comune pentru orice proiect. Chiar dacă Meteor nu a atins încă versiunea 1.0, se află într-un stagiu stabil, iar unele proiecte au început deja să migreze spre această platformă. În momentul de față platforma este la versiunea 0.6.6.3, dar în ciuda faptului că a trecut prin mai multe sesiuni de testare automată dar și manuală unele bug-uri mai pot exista.Totodată, Meteor este într-o continuă dezvoltare mulțumită unei echipe de programatori care lucrează full time pentru a oferi schimbări majore în API-uri, cu fiecare update lansat. Chiar dacă nu a atins o primă versiune finală, Meteor este o platformă extrem de flexibilă, puternică și de ultimă generație care trebuie să ajungă în atenția publicului.
În acest context, piața aplicațiilor mobile devine din ce în ce mai dinamică și mai profitabilă (atât pe segmentul entertain-ment, cât și pe cel business) - potrivit unui raport al Gartner1, va valora 74 miliarde de dolari, în 2016.
Însă crearea aplicațiilor mobile implică pentru dezvoltatori anumite riscuri deseori neglijate - riscuri care pot fi relativ ușor de gestionat dacă sunt cunoscute. Iată câteva sfaturi utile.
Protejează-ți proprietatea intelectualăActivul tău cel mai valoros este propri-
etatea intelectualaă care trebuie protejată corespunzător.
Drept de autorCodul sursa, design-ul, interfața
grafică, textul și alt continut original al apli-catiei mobile (imagini, videoclipuri, melodii, etc.) sunt protejate prin drept de autor, de la momentul creării lor. Chiar si “ico-nița” (icon) pe care utilizatorii o accesează pentru a lansa aplicația, poate fi protejată prin drept de autor. Poți lua în considerare să o înregistrezi chiar și ca marcă, dacă vrei să interzici altora să o copieze și să o folosească. Cu același scop, poți înregistra interfața grafică a aplicației (“look and feel”) ca design industrial.
MarcaEste opțiunea ta dacă înregistrezi
1 h t t p : / / w w w . e w e e k . c o m / m o b i l e /apps-marketing-and-the-cloud-gartner-predictions-for-2013/
denumirea aplicației ca marcă (de exem-plu, marca Angry Birds). Chiar dacă nu o înregistrezi, poți face o cercetare a mărci-lor similare sau identice deja înregistrate sau care sunt notorii, pentru a nu le imita – ceea ce ar putea determina, de exemplu, eliminarea aplicației tale din App Store (pe lângă eventuale acțiuni în instantă din par-tea proprietarilor lezați).
Secrete comercialeDezvoltarea aplicațiilor mobile implică
și secrete comerciale (strategii de preț, plan de afaceri sau de marketing, etc.) pe care este recomandat să le păstrezi confidențiale. De aceea, încheie contracte cu angajații, programatorii freelance, potențialii parteneri de afaceri, furnizorii, investitorii (adică cu acele persoane cărora le-ai împărtășit detalii privind aplicația și implementarea ideii), obligându-i să nu divulge informațiile la care au avut acces.
BrevetPoate fi util să afli ce brevete au fost
acordate deja pentru funcționalități tehnice similare aplicației tale.
Știi cine deține drepturile de autor?În principiu, dreptul de autor asu-
pra programului software al aplicației mobile aparține creatorului (programa-torul) din momentul în care scrie codul sursă. însă dacă programatorul scrie codul sursă în calitate de angajat, în exercitarea atribuțiilor sale de serviciu, angajatorul va
deține dreptul de autor – atât timp cât nu există un contract care prevede contrariul.
Probleme mai delicate privind stabili-rea titularului dreptului de autor pot apărea când crearea aplicației este externalizată, realizată printr-un parteneriat sau când implică folosirea unor soft-uri open source.
De exemplu, cand externalizezi pro-cesul tehnic de creare a aplicației către programatori freelance sau către un fur-nizor independent, nu uita să inchei contracte care să menționeze, printre altele, că drepturile de autor asupra soft-ului și a codului sursă îți revin.
Indiferent dacă detii o afacere ce pune pe piată aplicații mobile sau dacă esti un programator freelance care creează aplicații mobile pentru diverși clienți, este recoman-dat să apelezi la un avocat specializat care să îți pregatească contracte standard, avan-tajoase, pe care doar să le adaptezi când este cazul.
Nu încălca drepturile altor persoane Asigură-te că aplicația mobilă pe care
o dezvolți nu imită, fără drept, elementele unor aplicații existente deja pe piată, încăl-când drepturile de proprietate intelectuală ale altor persoane. Dacă vrei ca aplicația să foloseasca un soft, design-ul, codul sursă al altei aplicații (sau chiar alt continut ce nu îți aparține - de exemplu, imagini, muzică), solicită și obține acordul persoanei care deține acele drepturi.
Cum pot fi protejate afacerile cu aplicații mobile?
Creșterea fără precedent a utilizarii telefoanelor cu sistem de operare Android, a iPhone-urilor și tabletelor, a determinat com-paniile să investeasca resurse în aplicații software create special pentru dispozitivele mobile.
TODAY SOFTWARE MAGAZINE
48 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
Alege cu grijă platforma Selectarea platformei pe care va fi distribuită aplicația - iOS
(Apple), Android (Google), Blackberry OS, Windows Store (Microsoft), Facebook, etc. - este o decizie importantă. Este bine să cunoști avantajele si dezavantajele fiecărei platforme, atât aspectele tehnice, cât și pe cele care țin de termenii contractuali.
De exemplu, pentru a deveni dezvoltator autorizat Apple sau Google, trebuie să închei un contract prin care primești o licentă ne-exclusivă care iți permite să dezvolii aplicații mobile ce vor rula pe acea platformă. Fii însă atent la clause, mai ales la cele care:
• îți interzic să folosești aplicația pe o platformă concurentă; • îți interzic să dezvolti aplicații mobile a căror interfața gra-
fică este similară unor aplicații existente deja pe platformă;• Permit deținătorului platformei (sau altor dezvoltatori) să-ți
modifice aplicația fără acordul tau;• Dau deținătorului platformei o licență exclusivă pentru folo-
sirea aplicației tale, etc..
Cât de bine cunoști implicațiile folosirii soft-ului open source?Multi dezvoltatori optează pentru folosirea soft-ului open
source în aplicațiile mobile (caracteristica open source fiind per-misiunea de a copia, modifica și distribui în mod liber). Dar cum există multe tipuri de licențe open source, este util să cunosti ce tip de licentă se aplică utilizarii unui anumit soft open source și care sunt implicațiile de natura comercială ale fiecărei licențe.
Cea mai populară este licența GNU General Public License (GPL)2. Aceasta funcționează pe un principiu simplu: iți permit să folosești codul sursă pe care l-am creat eu, dar și tu trebuie să ne permiți mie și altora să-l folosim pe cel creat de tine pe baza codului inițial.
Acest principiu este impus tuturor utilizatorilor unui cod sursă astfel licențiat; de aceea, termenii licenței GPL pot avea implicații majore.
De exemplu, când dezvolți o aplicație mobilă pornind de la un anumit soft cu licenta GPL, condițiile acesteia se vor extinde și aplicației tale ( astfel, codul sursă al aplicației va trebui pus la dispoziția publicului în condiții similare celor în care ți s-a oferit ție softul). De aceea, poate fi problematic dacă încarci o asemenea aplicație pe App Store, unde regulile iOS sunt incompatibile cu GPL și interzic modificarea și redistribuirea codului sursă.
Aplicația colectează date personale?Aspectele privind protecția datelor cu caracter personal sunt
foarte sensibile în prezent – iar Apple si Google chiar au facut obiectul unor reclamații în acest sens. Primul pas este să stabilești dacă aplicația pe care o dezvolți colectează anumite date cu car-acter personal privind utilizatorii (nume, date de contact, inclusiv informații stocate pe dispozitivele mobile, date ce permit localiza-rea geografică, date ale minorilor, etc.).
Dacă răspunsul este “da”, al doilea pas este să ai o politică con-cretă privind aceste date (privacy policy) care să abordeze, printre altele, modalitatea în care se obține acordul utilizatorilor, detalii privind tipul datelor colectate, dacă sunt distribuite, cui și pentru ce scop, locul stocării, etc. .
ConcluzieImplementarea unei strategii eficiente minimalizează
potențialele riscuri sau, în cuvinte mai simple, paza bună trece primejdia rea.
2 http://opensource.org/licenses/GPL-3.0
Despre autoare: Claudia Jelea este avocat specializat pe aspecte ce implică mediul
online, comerțul electronic și IT&C, mărcile, drepturile de autor și protecția datelor cu caracter personal.
Cum pot fi protejate afacerile cu aplicatii mobile?
legal
49www.todaysoftmag.ro | nr. 18/Decembrie, 2013
TODAY SOFTWARE MAGAZINE programare
A: Crezi că o abordare generalistă poate fi susţinută? Pentru cât timp poate fi sus-ţinută? Este nevoie să ne specializăm în diverse subdomenii?
R: Cred că volumul de muncă a fost suficient de mare încât am avut dintotdea-una nevoie de specialiști. Sunt prea multe aptitudini de cunoscut, dar fiecare are rolul său. Mă întorc mereu la metafora podului. Dacă vrei să construiești un pod, există un inginer. El nu construiește podul, dar semnează pe documentaţie, iar dacă podul se prăbușește, este vina lui. Ai nevoie de oameni care să știe cum să toarne cimentul corespunzător. Ai nevoie de oameni care să știe cum să întindă corect cablurile. Ai nevoie de oameni care să știe cum să toarne asfaltul. Şi aceștia sunt oameni cu anumite aptitudini, sunt tehnicieni. Sunt seturi de aptitudini diferite și ai nevoie de toate astea dacă vrei să ai succes cu podul. Există cu siguranţă un inginer implicat, dar nu este singur. Cred că trebuie să preţuim fiecare aptitudine și că generaliștii trebuie să aibă responsabilităţi specifice efortul general de a realiza software cu succes. Cineva cu un ochi format ca al lor peste întreaga activi-tate este o persoană utilă, dar are nevoie să lucreze cu specialiști pentru a avea cu ade-vărat succes.
A: Crezi că aceasta este o atitudine folositoare care să fie adoptată de tinerii care intră în domeniul acesta? Ar trebui să caute o specialitate în care să se specializeze și pe care să o studieze și să nu se aștepte să cunoască totul despre informatică / ingine-ria calculatoarelor?
R: Nu cred că putem ști totul despre ceva – în primul rând. Trebuie să simţi ceea ce vrei să faci. Şi nu fiecare lucrare de software este un pod. Unul dintre lucrurile care mi-au placut în legătură cu mișcarea smartphone a fost acela că a adus înapoi echipa foarte mică. Trei oameni puteau să își câștige existenţa construind o apli-caţie interesantă. Şi pentru multă vreme
acest lucru era imposibil. Dezvoltarea jocurilor a devenit atât de complexă încât era nevoie de organizaţii precum Electronic Arts cu o sută până la două sute de oameni pentru a scoate un joc care cu adevărat să testeze limitele unui aparat de jocuri video. Dar totul s-a redus la un telefon, și dintr-odată era nevoie doar de un programator bun, un artist bun și un manager pen-tru a rezolva totul și a aduce un venit din care să trăiască toţi. Şi asta e extra-ordinar! Noi făceam asta în anii 80 cu computere desktop și limbaje 4G. Iar faptul că s-a revenit la așa ceva ma interesează cu adevărat. Cred că acum ne aflăm în fazele ultime, când există atât de multe produse pe smartphone-uri încât este din ce în ce mai dificil să ai suc-ces. Cred că cea mai mare provocare pentru un tânăr în ziua de azi este să își dea seama ce stil de lucru preferă. Şi din nou, nu putem presupune că vom rămâne în aceeași carieră. Poţi să rămâi în informatică pen-tru mult timp. Eu așa am facut. Dar nu am avut aceeași slujbă pentru mai mult de un an. Întotdeauna apare ceva nou. Un alt mod de a lucra. Şi cred că asta face parte din a-ţi ghida cariera – să îţi păstrezi privirea la ori-zont și să alegi lucruri noi pe care vrei să le încerci și să te miști în acea direcţie când ai ocazia sa o faci.
A: Deci, dacă înţeleg corect, tinerii ar trebui să experimenteze un pic pentru a vedea ce le place și să avanseze înspre acea direcţie dacă doresc să lucreze în informatică.
R: Şi cred că dacă vor să rămână, trebuie să își dedice un anumit timp pen-tru a vedea ceea ce se întâmplă nou – să decidă ce este important pentru ei, ce vor să încerce în continuare. Există o capcană: devii bun într-o anume abilitate și încetezi să mai înveţi – te concentrezi numai pe acea abilitate. Poţi fi pe acel val pentru mult timp. Începi din vârf și treptat te întorci în
mulţime până când devi tipul în vârstă care păstrează sistemul moștenit. Toate astea cu aceleași aptitudini. După părerea mea, dacă petreci zece ani făcând același lucru în informatică, nu ai dobândit zece ani de experienţă – ci ai doar un an de experienţă, repetat de zece ori. Este mai interesant pentru mine, cred că este o carieră mai distractivă și care te face un muncitor mai valoros, să îţi depășești limitele aptitudi-nilor tale și să explorezi alte aptitudini. Diversitatea te face bun în toate. Nu poţi să le faci pe toate, trebuie să îţi alegi nișele, dar să înţelegi: dacă cunoști numai un sin-gur limbaj de programare, ai o modalitate foarte îngustă de a privi lucrurile. Al doilea tău limbaj de programare va fi o bătaie de cap. Al treilea va fi limbajul care va genera un adevărat progres. Acela va fi momentul când vei începe să vezi întregul în progra-mare și nu doar zahărul de deasupra, care le face diferite. După aceea, al patrulea, al cin-cilea și al șaselea sunt ușoare. Şi alt aspect care are loc în mintea ta este acela că nu îţi mai pasă de limbaje – limbajele nu mai sunt așa de importante. Felul în care gân-dești este adevărat. Şi cum rezolvi probleme este important și asta te face un muncitor mai valoros. Asta nu înseamnă să înveţi
Interviu cu Richard Campbell (II)
Richard Campbell are mai mult de 30 de ani de experienţă high-tech, fiind Director Regional Microsoft și profesionistul cel mai valoros al Microsoft (MVP). El se consultă cu mai multe organizaţii nord- americane de top. Pe lângă faptul că vorbește la con-ferinţe peste tot în lume, Richard este una dintre gazdele „.NET Rocks! Talk Show-ul audio de pe internet pentru Dezvoltatorii
.NET” și gazda emisiunii „RunAs Radio, Talk Show-ul audio de pe internet pentru Profesioniștii IT”.
50 nr. 18/Decembrie, 2013 | www.todaysoftmag.ro
tot. Pur și simplu înseamnă să te axezi pe a avea o perspectivă reală asupra a ceea ce înseamnă o abordare productivă a dezvol-tării de software.
A: Care crezi că este calea cea mai bună de a învăţa? Şi aș împărţi întrebarea asta în două părţi: care este metoda cea mai bună de a învăţa pentru o persoană tânără care dorește să intre în domeniul informaticii? Ar trebui să obţină o diplomă? Sau să stu-dieze pe cont propriu? Şi aceeași întrebare și pentru cineva care este în domeniu de câţiva ani și dorește să avanseze în carieră?
R: Cred că mai întâi de toate trebuie să te cunoști pe tine însuţi suficient de bine pentru a ști cum să înveţi. Care este un mecanism eficient pentru ca tu să înveţi? Una dintre veștile bune este că există mai multe modalităţi de a învăţa în prezent și resurse pentru toate aceste modalităţi. Eu mi-am dat seama de multă vreme că sunt un cititor bun. Că învăţ foarte repede citind și că nu am răbdare cu alte metode de învă-ţare, așa că eu citesc pentru a învăţa. Așa sunt eu. Dacă tu înveţi cel mai bine prin video, există produse extraordinare pen-tru a învăţa prin video. Dacă înveţi cel mai bine în mod practic, există cursuri dispo-nibile pentru tine. Așa că depinde de tine cum dorești să înveţi. Aș spune că multe dintre abordările esenţiale ale programării pe care le avem în prezent au o ștachetă de pornire foarte ridicată. Este o provocare să fi productiv în unele dintre aceste medii de dezvoltare mai mari, așa că s-ar putea să dorești să alegi ceva mai simplu. Pentru a te propulsa peste nivelul de amator – pentru a intra în informatică ca profesie – trebuie să faci asta singur. Nici o diplomă nu te va salva. Când angajez un dezvoltator – rar mă mai uit la aptitudini – de obicei caut două lucruri: pasiune și capacitatea de a lucra cu echipa – cât de bine se poate integra printre oamenii mei? Dacă ai aceste două lucruri, eu te pot învăţa tot restul. Destul de pasio-nat încât, dacă îţi impun un nou limbaj, nu ești doar capabil să te descurci, ci vei fi de-a dreptul încântat să o faci. Dacă îţi dau un cont Pluralsight și îţi spun că „am nevoie să te pregătești să activezi în Aplicaţii Single Page în HTML5” vei face foarte rapid asta pentru că ai video-urile și le poţi viziona cât de mult dorești. Şi să lucrezi bine cu echipa: să apreciezi diferenţele dintre aptitudini și să vrei să lucrezi aproape – acesta pentru mine este cel mai valoros angajat pe care îl pot avea. Şi să realizezi că ambele aptitudini sunt de fapt aptitudini soft – aptitudinea tehnică nu te va mai duce departe – ci abi-litatea de a deprinde noi aptitudini tehnice
este cea care contează. Ne aflăm în această perioadă de transformare în informatică și astfel, aptitudinile pe care le înveţi acum nu îţi vor mai servi la fel de mult peste cinci ani. Dar capacitatea ta de a învăţa acele deprinderi și dorinţa ta de a face asta îţi vor prinde bine.
A: Vorbind despre aptitudini soft – care crezi că este cea mai mare concepţie greșită pe care oamenii din afara industriei noastre o au în legătură cu asta? Lucruri precum „stai toată ziua în faţa calculatorului”, „nu interacţionezi cu oameni”, „poţi să înveţi meseria, iar apoi te-ai aranjat pe viaţă”, ...
R: Există ceva ce se numește efectul Dunning Kruger, care spune că cei mai mulţi oameni știu atât de puţine despre asta încât nici măcar nu știu că nu știu nimic. Şi informatica este adeseori așa. De multe ori suntem în situaţia în care managerii unei organizaţii consideră că dezvoltarea software înseamnă numai dactilografiere. Deci, dacă nu tastezi, nu lucrezi. Şi tre-buie să îi educăm să înţeleagă că nu este așa. Că dactilografierea poate fi extrem de distrugătoare pentru procesul de dez-voltare. Ne poate îndepărta de scop, în loc să ne apropie. Că trebuie să existe un plan și o anticipare. Cred că tocmai să educi oamenii și să îi ajuţi să înţeleagă ce este complicat și ce este ușor – deoarece nu este ceva evident în software – este de cele mai multe ori proba de aptitudine soft. Suntem aproape siguri astăzi, în acest moment, că sunt foarte puţine aptitudini de afaceri care să nu poată fi automatizate, în care să nu putem să introducem tehnologie și să le avantajăm într-un fel. Tehnologia a stră-bătut cale lungă și este extrem de solidă în acest moment. De cele mai multe ori, pro-blema este în echipă și în punerea laolaltă a cerinţelor. De fapt, înţelegerea businessului suficient de bine încât să îi aplici tehnolo-gie. Aceasta este adevărata zonă de creștere. A fost dintotdeauna o problemă, dar devine din ce în ce mai acută cu trecerea timpului.
A: Mulțumesc. Acestea au fost întrebă-rile pe care le-am pregătit, dar aș mai dori să te rog dacă vrei să menţionezi câteva resurse, website-uri cu care lucrezi, lucruri pe care oamenii ar trebui să le încerce?
R: .NET Rocks. A fost creat de prietenul meu Carl Franklin în 2002, ceea ce e ulu-itor, deoarece în 2002 cuvântul „podcast” (a distribui fișiere multimedia pe inter-net) nici nu exista. Acesta a apărut câţiva ani mai târziu. El făcea fișiere MP3 și le punea pe Internet. Dar acum, după 11- 12 ani, show-ul a devenit destul de puternic. Eu sunt noul venit. Am intrat în echipă
în emisiunea cu numărul 100. Cred că ne aflăm la numărul 916 acum. Am avut al 900-lea episod în Wisconsin, la o conferinţă. A fost și o petrecere mare cu ocazia asta. 900 înseamnă multe emisiuni. Showul are loc de două ori pe săptămână – marţea și joia. Este gratis de descărcat. Este doar un fișier MP3 și poţi să îl obţi în iTunes sau Zune Marketplace sau oriunde dorești. Acum avem aplicaţii mobile pentru toate dispo-zitivele – chiar și pentru Windows Phone. Şi de două ori pe săptămână vorbim cu un luminator .NET: Rocky Lhotka sau Scott Guthrie – un cunoscător în profunzime al spaţiului .NET – despre ceea ce îi intere-sează și despre noile tehnologii. Încercăm să facem lucrurile mai ușoare pentru cei care lucrează în industrie sau sunt intere-saţi de aceasta, să sorteze ce este important pentru ei și de unde să afle mai multe în legătură cu anumite teme. Emisiunile de marţi tind să fie emisiuni mai tehnice. Joia mergem mai departe. Uneori este despre tehnologie, alteori poate să fie o lecţie de istorie. Odată am avut un interviu cu Les Pinter, cel care a scris versiunea originală Word, pe care a vândut-o lui Bill Gates. Sau vorbim despre oportunităţi în carieră. Cam o dată pe lună facem o emisiune dife-rită, pe o temă cu totul diferită de zona de dezvoltare. Luna trecută a fost exploatarea asteroizilor. Luna asta va fi despre grătar. Dar știi, încercăm să fim lejeri în legătură cu show-ul. Cunoaștem multe persoane care ne ascultă în timp ce fac naveta, așa că avem un format de talk-show. Încercăm să ne și distrăm așa, comportându-ne une-ori prostește în momentele în care suntem în formă. Şi DNR este numai una dintre emisiuni. Mai avem și Tablet Show o dată pe săptămână, lunea, iar acesta este des-pre dezvoltarea tabletelor și mobilelor pe diferite platforme – vorbim despre iOS și Android și Windows și apoi mai sunt și pe partea de IT – de la începuturile infor-maticii, am construit multe echipamente, am realizat multe reţele, așa că vorbesc cu profesioniști IT despre astea, o dată pe săptămână, miercurea, pe Run As Radio – un show mai scurt, un pic mai intens, axat pe o anumită gamă de subiecte, alta decât lejeritatea caracteristică a DNR. Așa că, da, patru show-uri pe săptămână în prezent.
