today software magazine n38/2015

No. 36 • June 2015 • www.todaysoftmag.ro • www.todaysoftmag.com

TSM T O D A YS O F T WA R E

Nr. 38 • August 2015 • www.todaysoftmag.ro • www.todaysoftmag.com

M AG A Z I N E

BuyAndHelp.ro – un proiect despre marketing afiliat și dorința de a ajuta

Beneficiile extra-salariale în 2015 sub lupă

Gestionarea datelor în creștere cu baze de date relaționale

Conflictul dintre mărci și domenii de Internet

Asigurarea Accesului Autorizat la Resursele Web prin Utilizarea ASP.NET Identity

A fi sau a nu fi un obiect: despre problema auto-referinței

Elevii ACADEMY+PLUS îninternship-uri și poziții de junior

Software Project Management în România

Download fromWindows StoreDownload fromWindows Store

I Love I Hate NY

6BuyAndHelp.ro – un proiect

despre marketing afiliat și dorința de a ajuta

Angela Lepădatu

8Software Project Management

în România Razvan Gai

10Siemens Developers

Day 2015 Razvan Opris

12Asigurarea Accesului Autorizat la

Resursele Web prin Utilizarea ASP.NET Identity

George Rus

16Gestionarea datelor în creștere

cu baze de date relaționaleAlin Luncan

20A fi sau a nu fi un obiect:

despre problema auto-referințeiVlad Ardelean

22I LoveI Hate NYTudor Stânean

26Elevii ACADEMY+PLUS în internship-uri și poziții de juniorGloria Csizser

30Beneficiile extra-salariale în 2015 sub lupăAdrian Beșleagă și Adrian Benta

35 Când ne doare,mergem la medic Szilard Kacso

37Bătălia din online: marcă vs domeniu de InternetClaudia Jelea

4 nr. 38/2015, www.todaysoftmag.ro

Ne apropiem de septembrie, luna în care lucrurile intră pe făgașul normal iar atunci când suni pe cineva nu te mai gândești că poate este în concediu. Redacția Today Software Magazine a intrat deja în acest ritm prin cele două

lansări ale revistei în Cluj și în Oradea. De asemenea, am lansat primul clip video de promovare a revistei, sper să vă placă și așteptăm părerile voastre, îl puteți vizualiza pe pagina noastră de Youtube. Ne pregătim și să lansăm agenda evenimentului Cluj IT Days, 24-25 noiembrie care a ajuns la cea de-a treia ediție. Dacă anul trecut am vorbit în secțiunea de leadership despre tranziția de la outsourcing la produs, anul acesta în prim plan vor fi produsele și vom avea în premieră o serie de lansări pentru piața locală clujeană. Profit de ocazie și vă mai spun câteva cuvinte despre programez.ro care va fi disponibil în curând. Utilizatorii vor avea ocazia să își creeze prin realizarea de teste online un profil tehnic verificat iar în funcție de punctele acumulate vor avea acces la diferite bonusuri precum reduceri la training-uri sau să vizualizeze job-uri ascunse. Acestea au fost ultimele noutăți din partea echipei TSM. Vă invit să citiți în continuare acest număr al revistei iar în continuare vom face o scurtă trecere în revistă a articolelor.

Păstrăm totuși un pic din plăcerea de relaxare a verii acest număr fiind un pic mai subțire. Începem cu prezentarea a două startup-uri locale, primul este BuyAndHelp.ro – o idee inedită prin care profit share-ul de la site-urile de e-commerce precum emag.ro, libris.ro, etc. este redirectat către diferite cauze precum: fundația comunitară CJ, Arca lui Noi, Simplon, etc. . Nu ne costă nimic iar în felul acesta putem într-o mică măsură aceste fundații. Felicitări Radu Popescu, un vechi colaborator al revistei, pentru această idee !!! Următorul startup este tot clujean dar are țintă piața din New-York, este vorba de I Love I Hate NY și îi invită pe vizitatori să spună ce le place și ce nu le place despre acest oraș. În continuare, Software Project Management în România propune o istorie a project management-ului local și cred că ne vom regăsi mulți într-un domeniu care este puțin reglementat și se manifestă în funcție de necesitățile clientului iar o comu-nitate și evenimentele sunt întotdeauna binevenite prin PMI chapter. Pe partea tehnică vă propunem Asigurarea Accesului Autorizat la Resursele Web prin Utilizarea ASP.NET Identity care prezintă metodele de autentificare și autorizare pentru ASP.NET MVC. Gestionarea datelor în creștere cu baze de date relaționale prezintă un caz real de prelu-crare de date bazate pe un mediu de stocare SQL și soluția pentru a realiza acest lucru cu o performanță cât mai mare. Spre final vă invităm să citiți impresiile studenților care iau parte la Academy+ după un an de activitate și modalitățile prin care vă puteți proteja marca în cazul în care cineva înregistrează doar pentru profit anumite domenii web.

Ovidiu MăţanFondator Today Software Magazine

Ovidiu Măţ[email protected]

Editor-in-chief Today Software Magazine

editorial

5www.todaysoftmag.ro | nr. 38/august, 2015

Lista autorilor

Gloria [email protected]

Marketing Specialist @ Pitech+Plus

Claudia [email protected]

Avocat & Consilier în domeniul marcilor @IP Boutique

Adrian Beșleagă [email protected]

Manager Operatiuni @ A&I Consulting

George [email protected]

Software Developer @ Yardi România

Adrian Benta [email protected]

Consultant Fiscal @ Benta Consult

Vlad Ardelean [email protected]

Software Developer @ 3Pillar Global Romania

Szilárd Kacsószilard.kacso@ happy-employees.eu

CEO & Trainer @ Azimut Happy Employees

Angela Lepă[email protected] Marketing Professional@ Buy & Help

Razvan [email protected] Project Manager @iQuest

Alin [email protected]

Software Engineer @ Accesa

Tudor Stâ[email protected]

IOS Developer@3 Pillar Global Romania

Redacţia Today Software Magazine

Fondator / Editor in chief: Ovidiu Mățan [email protected]

Graphic designer: Dan Hădărău [email protected]

Copyright/Corector: Emilia Toma [email protected]

Traducător: Roxana [email protected]

Reviewer: Tavi Bolog [email protected]

Contabil : Delia [email protected]

Programator junior: Alexandru Diniș[email protected]

Marketing și tehnoredactor: Ana Maria Bivol

[email protected]

Tipar realizat de Daisler Print House

Produs de Today Software Solutions SRL

str. Plopilor, nr. 75/77Cluj-Napoca, Cluj, [email protected]

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

Reproducerea parțială sau totală a articolelordin revista Today Software Magazine

fără acordul redacției este strict interzisă.

www.todaysoftmag.rowww.todaysoftmag.com

Razvan [email protected]

Location Manager @Siemens Cluj-Napoca


educație

Prin urmare, piața cumpărăturilor online din România este foarte mare și în creștere. În acest context și marketingul afiliat a început să se dezvolte foarte mult. În ultimii ani acest concept a luat amploare și s-a dovedit a fi o sursă considerabilă de venit pentru toate părțile implicate: afiliați, comercianți și platformele de afiliere.

Ce este marketingul afiliat? Marketingul afiliat este o formă de

marketing bazată pe performanță. Pe scurt, este procesul prin care afiliații (denumiți și publisher-i) primesc comisioane procentu-ale pentru fiecare lead sau vânzare adusă comercianților pe baza unui cookie. Acest proces este intermediat de o platformă de afiliere, unde cele două părți trebuie să fie aprobate în prealabil. În România, cele mai cunoscute platforme de afiliere sunt 2Parale și Profitshare. Acestea au plătit în 2014 comisioane de peste 184 milioane de lei.

Apariția BuyAndHelp.roC ombinând acest t ip de mar-

keting cu fundraising-ul, s-a născut proiectul BuyAndHelp.ro în cadrul competiției Innovation Labs 2015, susținută de Spherik Accelerator. Drumul de la idee până la realitate a fost scurt. Proiectul a început de la 0 în luna martie a acestui an și a fost lansat oficial la începu-tul lunii Iunie. Acesta a atras rapid atenția mass media, reușind să avem apariții în numeroase ziare online (Gandul, Monitor de Cluj sau Ziarul Financiar) dar și în emisiuni TV precum I Like IT (Pro TV), Recrutat în Cluj (Digi24) sau știrile TVR1.

Plusul față de o platformă de cumpă-rături online clasică este partea de HELP care oferă opțiunea de a alege către ce cauză socială cumpărătorul dorește să doneze o parte din valoarea produsului. Ceea ce este foarte important este că nu se plătește nimic în plus. Noi primim din partea comerciantului un comision pentru

BuyAndHelp.ro –

un proiect despre marketing afiliat și

dorința de a ajuta

Date oficiale furnizate de GPEC ne spun că 1 din 4 internauți cumpără online, iar în 2014 aceștia au cumpărat produse și servicii în valoare de aproximativ 1.1 miliarde de euro (o creștere de 40% față de 2013).

Angela Lepă[email protected] Marketing Professional@ Buy & Help


TODAY SOFTWARE MAGAZINEprogramare

că i-am adus un client nou, iar o parte din acest comision este direcționată către ONG-ul ales de cumpărător.

Putem explica cel mai bine tot procesul printr-un exemplu foarte simplu. Să spunem că tu dorești să îți cumperi o tabletă nouă care costă 1000 de lei, de pe website-ul unui magazin online (să îl numim X). Intrând pe site-ul magazinului X prin interme-diul BuyAndHelp.ro (click pe logoul acestuia) noi vom primi un comision procentual (să presupunem că acesta este 3%). După ce vei cumpăra tableta, magazinul X va transfera către BuyAndHelp.ro comisionul de 3% adică 30 de lei, iar noi îl vom dona către cauza socială pe care vrei să o susții. Toate acestea fără ca tu să scoți mai mulți bani din buzunar.

Statisticile platformeiWebsite-ul a fost lansat oficial la începutul lunii Iunie, iar până

acum am înregistrat 178 donații în valoare totală de aproxima-tiv 2000 lei, cea mai mare fiind de 79 lei. Toate aceste achiziții și donații au fost realizate prin intermediul celor peste 40 de maga-zine online partenere, printre care eMag, Elefant sau Plafar.

În prezent găzduim pe platformă 11 ONG-uri și cazuri sociale dintre cele mai diverse. Utilizatorii noștri pot cumpăra și dona pentru asociațiile care se ocupă de îngrijirea și sterilizarea ani-malelor, pentru a susține cursurile de programare ale celor de la Simplon România sau pentru Centrul de Recuperare “Un zâm-bet cu MIRA”. Singurul caz independent pe care îl avem în acest moment este “HelpSmaranda”, prin care încercăm să strângem bani pentru tratamentul unei tinere bolnave de cancer.

Ca planuri de viitor, dorim să extindem numărul magazinelor

online partenere și să avem cât mai multe campanii speciale pre-cum cea cu pe care o avem cu Gxgia Fashion prin care donăm 100% din prețul a nouă rochii unicat. De asemenea, vrem să permitem crearea de conturi pentru ca vizitatorii să-și poată vizu-aliza donațiile dar și dezvoltarea unui plugin de browser care va facilita achizițiile și donațiile online.

Spor la cumpărături!


Această țară a avut șansa să fie impli-cată în proiecte software de aproape 20 de ani, acumulând astfel o experiență vastă în outsourcing, servicii exclusiviste precum și în realizarea de produse. Întrebarea este: cui i-a revenit rolul de a coordona aceste proiecte?

Dar înainte de a vorbi despre Managementul Proiectelor, considerăm utilă menționarea unei definiții comune a proiectului: ”un demers temporar între-prins pentru a crea un produs, serviciu sau rezultat unic.” Deci, în toți acești ani, România a făcut multe demersuri tem-porare pentru a crea produse sau servicii care se află sau nu în producție chiar și în prezent. Cele mai multe dintre aceste pro-iecte au început ca subproiecte ale unor proiecte globale mai mari care și-au găsit calea într-o firmă de dezvoltare software românească, fiind astfel coordonate de manageri de proiect străini cu experiență, care au subcontractat bucăți de lucrare românilor. Așadar, efortul de management pentru aceste proiecte nu a fost chiar atât de complex de la început. Dar, bineînțeles

că aceasta s-a schimbat în timp.

De la antreprenori la … ”Project Managers” Dacă ne gândim la începuturi – cine

conducea atunci toată această muncă dată echipelor românești? Proiectele erau conduse inițial de către înșiși antrepreno-rii care creaseră aceste mici companii cu echipe mici printr-un management ghidat uneori doar de regulile bunului simț. În calitate de oameni de afaceri, antreprenorii se ocupau de costuri și randament ca și de compania în sine. Unii aveau diplome în administrarea afacerilor, alții doar instinc-tul natural, unii foloseau MS Project, alții Excel- un instrument de management con-siderat foarte puternic și în zilele noastre- , unii aveau strategii și viziuni, alții doar se concentrau pe a face o treabă bună pentru o referință activă. Pe măsură ce solicitările pentru scalabilitate au crescut și din ce în ce mai mulți dezvoltatori software s-au alăturat domeniului, structurile de mana-gement relativ slab nu au mai făcut față. Astfel, ”liderii de echipă” au ieșit la iveală din ”echipă” și au permis marelui șef să

Software Project Management

în România

La momentul scrierii acestui articol – august 2015 – România a fost clasată în multe sondaje drept o prezență notabilă pe piața IT&C globală, remarcându-i-se forța de muncă bine pregătită,cu suport academic și capacități multilingvistice.

Razvan [email protected] Project Manager @ iQuest

management


TODAY SOFTWARE MAGAZINE

delege managementul. În timp, ei au primit numele de ”mana-geri de proiect”, iar proiectele se derulau în jurul acestor lideri înnăscuți. Bineînțeles, mai existau și alte surse de manageri care se alăturau companiilor deja la nivelul de management, având experiență în medii academice și/sau în afara țării, care și-au găsit foarte repede locul în structurile de conducere superioare ierarhic.

Un nume. Descrieri ale postului și responsabilități multiple. De ce utilizăm ghilimele pentru acești ”Project Managers”

români timpurii? Pentru că fiecare companie a început să defi-nească acest rol într-o manieră relativă, care să se circumscrie nevoilor sale. Responsabilitățile managerului de proiect erau limitate de nevoile de management pe care le avea fiecare com-panie. Bineînțeles, ar trebui să existe un numitor comun undeva – de la triunghiul scop-timp-buget, la romburi și pentagoane de management și așa mai departe, dar niciun manager de proiect nu putea fi înlocuit de la o companie la alta; nici chiar în interiorul aceleiași companii project manager-ii nu au fost și nu sunt ușor de schimbat între ei. Deci, această poziție de manager de proiect software român a străbătut o cale lungă (și încă neîncheiată în prezent) până să se poată delimita clar de la un capăt la altul care îi sunt responsabilitățile și abilitățile necesare.

Această stare de fapt afectează în schimb procesul de anga-jare, deoarece companiilor care cer mai mult de la un manager de proiect le va fi greu să obțină oameni valoroși care doresc să își schimbe compania. Aceștia provin dintr-o poziție mai înaltă în care făceau aceleași lucruri, dar poate pentru bani mai puțini sau un titlu mai puțin impor-tant – ceea ce unele companii numesc Manager de Proiect, alții numesc Manager de Linie sau Manager de Program și așa mai departe.

Manager de proiect ”tehnic” Cei care s-au dezvoltat în interiorul companiei

dintr-un programator senior este ceea ce se poate numi ”Technical” Project Manager. Se pare că acesta este modul preferat în zilele noastre de a produce manageri de proiect. În teorie, un project manager dintr-o altă industrie ar putea foarte bine să se ocupe de un proiect din industria IT. Totuși, ar fi nevoie de ceva timp pentru ca acesta să se deprindă cu toate aspectele specifice ale industriei și există desigur o limitare – acest project manager nu poate să treacă la scrierea de cod atunci când procesul devine dificil și cei mai buni pleacă. Și poate că nici nu ar trebui să fie cazul, deoarece de fapt acest lucru încalcă chiar primul principiu al SOLID – ”principiul unicei responsabilități”. Da, știu că este pentru clase și nu pentru oameni – ar putea argumenta unii programa-tori, dar filozofia rămâne.

Specialiști versus generaliști – este bine să ai ambele grupuri în orice aspect al vieții sau profesiei. ”Un singur om” nu ar trebui să fie standardul – mana-ger, analist business, arhitect, lider tehnic, guru, naș, mentor, persoană de vânzări… nu prea este atâta loc pentru a-i înghesui pe toți aceștia într-o singură per-soană – așa că, de ce să nu ne întoarcem pur și simplu la manager. Fă o singură treabă, dar fă-o bine!

Manageri de proiect profesioniști ”Cu o putere mare vine și o mare răspundere” – de fapt, aici

nu există putere, doar răspundere. Puterea nu poate fi dată, res-ponsabilitatea poate fi atribuită și asumată. Liderii au puterea de a influența direcția spre care se îndreaptă proiectele, dar nu există un lider numit, ci numai ajuns în această postură prin propriile sale mijloace. Calea arată promițătoare pe măsură ce începem să ne aliniem cu abilitățile, responsabilitățile, pregătirea și cer-tificarea pentru a forma Project Manager-i și a crea Birouri de Project Management. Nu este o provocare ușoară și s-ar putea să fie un proces încet și dureros, dar trebuie să conștientizăm acest lucru dacă dorim să sporim procentul mic de azi al proiectelor software de succes. Este îmbucurător să vedem în prezent cum manageri de proiect din diferite companii se adună cu ajutorul unor organizații precum Institutul Managementului de Proiect – Capitolul România, susțin prezentări, împărtășesc informații, se pun de acord cu privire la responsabilitățile pe care ar trebui să le aibă un manager de proiect, aptitudinile tehnice si soft pe care ar trebui să le posede un manager sau un lider și construiesc cu adevărat o comunitate.

În concluzie, Managementul de Proiect Software Românesc profesionist poate fi o realitate și se întâmplă deja. Noi trebuie doar să… nu lăsăm niciodată vreun proiect să eșueze.

IT CONFERENCE ON

TECHNOLOGIES.IES.

IT Conference on

18-19.09.2015Locatia : City Plazza

https://goo.gl/6N1GKX

www.msg-systems.ro

10 nr. 38/august, 2015 | www.todaysoftmag.ro

Dezvoltarea software era acum douăzeci de ani ceva special – cu puține informații disponibile, nu foarte multe unelte sau sisteme de dezvoltare, aceasta se baza în primul rând pe creativitatea și inspirația unor programatori foarte pasionați, care înțelegeau și aplicau prin intermediul aplicațiilor dezvoltate con-cepte teoretice avansate.

O dată cu evoluția sistemelor bazate pe software, atât în complexitate, cât și în ceea ce privește dimensiunile, apare problematica modificărilor și extensiilor codului, modificări făcute de cele mai multe ori într-un mod ad-hoc. Ca urmare, procesele de dezvoltare de software se îndreaptă spre adoptarea de procese agile, îndepărtându-se de abordarea clasică tip waterfall. Această abordare aduce însă cu sine de multe ori probleme cauzate de înțelegerea deficitară a impactului asupra sistemelor mari și complexe, cu multe

interdependențe, dar și a metodologiei asociate acestor procese de dezvoltare.

Centrul Siemens din Cluj-Napoca este implicat în susținerea concernului Siemens în adresarea provocărilor aduse de digi-talizarea pe scară largă. Startul centrului nostru l-am dat acum un an, iar astăzi numărăm peste 100 de colegi implicați în dezvoltarea și mentenanța aplicațiilor complexe de tip enterprise, dar și furnizării de servicii de support pentru echipele din cadrul organizației globale de inginerie a Siemens.

Pe 6 octombrie vom organiza un eveniment special destinat tuturor celor implicați în dezvoltatarea software: prima ediție a Siemens Developers Day. Pe par-cursul acestui eveniment, participanții vor putea descoperi modul în care au fost adresate provocări reale din alte organizații IT și vor putea să participe în cadrul unor activități hands-on dedicate dezvoltării de

software. Acest eveniment este deschis participării tuturor celor implicați în dez-voltarea de aplicații enterprise sau celor interesați de acest domeniu.

Alături de speakeri de la Microsoft și evosoft GmbH vom explora provo-cările întâmpinate în transformarea unei organizații către o organizație care adoptă metodologia DevOps, prin exem-plul furnizat de echipa Visual Studio Online. Vom descoperi dacă o inițiativă neconvențională de implementare a unei metodologii DevOps orientată pe cloud și-a atins obiectivele într-o jumătate de an, conform așteptărilor.

Compania evosoft este implicată în dezvoltarea, livrarea și mentenanța multor aplicații și platforme enterprise utilizate în cadrul Siemens. Activitatea evosoft se axează de-a lungul a trei direcții importante pentru Siemens precum domeniul industrial, energetic si medical.

Siemens Developers Day 2015

Tehnologia aduce inovații care schimbă viața oamenilor din întreaga lume. Digitalizarea este acum parte a vieții de zi cu zi, iar la baza acesteia se află munca a mii și mii de dezvoltatori software, testeri, arhitecți software, manageri de proiect, ingi-neri și mulți, mulți alții. Domeniul dezvoltării software este un domeniu relativ tânăr, prezent în viețile noastre de câteva

decenii. În ultimii douăzeci de ani acest domeniu a trecut prin transformări majore, iar în următorii ani lumea dezvoltării software va fi complet diferită.

eveniment



Cu precădere în ultimii cinci ani, am observat chiar și în cazul proiectelor de scară largă o migrare către adoptarea de metodologii agile, cum ar fi SCRUM sau continuous integration. Însă în cazul siste-melor tip cloud, această abordare merge un pas mai departe: continuous delivery și continuous deployment reprezintă premi-sele materializării întregului potențial al unei tehnologii bazate pe cloud. Mergând către un mediu DevOps bazat pe cloud, colegii noștri au adoptat o combinație de test-driven pair programming și con-tinuous delivery. Colegul nostru, Kornél Molitórisz, va împărtăși participanților la acest eveniment experiențele și concluziile unei astfel de abordări neconvenționale.

Participând la acest eveniment veți putea afla detalii despre transformarea unei organizații de la o abordare clasică, tip Waterfall, către un model DevOps, cu sprint-uri de câte trei săptămâni și deploy-ment într-un serviciu cloud, având mai mult de două milioane de utilizatori glo-bali. Christian Binder, ALM Architect în cadrul Microsoft, va descrie etapele trans-formării diviziei Microsoft Developer – Visual Studio Online către o abor-dare DevOps. În cadrul prezentării sale, Christian va furniza informații intere-sante despre organizarea și modul în care își desfășoară activitatea această divizie de dezvoltare a Microsoft.

Dacă sunteți interesați să participați la acest eveniment, urmăriți pagina Facebook a Siemens România (http://fb.com/SiemensRomania). Abonații TSM vor primi de asemenea mai multe informații despre acest eveniment.

Despre speakeriKornél Molitórisz este un expert în

software developement și arhitecturi software al evosoft din Budapesta. A absol-vit Universitatea Tehnică din Budapesta în 2000 și este activ în cadrul evosoft din 2003, unde a participat activ în diverse proiecte complexe, majoritatea având de-a face cu domeniile Industrial Automation, Railway Automation și Healthcare. Este membru în Expert Office din 2011, ariile de interes sunt cloud computing și aspec-tele tehnice și metodologice ale dezvoltării de software pentru medii tip cloud.

Christian Binder este ALM Architect în cadrul Microsoft Developer Experience Group (DX). S-a alăturat Microsoft în 1999 și lucrează alături de Visual Studio Product Development Group din Redmond începând cu anul 2006. Specializările sale sunt platformele ALM, respectiv direcțiile de dezvoltare ALM, cum ar fi organizații agile și Lean, Cloud Cadence, respectiv metodologia Build-Measure-Learn. Christian se concentrează pe implementarea acestor concepte pen-tru clienți, inclusiv pe adaptarea internă și adoptarea acestor metodologii și principii în organizații mari.

Despre Siemens RomâniaSiemens sărbătorește în acest an

110 ani de la înființarea primei sale reprezentanțe locale în România. Fiind încă de la începuturi un contribu-tor important la dezvoltarea tehnică și economică a țării, compania Siemens este hotarâtă să joace în continuare un rol important în dezvoltarea viitoare a României. Având mai mult de 1600 de

angajați în 10 orașe din România, Siemens SRL este una dintre cele mai mari compa-nii de inginerie din țară. În Cluj-Napoca suntem prezenți cu două locații. Cea de-a doua locație din Cluj-Napoca a fost inau-gurată la începutul acestui an, împreună cu subsidiara evosoft GmbH, și este un centru regional de cercetare și dezvol-tare în IT, destinat proiectelor IT interne ale Siemens și proiectelor de dezvoltare software pentru aplicații și sisteme din portofoliul concernului.

Despre evosoft GmbHEvosoft GmbH este o subsidiară

deținută de Siemens AG. În această cali-tate, compania coordonează și execută încă din 1995 consultanță, design și training pentru proiecte internaționale și servicii IT destinate tuturor diviziilor interne ale concernului Siemens. Având 1400 de angajați în locații din Germania, Ungaria, Turcia și România, compania are sediul central în Nuremberg, Germania și operează ca entitate independentă și în Ungaria.

Razvan [email protected]

Location Manager @ Siemens Cluj-Napoca


În această eră a mobilității și a interconectivității device-urilor, există cazuri în care accesul la informație trebuie restricționat pentru entitățile neautentificate. Scopul acestui articol este furnizarea de detalii privind metodele de autentificare și auto-

rizare pentru dezvoltatorii de soft care folosesc platforma ASP.NET, și în special ASP.NET MVC.

În rândurile următoare vom expune infrastructura ASP.NET Identity, insistând asupra particularităților de bază ale produ-sului, dar și asupra modului în care acest sistem poate fi modificat pentru a se preta unor scenarii/situații diferite.

Ce este ASP.NET Identity? Ca să putem răspunde la această

întrebare, după cum explică autorii [1], putem afirma că ideea din spatele acestei infrastructuri reprezintă o soluție care fur-nizează următoarele beneficii:

• Un mecanism de autentificare și autorizare care permite controlul asupra mecanismului de stocare a informației, ușor de extins și de testat, ce oferă în plus și un middleware OWIN, desti-nat folosirii în cadrul oricărui tip de aplicație(web, mobile, cloud);

• Autorizare bazată pe rol sau pe solicitare;

• Infrastructură care poate fi conec-tată pentru diferiți furnizori, cum ar fi Microsoft, Google, Facebook, Twitter, etc.;

• Facilități de integrare cu Azure Active Directory.

Privire de ansamblu asupra arhitecturiiSistemul ASP.NET Identity furni-

zează din start o soluție de membership

funcțională. Privind lucrurile într-un mod abstract, arhitectura ASP.NET Identity se bazează pe următoarele aspecte: mana-gers responsabili pentru procesarea informațiilor și stores, care reprezintă implementarea modului de stocare a informației. Aceste două concepte sunt decuplate, oferind dezvoltatorilor posibi-litatea de a se conecta la diferiți provider-i de stocare.

În mod implicit, mecanismul de persistență este implementat utilizând conceptul Entity Framework Code First. Pentru a stoca informația, se vor genera un set de tabele:

• Un tabel care va conține informațiile despre utilizator: user id, numele user-ului, o parolă hashed;

• Un alt tabel reprezentând rolurile – poate fi interpretat ca reprezentarea grupurilor de autorizare;

• Un tabel pentru claims – un set de informații care duce la identificarea utilizatorului;

• Un tabel logins – reprezentând informațiile de la provider-ii externi de autentificare, cum ar fi Microsoft, Facebook, Google, Twitter, etc. .

Părțile principale ale sistemului sunt formate din:

• Microsoft.AspNet.Identity.Core

Asigurarea Accesului Autorizat la

Resursele Web prin Utilizarea ASP.NET

Identity

programare

George [email protected]

Software Developer @ Yardi România


TODAY SOFTWARE MAGAZINEprogramprare

– logica pentru users, stores și managers;• Microsoft.AspNet.Identity.EntityFramework - implementa-

rea legată de stocare specifică a Entity Framework;• Microsoft.AspNet.Identity.Owin – implementarea peste

funcționalitatea OWIN a ASP.NET Identity.

Următoarea diagramă ilustrează componentele arhitecturale ale framework-ului:

Figura 1.Componentele ASP.NET Identity

Luând în considerare partea de nucleu a framework-ului, următoarea diagramă ilustrează abstractizările conceptelor de user și store:

Figura 2. ASP.NET Identity Core

Dacă privim structura centrală, vom observa entitățile de bază, acestea fiind: IUser și IRole, care sunt folosite în partea de stores; IUserStore – user management și respectiv IRoleStore – pentru rol management.

Următoarele tipuri de stores, prezentate mai jos, sunt particu-larizări ale conceptului reprezentat de IUserStore:

• IUserClaimStore – stochează claims specifice fiecărui utilizator;

• IUserEmailStore – stochează partea de e-mail; • IUserLockoutStore – reprezintă partea de lockout:- accesuri

respinse, statusul de blocat, etc;• IUserLoginStore – persistarea asocierilor cu provider-ii de

login externi: Google, Facebook, Twitter, Microsoft; • IUserPasswordStore – stochează parola hash-ed pentru un

utilizator; • IUserPhoneNumberStore – stochează informații legate de

numărul de telefon;• IUserRoleStore – face legătura între utilizatori și rolurile lor; • IUserSecurityStampStore – stochează timbrul de securitate; • IQueryableUserStore – expune IQueryable users.

Pe lângă stores, există și partea de managers. Aceștia sunt res-ponsabili pentru orchestrarea modificărilor, respectiv:

• UserManager – expune funcționalitatea care va salva modi-ficările în user store;

• RoleManager – furnizează logica pentru salvarea modifică-rilor legate de role store.

În cazul în care Entity Framework nu este compatibil cu proiectul la care lucrați, există posibilitatea de a folosi diverși pro-vider-i de stocare, care suportă următoarele tehnologii:

• MySQL; • Azure Table Storage; • ElasticSearch; • CouchDB / Cloudant; • MongoDB; • NHibernate; • RavenDB; • Redis.


Dacă acești furnizori nu sunt ceea ce aveți nevoie, există posi-bilitatea de a fi dezvoltați alții și integrați în proiectul de dezvoltat. Pentru a realiza acest lucru, trebuie luate în considerare următoa-rele aspecte:

• Sursa de date pe care o veți folosi;• Datele care trebuie stocate: informațiile utilizatorilor, user

claims, cât și partea de logins și roles• Clasele de stocare: user store, user claim store, user logins

store, user role store;• Layer-ul de data access care va opera cu clasele de store.

Autentificarea externă Există anumite scenarii în care aplicația care urmează a fi dez-

voltată trebuie să ofere posibilitatea de autentificare prin alte/de către alte surse, nu doar opțiunea tradițională, unde informațiile utilizatorului se păstrează într-o bază de date locală. În acest caz, dezvoltatorii pot folosi suportul inclus în produs, pentru imple-mentarea provider-ilor externi.

Există două standarde de autentificare care permit utilizato-rilor folosirea conturilor de la provider-i de încredere. Acestea sunt OAuth și Openld. După cum afirmă unii experți, protocolul OAuth a fost creat în principal pentru autorizare, dar sunt multe cazuri în care este utilizat pentru autentificare. Partea bună, la aceste standard, este că majoritatea provider-ilor oferă și imple-mentarea pentru ele, scutindu-i pe utilizatori de procesul de înregistrare pentru diferite aplicații

Dacă folosim provider-i externi, în primul rând trebuie să ne asigurăm că Autentificarea proiectului este setată pe Individual User Accounts. Utilizarea de provider-i de autentificare externi, cum ar fi Google, Microsoft, Facebook, etc. obligă stabilirea cone-xiunii în mod SSL, dar este indicat a se folosi https și după login, pentru a nu fi transferate date sensibile în clear-text. Dacă dez-voltăm aplicații folosind ASP.NET MVC, atributul RequireHttps poate fi folosit pentru a obliga toate Request-urile să folosească https și atributul Authorize pentru a restricționa accesul. O altă abordare ar fi crearea unui filtru care să oblige toate Request-urile să treacă prin https. Configurarea RequireHttps și Authorize pen-tru întreaga aplicație este considerată un security best practice.

În cadrul dezvoltării de aplicații folosind ASP.NET MVC 5, provider-ii de autentificare externi sunt configurați prin App_Start\Startup.Auth.cs. În funcție de protocolul implementat, OAuth sau OpenID, provider-ul va impune un proces de înre-gistrare sau nu, pentru a furniza datele de autentificare. Datorită faptului că ASP.NET Identity dispune de un OWIN middleware, configurarea provider-ului extern este foarte ușor de realizat indi-ferent de protocolul implementat de provider.

Următorul conținut prezintă App_Start\Startup.Auth.cs cu configurația OWIN funcțională: public partial class Startup{// For more information on configuring // authentication, please visit // http://go.microsoft.com/fwlink/?LinkId=301864

public void ConfigureAuth(IAppBuilder app) {// Configure the db context and user manager // to use a single instance per request app.CreatePerOwinContext( ApplicationDbContext.Create); app.CreatePerOwinContext<ApplicationUserManager> (ApplicationUserManager.Create);

// Enable the application to use a cookie to store // information for the signed in user app.UseCookieAuthentication(

new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes. ApplicationCookie, LoginPath = new PathString(“/Account/Login”), Provider = new CookieAuthenticationProvider { OnValidateIdentity = SecurityStampValidator. OnValidateIdentity<ApplicationUserManager, ApplicationUser>( validateInterval: TimeSpan.FromMinutes(5), regenerateIdentity: (manager, user) => user. GenerateUserIdentityAsync(manager)) } });

// Use a cookie to temporarily store information // about a user logging in with a third party // login provider app.UseExternalSignInCookie( DefaultAuthenticationTypes.ExternalCookie);

// Uncomment the following lines to enable logging // in with third party login providers//app.UseMicrosoftAccountAuthentication(// clientId: “”,// clientSecret: “”);

//app.UseTwitterAuthentication(// consumerKey: “”,// consumerSecret: “”);

//app.UseFacebookAuthentication(// appId: “”,// appSecret: “”);

//app.UseGoogleAuthentication(); } }

După ce procesul de înregistrare cu provider-ul de autenti-ficare este încheiat, pasul următor ar fi să folosim Startup.Auth.cs pentru a configura aplicația, astfel încât aceasta să folosească acel provider. Salvarea de date sensibile în cod sau fișiere repre-zintă o problemă de securitate și această abordare trebuie evitată. Modalitățile de securizare a aplicațiilor web împotriva diferite-lor amenințări sau atacuri care pot exista nu reprezintă subiectul acestui articol.

ConcluziiScopul principal al acestui articol a fost prezentarea modului

în care caracteristicile sistemului ASP.NET Identity pot fi folosite pentru a controla accesul la anumite părți ale aplicației.

În prima parte au fost prezentate informații generale despre sistem și avantajele lui pentru dezvoltatorii care trebuie să includă funcționalitatea de membership în aplicațiile lor. A doua parte a articolului oferă informații despre arhitectura framework-ului, expunând componentele abstracte, despre ce storage providers pentru diverse tehnologii de stocare există deja, dar și ce aspecte ar trebui luate în considerare atunci când este nevoie să scriem chiar noi unul. Ultima parte conține informații legate de plug-in-ul și configurarea unui provider de autentificare extern.

Luând în considerare produsul finit, posibilitatea de a extinde și de a adapta sistemul, ASP.NET Identity este o opțiune de considerat atunci când dezvoltarea unei aplicații care folosește tehnologia .NET implică și funcționalitatea de membership.

Bibliografie1. http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity2. https://msdn.microsoft.com/en-us/magazine/dn605872.aspx3. http://www.asp.net/identity/overview/extensibility/overview-of-custom-storage-providers-for-aspnet-identity

programareAsigurarea Accesului Autorizat la Resursele Web prin Utilizarea ASP.NET Identity



Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 610 / Nr. Evenimente: 47

Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Websites: www.facebook.com/todaysoftmag www.meetup.com/todaysoftmag www.youtube.com/todaysoftmagData înfiinţării: 06.02.2012 /Nr. Membri: 2424/Nr. Evenimente: 32

Cluj Business AnalystsComunitate dedicată analizei de businessWebsite: www.meetup.com/Business-Analysts-ClujData înfiinţării: 10.07.2013 / Nr. Membri: 91 / Nr. Evenimente: 8

Cluj Mobile DevelopersComunitate dedicată tehnologiilor mobileWebsite: www.meetup.com/Cluj-Mobile-DevelopersData înfiinţării: 05.08.2011 / Nr. Membri: 264 / Nr. Evenimente: 17

The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 437 / Nr. Evenimente: 93

Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 192/ Nr. Evenimente: 29

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: 251/ Nr. Evenimente: 14

Tabăra de testareComunitate formată din testeri și alți profesioniști din industria IT care, în cadrul unor întâlniri informale lunare, împărtășesc din cunoștințele proprii și învață din experiențele profesionale ale celorlalți membri.Website: www.tabaradetestare.roData înfiinţării: 15.01.2012/Nr. Membri: 1243/ Nr. Evenimente: 107

Evenimentele din această perioadă sunt realizate de pasionații de tehnologii și de grupurile acestora. După cum puteți vedea în calendar, acestea sunt publicate exclusiv pe meetup.com și facebook având audiența formată din comunitățile locale.

Calendar August 26 (Cluj)Lansarea numărului 38 al Today Software Magazine www.todaysoftmag.ro

August 27 (Oradea)Lansarea numărului 38 al Today Software Magazine www.todaysoftmag.ro

August 29 (Cluj)Lansare Kogaion și Argent Linux OS Româniaeventbrite.com/e/cluj-napoca-lansare-kogaion-si-argent-linux-os-romania-tickets-18251932020

Septembrie 3 (Cluj)Drupal Cluj Meetup meetup.com/Drupal-Cluj/events/223672594/

Septembrie 17 (Cluj)JavaScript Cluj Meetup meetup.com/JavaScript-Cluj/events/222421552/

Septembrie 24-27 (Harghita Băi)Tabăra de testare - Autumn Camp 2015facebook.com/events/487498068085911/

Octombrie 1 (Cluj)Using Protractor and Appium to automate Hybrid appsmeetup.com/Cluj-JS/events/224608770/

Noiembrie 24-25 IT Days (Cluj)A treia ediție a Cluj IT Daysitdays.ro

Comunităţi IT


programare

Aceste cuvinte m-au bântuit pentru o vreme, nu puteam înțelege de ce s-a expri-mat în acest fel. O excepție a aplicației era suficient de rea, dar pierderea datelor era de neînchipuit; încercam să vizuali-zez tipul de complexitate care l-a făcut să exprime această cerință anume.

Nu reușeam să văd imaginea de ansamblu. În ultimii doi ani și jumătate, am aflat că pentru acest client datele sunt totul. Nimic nu este mai presus de date: nici UI, nici modul în care datele sunt sto-cate, nici chiar ușurința utilizării. Aceasta, pentru că aplicația colectează date uti-lizate în modele științifice de la diferite dispozitive (senzori) și servicii software (procesare de imagini), care la rândul lor sunt transferate într-un model matema-tic care evaluează datele, rezultând și mai multe date, care din nou sunt reprocesate și combinate cu alte date citite de senzori și introduse, care sunt toate reevaluate în alte modele afișate drept tabele sau diagrame. Dar lucrurile nu se opresc aici: utilizatorul are posibilitatea de a filtra și elimina intră-rile greșite de la orice nivel, ceea ce face ca modelele matematice să reevalueze. Da! Pentru acest software, datele reprezintă întreaga aplicație; toate celelalte aspecte sunt lipsite de sens dacă datele sunt defor-mate sau inaccesibile. Mi-a luat ceva timp pentru a înțelege cerința principală în forma sa deplină, dar în final am reușit să am o privire de ansamblu completă asupra

întregii ierarhii de date. Și am reușit! Acum aproximativ un

an, am ajuns într-un punct în dezvol-tare în care toate datele pe care aplicația anterioară le colectase și le distrusese, au fost salvate și stocate în baza de date relațională a noastră (SQL Server 2012). Acestea au putut fi utilizate din nou, exportate/ importate între diferite compu-tere printr-un serviciu rapid și inteligent integrat în aplicație. Am proiectat împre-ună cu clientul o structură recurentă care putea gestiona toate cerințele, senzorii și modelele matematice viitoare, cu mici modificări. Era stabilă și scalabilă și am realizat-o în timp ce încă foloseam un instrument Object Relationship Mapping (ORM) pentru Data Layer.

Pentru procesul de colectare a datelor a

fost necesar să proiectăm mai multe tabele de configurare a senzorilor și a procesului propriu zis: numărul de senzori folosiți, constante de mediu și unitatea de măsură a datelor. Configurările și valorile efec-tive ale datelor sunt evaluate de un model matematic pentru a obține un prim set de rezultate. Modelul matematic e reprezen-tat printr-o simplă tabelă ce are legătură cu configurările inițiale ale senzorilor, propriile configurări pentru a determina unitățile de măsură și numele rezultatelor ce le expune dar și o legătura efectivă cu fiecare rezultat ce îl expune (data output),

Gestionarea datelor în creștere

cu baze de date relaționale

Când și dacă software-ul se prăbușește, clienții noștri nu ar trebui să își piardă datele pe care le-au colectat, chiar dacă acestea se află în memorie.” Fraza aparține unuia dintre clienții noștri care ne-a transmis-o acum doi ani, cu

valoare de principală cerință pentru o nouă aplicație software.

Alin [email protected]

Software Engineer @ Accesa



existând un nivel logic în cod care aplică formulele matematice propriu-zise. Rezultatele unui model matematic poate servi ca punct de intrare pentru un altul creând o relație părinte-copil între modele, existând și posibilitatea ca un set de date colec-tate să fie folosit de mai multe modele. Toate aceste relații dintre modele și rezultate sunt determinate de acțiunea utilizatorului, acesta având posibilitatea de a filtra date colectate pentru un sin-gur model sau rezultate de evaluare pentru un altul. Pentru baza noastră de date, acest lucru a însemnat adăugarea de multiple tabele de legătură pentru a putea determina care date dintr-un set

sunt selectate și crearea de coloane în unele tabele care să indice părintele modelelor, dacă acesta există.

Designul funcționa și rezista. Ne-am ocupat de fiecare nouă cerință în structurile noastre, în timp ce păstram încă relațiile plă-nuite inițial între tabele. Designul bazei de date relaționale ne-a dat flexibilitatea de a efectua cercetări complicate de la toate nive-lurile și de a filtra citirile greșite ale senzorilor și a reevalua datele de la fiecare nivel al ierarhiei, fie el pe verticală sau pe orizontală. Eu, unul, m-am bucurat că am utilizat o bază de date relațională


și că nu am căzut în capcana utilizării unui design NoSQL pentru date structurate în această manieră.

Dar ceva nu a mers bine. La începutul acestui an, am înce-put să observăm că o anumită cerință producea o proporție mare de Date de Evaluare de nivel slab. A reieșit că un tip de dispozitiv avea cerința de a colecta și stoca citiri multiple ale senzorului, la o rată de 20 de citiri pe secundă. Aceasta însemna că într-o oră, am fi avut de făcut 72000 de citiri de la vreo 7 senzori, de procesat fiecare înregistrare cu mode-lul matematic și de stocat acele valori. După câteva calcule cu privire la dimensiunea obiectului pentru o citire a senzorului care ajunge în baza de date, ne-am dat seama că aceasta s-ar ridica la 2 KB de date. Deci, am făcut încă puțină matematică:

2 kilobytes x 72000 reading x 7 sensors= 1.008 Giga-byte

Adică 1GB de dimensiune pe disk numai pentru a păstra datele de la 7 senzori timp de o oră. De cât de multă memorie era nevoie pentru a prelua obiectele de la Nivelul de Date (Data Layer) la Nivelul de Prezentare (Presentation Layer), astfel încât utilizatorul să poată avea o reprezentare completă a datelor colec-tate? Lucrurile nu arătau bine.

Gestionarea problemei! Primul lucru era să verificăm de două ori dacă cerința era reală (colectarea datelor timp de o oră la o rată de luare de mostre de 20 citiri per secundă). Din păcate, acesta era un caz de utilizare valid și, mai mult, pentru a agrava problema, clientul devenea frustrat de viteza de încărcare. Citirea unei cantități atât de mari de date și crearea obiectelor Business Logic pentru acestea lua mult mai mult timp și memorie decât simpla copiere a datelor de pe disk în memorie. Aveam nevoie de un nou mod de a gestiona datele noastre relaționale astfel încât

să putem ajunge la o performanță cât mai apropiată posibil de timpul de citire al discului.

Am verificat performanța ORM și cea a altor unelte similare la încărcarea tuturor datelor și asamblarea ierarhiei după cum a fost descrisă de baza de date și de către Business Logic. Pentru a rezuma lucrurile, răspunsul pe scurt a fost după cum era de așteptat: performanța era proastă. Am făcut orice v-ați putea ima-gina cu ORM până am ajuns chiar să utilizăm instanțe multiple pentru a încărca datele separat per obiecte, am oprit urmărirea stărilor entităților, dar iar și iar, eram departe de performanța pe care clientul se aștepta să o furnizăm. Imaginea era clară: nu vă bazați pe instrumente ORM pentru a construi și încărca ierarhii complexe.

Acesta a fost punctul în care am realizat că era nevoie să găsim o modalitate de a exprima complexitatea ierarhiei, așa cum merge ea și pe orizontală (frați) și pe verticală (părinți, copii), într-un singur tabel, astfel încât să putem obține entitățile și relația lor cu o unică interogare (query) simplă, iar cu un pass al acestui tabel, obiectele de Business Logic și reprezen-tarea lor puteau fi corect încărcate. Am creat un tabel care să păstreze repre-zentarea pentru fiecare tip de obiect din tabelele bazei de date și de asemenea să stocheze nivelul de profunzime pentru acestea; astfel am acoperit și relațiile de frăție și pe cele de paternitate.

Această tabelă (Model Nodes) practic ne permite să extragem toate înregistrările din baza de date ce conțin o legătură cu un model matematic. Fiecare configurare, fiecare model precedent, fiecare citire de senzor, fiecare rezultat al

programareGestionarea datelor în creștere cu baze de date relaționale



modelului are câte o înregistrare în acest tabel. • Model ID – reprezintă Id-ul modelului matematic• NodeType – indică către ce relaționăm (configurare, rezul-

tate, citire de senzor)• Node Id – indică Id-ul obiectului cu care relaționăm;• Parent Id – indică parintele nodului.

Citind fiecare linie din această tabelă ne putem crea propriul index în memorie pentru un model matematic pe baza căruia din fiecare tabelă indicată de către NodeType putem încărca doar datele relevante.

Să presupunem că avem două modele matematice: M1 și M2. Primul model, M1, se bazează pe date citite din senzorii S1 și S2 si produce rezultate M1R1, M1R2 și M1R3. Al doilea model, M2, primește ca input M1R1 și M1R3 și produce rezultatul M2R1. Utilizatorul vrea să elimine din acest calcul doar datele influențate de senzorul S1, iar pentru aceasta e destul să îl dese-lecteze din interfață.

În mod normal această operație ar însemna construirea unui query complex care pornind de la Id-urile a modelelor matema-tice, a senzorului și a rezultatelor. Se extrag toate valorile de la S1 folosite în calcului lui M1R1 și M1R3 și se reevaluează M2R1.

Dacă însă ne folosim de tabela de ierarhie avea deja toate Id-urile necesare în memorie legate atât de M1 cât și de M2:

Tot ce trebuie să facem e să citim din baza de date valorile din tabelele corespunzătoare, să reevaluăm modelul și să actualizăm tabela de ierarhie dacă este cazul.

Această tabelă poate fi construită în două moduri: fie gene-rarea ei printr-un script sau la momentul creării de noi entități logice în aplicație se generează automat o înregistrare, iar exem-plul dat este doar unul dintre multiplele scenarii unde indexare în memorie a acestor legături logice poate economisi tip de execuție pe serverul de baze de date.

Pentru a înțelege de ce acest tabel rezolvă complexitatea date-lor noastre în creștere din bazele de date relaționale, noi trebuie să înțelegem obiectele din spatele său. Bazele de date relaționale nu au probleme de performanță la citirea datelor structurate plan, dar atunci când Data Layer începe să alcătuiască obiecte business, se creează interogări complexe care au durate de rulare însemnate și un impact semnificativ de memorie. Acest tabel creează o descriere plană a unei ierarhii și orice informații nece-sare, cu privire la relațiile logice dintre obiecte, vor fi disponibile în interiorul său. Toate datele necesare pentru a descrie relațiile logice dintre obiectele Business Logic pot fi obținute prin rularea unei singure interogări (query) în memorie. Doar prin adăugarea tabelului adițional în baza noastră de date, am fost capabili să citim și să alcătuim obiecte cu viteza pe care ne-o permite discul, la un cost de 40 bytes * 72000 citiri * 7 senzori (20 MB) pentru 1GB de date neprelucrate.

Privind în viitor. Aceasta m-a făcut să mă gândesc la cum vor arăta datele noastre în viitor, cât de mult poate gestiona în

realitate aplicația în acest fel. Ar mai fi ceva ce am putea face pentru a o îmbunătăți? Pentru a răspunde la această întrebare, trebuie să revenim la baza noastră de date. Dacă datele ne per-mit, am putea avea colecții de valori care ar putea să încapă ușor în tabelul ierarhiei; am putea încărca acele valori și le-am putea utiliza în alte filtrări și calcule suplimentare, iar dacă matematica permite, filtrarea și eliminarea valorilor greșite citite de senzori va actualiza valoarea colectată, ceea ce, la rândul său, poate deter-mina reevaluarea Modelelor Matematice.

A ieșit la iveală un tipar, iar noi putem trage o concluzie: baza de date poate fi divizată în două tipuri de relații: cele de tip schemă și cele logice. Relațiile schemă sunt cele care îți fac viața mai ușoară, descrise de schemele tabel; încărcarea acestui tip de date este directă și scalabilă. Relațiile logice, pe de altă parte, sunt cele care generează probleme. Aplicarea unei logici complexe în interogări (queries) duce la performanță lentă și consum enorm de memorie. Iată deci unde trebuie să optimizăm și să găsim o modalitate de a asocia acele relații la baza de date, drept o relație schemă.

Lăsați baza de date să lucreze pentru voi.


Auto-referința (self reference) – modul unui obiect de a se referi la sine însuși – pare să fie tratată foarte diferit în limbajele orientate pe obiecte. În timp ce în limbajele statice asemănătoare cu Java, cuvântul this este magic, direct și în mare parte nefolosit, în Javascript, magia poate să deruteze. Și totuși, în Python, unii l-ar putea descrie drept ”explicit în mod redun-

dant”.

În alt limbaj dinamic, Ruby, self acționează foarte similar cu this din Java, dar metodele nu sunt obiecte nici acolo. Este această varietate de comportamente datorată deciziilor întâmplătoare de design, sau există vreun tipar comun în toate aceste limbaje OO?

Aș vrea să vă propun un experiment de gândire. Vom încerca să creăm un limbaj OO care să aibă anumite trăsături confor-tabile din limbajele de mai sus. În timp ce creăm acest limbaj, ne vom întâlni cu anu-mite situații care să sperăm că vor clarifica de ce auto-referința (self reference) este tratată atât de diferit. De asemenea, vom vedea cum auto-referința se potrivește cu alte funcționalități ale limbajelor noastre preferate.

Limbajul pe care îl creăm va fi un lim-baj scris static, dar vom permite înlocuirea dinamică a tuturor membrilor dacă aceștia mențin contractul static. Cu alte cuvinte, întocmai cum am putea schimba o valoare a atributului unui întreg de la 4 la 5, noi putem redefini ceea ce fac metodele, în timpul de rulare, atâta timp cât semnă-tura (numele, tipurile, tipul returnat etc. al parametrilor formali) rămâne aceeași. Aceasta ne oferă toată siguranța de compi-lare de care avem nevoie, dar ne și permite puțină magie neagră dacă ne dorim cu adevărat. Vom avea de asemenea funcții, deoarece uneori ne plac astea, iar acestea vor fi obiecte. Pentru a condimenta puțin, vom face metodele rezidente (citizens) de primă clasă și obiecte de asemenea, deoarece ne-ar plăcea să le trecem drept argumente (tipar observator cu numai un callback).

Nu vor exista modificatori de vizibi-litate, aceștia sunt irelevanți pentru acest argument: totul este public.

Dacă se ivește vreo confuzie legată de cuvântul ”obiect”, să îl păstrăm simplu: obiectele sunt instanțe ale claselor. Mai în detaliu, obiectele au o relație specială cu o altă entitate, ceea ce descrie (cel puțin în

parte) comportamentul și structura obiec-tului dat.

Dați-mi voie să fac un rezumat:• scriere statică• obiectele sunt instanțe ale claselor• casele au metode• clasele, metodele și funcțiile sunt

obiecte• metodele și funcțiile pot fi înlocuite

în perioada de rulare Haideți să vedem, nu? Iată prima

noastră clasă, denumită în mod adecvat First. class First { int x Constructor(int x){ this.x = x } int double_the_fun(){ return 2 * x }

} Asta ar trebui să pară cunoscut celor care lucrează în limbaje inspirate de Java. Am definit o clasă cu un atribut de date care va fi o valoare a unui întreg și stabilim valoarea sa în constructor. Avem de ase-menea o metodă care returnează valoarea acestui atribut multiplicată cu 2. Deja în acest exemplu simplu, aveam nevoie de o modalitate de a face referință la atributul obiectului (cel puțin) din interiorul con-structorului său. De ce a fost necesar acest lucru? Pentru că noi umbrim atributul x cu parametrul formal al aceluiași nume. De aceea, aici, auto-referința este utilizată pentru a accesa câmpul (scope) care este bagajul de atribute ale obiectului. Am promis funcții libere, deci, iată una:

int triple_the_fun(int x){ return 3 * x

}

Am promis, de asemenea, și metode care pot fi înlocuite dinamic, deci, dacă am uita pur și simplu pentru o clipă tot ce ne-a învățat programarea orientată pe obiect (OO), am face asta:

First.double_the_fun = triple_the_fun

Noi am tratat metoda double_the_fun exact precum am trata un atribut de date simplu (integru, de exemplu). Un pic ciu-dat pentru unii dintre noi, știu.

Am putea apela conceptual această nouă metodă astfel:

var my_instance = new First(3)my_instance.double_the_fun(3) #

ar returna 9

Funcționează, nu-i așa? Nimic nu pare greșit, cu excepția faptului că poate ne-ar fi plăcut ca noua metodă , dou-ble_the_fun să utilizeze valoarea lui x care este deja stocată pe obiect. Ne-ar plă-cea ca my_instance.double_the_fun()să returneze 9 fără a reda un întreg, sau a face lucruri urâte precum my_instance.double_the_fun(my_instance.x).

Următoarea mișcare pe care o voi încerca, va face iadul să se dezlănțuie, deci este importantă: Ce ar fi să punem cuvântul cheie this în interiorul definiției funcției originale triple_the_fun?

Ei bine, am promis scriere statică cel puțin pentru ceea ce este vizibil înainte de perioada de rulare. int triple_the_fun(){ return 3 * this.x

} Deci ce e în neregulă cu această funcție acum? Se pare că în orice limbaj, și în special în cele care se scriu în mod static, ca și al nostru, așa ceva este urât, dacă nu chiar imposibil de făcut, deoarece am promis că funcțiile sunt de asemenea și obiecte. Fiind obiecte, înseamnă că ele au de asemenea și o clasă, să spunem clasa Function, care are la rândul său atribute și metode. Deci, cuvântul cheie this se re-feră la membrii definiți în clasa Function sau în clasa First?

Haideți să încercăm să clarificăm această ambiguitate și să propunem niște soluții alternative:

1. Să acceptăm că this se referă la 2 lanțuri moștenite. Imaginați-vă că

A fi sau a nu fi un obiect: despre problema auto-referinței

programare



am subclasat ambele clase: Function și de asemenea First (lanțul 1: subclasele Function ->… -> Function și lanțul 2: subclasele First ->… -> First). Vom obține atributul this.x de oriunde apare (acordând prioritate unuia dintre aceste câmpuri). Problema aici este că, dacă atributul se găsește în ambele câm-puri, tocmai am pierdut o modalitate de a obține pe unul dintre ele. Sintaxa explicită asemănătoare celei din Java, First.this.x VS Function.this.x nu ne poate ajuta prea mult, pentru că atunci când funcția nu este stabilită drept metodă, tot codul din ea trebuie să fie valid înainte de momentul de rulare, de asemenea (iar First.this.x nu ar fi). Mai mult, tipul atributului x s-ar putea să difere de definiția sa din clasa Function versus clasa First, deci codul fie s-ar strica atunci când utilizăm obiectul drept o funcție sau drept o metodă. Acceptarea a 2 lanțuri moștenire ar putea să funcționeze mai bine în limbajele dinamice, dar și aici ambiguitatea este mai dificil de rezolvat. Nici un limbaj pe care îl cunosc nu face asta.

2. Să acceptăm că această situație se întâmplă și să introducem 2 cuvinte cheie magice. Haideți să luăm cuvintele cheie caller și this. Cuvântul cheie this ar indica clasa Function, iar caller ar indica clasa First. Caller ar putea fi nul, deoarece funcțiile ar putea deveni limitate (bound), iar metodele nelimitate (unbound) pe perioada de rulare. Asta nu este prea frumos să facem în limbajele scrise static, deoarece caller ar putea lua orice tip și noi ar trebui să verificăm tipul său și să îl atribuim înainte de utilizare. Acesta este un lucru ce poate fi făcut, dar nu știu nici un limbaj care să facă așa ceva.

3. Pur și simplu alegeți unul dintre

acele câmpuri (scopes) și uitați de celălalt. Se pare că Javascript face ceva foarte simi-lar cu asta. După cum probabil mulți știți, în Javascript, this se referă întotdeauna la câmpul obiectului său caller (sau obiectul window global), nu la acela al obiectului original, unde funcția a fost definită drept un atribut. Delegații lui C# și Procs și lambdas din Ruby merg în direcția opusă. Rămân întotdeauna legate de clasa în care au fost definite (de asemenea, instanțele delegate nu sunt obiecte reale, deci this nu ar putea niciodată să se refere la vreo metodă delegată sau vreun atribut delegat. Ruby procs și lambdas sunt obiecte reale, dar acestea sunt create într-un asemenea mod în care să nu se refere niciodată la ele însele cu magicul self).

4. Renunțați la magia lui this . Să îl facem doar un parametru obișnuit și, de asemenea, chemați-l ori de câte ori doriți. După cum știu unii, Python face asta. Această soluție nu convine unora, pentru că fiecare metodă și funcție care se dorește a fi utilizată drept metodă trebuie să accepte un argument adițional.

5. Faceți situația imposibilă, nepermițând metodelor să fie obiecte. Aceasta este ceea ce fac Java, C#, Scala (limbajele scrise static), dar și Ruby (dina-mic). Chiar dacă toate aceste limbaje încearcă să meargă un pas mai departe cu lambdas (Java), delegați și lambdas (C#), funcții native (Scala), procs și lambdas (Ruby), aceste construcții sunt toate foarte diferite de obiectele obișnuite și nu au nicio modalitate de a se referi la ele însele.

Sper că acum este puțin mai clar cum toate aceste limbaje au încercat să rezolve aceeași problemă, dar pur și simplu au venit cu soluții diferite.

Înainte de a încheia, aș vrea să mai aduc în discuție o altă problemă

interesantă: definițiile în serie. Ce se întâmplă când o clasă este definită în inte-riorul unei metode, care este definită în interiorul unei funcții, care este defi-nită în interiorul unei metode și așa mai departe? Magia auto-referinței începe să dispară în situații ca aceasta, deoarece am avea nevoie de o sintaxă suplimentară, mai complexă, pentru a accesa câmpurile împrejmuitoare (enclosing scopes). Java are sintaxa ClassName.this.attribute, iar alte limbaje s-ar putea să aibă ceva ase-mănător, dar aceasta nu rezolvă problema decât parțial. În cele din urmă, totuși, complexitatea rețelei câmpurilor (scope nesting) face dificilă utilizarea unei auto-referințe magice. În acest punct, soluțiile pentru încercarea de a accesa obiectele înconjurătoare (precum bine-cunoscu-tul var that = this; din Javascript) ajung să semene cu verbozitatea foarte explicită a lui Python. Orice referire la obiectele înconjurătoare va fi tratată expli-cit în situații ca aceasta. Poate că nu este o coincidență că Python este un limbaj atât de reflexiv. Plătind prețul verbozității, el modelează mult mai multe lucruri drept obiecte, fără a-și face deloc griji în legă-tură cu auto-referința.

În concluzie, am dorit să arăt că diversitatea implementărilor nu este o alegere pur întâmplătoare sau exotică, ci a fost influențată de o problemă autentică. Aceasta limitează decizia în legătură cu ce poate fi modelat drept un obiect într-un limbaj OO, și cum facem referire la câm-puri (scopes). De asemenea, nu vreau să susțin nicio modalitate anume a vreunui limbaj de a implementa programarea ori-entată pe obiecte (OOP), deoarece sunt sigur că limitările problemei vor face ca toate implementările să aibă argumente pro și contra.

Vlad Ardelean [email protected]

Software Developer @ 3Pillar Global Romania


I Love I Hate NY este o aplicație iOS destinată tuturor persoanelor care au vizitat, vor vizita sau locuiesc în orașul New York. Aplicația reprezintă cel mai bun mod de a reda un feedback clar asupra orașului, ținându-se un anumit scor care acționează

asemeni unei balanțe dintre comentariile pozitive și cele negative. Un utilizator va putea oricând să-și facă o impresie asupra “pulsului” orașului privind scorul.

Figure 1: App Icon

Motivația ideii a venit din observa-rea dorinței utilizatorilor de a-și exprima propria părere referitoare la un anumit domeniu, în cazul nostru orașul New York, și în același timp implicarea uti-lizatorilor într-un mediu competitiv, în care comentariile de feedback pozitive și negative sunt considerate puncte și anumite animații fiind implementate pe baza raportului dintre cele două tipuri de comentarii. Utilizatorul va observa în mod

direct și “real time” aportul pe care comen-tariul lui îl va avea, acesta fiind contorizat și clasificat în funcție de destinație. Orice comentariu adăugat de un utilizator va fi disponibil în secțiunile de căutare, la fel ca și în funcționalitățile de filtrare ale comen-tariilor pe baza datei adăugării lui.

Principalelor funcționalitățiFiecare utilizator al aplicației va avea

posibilitatea să adauge un comentariu de feedback pozitiv sau negativ în funcție de experiența pe care acesta a avut-o în New York, de asemenea, în cazul în care acesta este doar un potențial vizitator al orașului, va putea urmări în permanență “pulsul” aplicației, acesta fiind determinat de raportul dintre comentariile de feedback pozitive și cele negative.

Screen-ul de adăugare al unui comen-tariu conține un “love smiley face” în cazul în care feedback-ul este unul pozitiv sau un “hate smiley face” în cazul adăugării unui feedback negativ:

I Love I Hate NY

Tudor Stă[email protected] IOS developer @3 Pillar Global

startups



Utilizatorii vor avea opțiunea de a distribui (a da share) comentariul postat. Prin apăsarea butonului “Post”, comentariul respectiv este trimis la server și salvat, urmând să fie afișat alături de toate celelalte comentarii.

Pentru a scoate în evidență funcționalitatea balanței comen-tariilor adăugate, anumite animații care au loc între cele două smiley face-uri, au fost introduse. Acestea își schimbă poziția în funcție de raportul dintre comentariile de feedback pozitive și cele negative.

Utilizatorii pot filtra toate comentariile introduse în funcție de perioadă, astfel ei vor avea la dispoziție trei opțiuni pentru a vizualiza comentariile în funcție de data la care au fost adăugate:

• “All” – aceasta opțiune va afișa toate comentariile pozitive sau negative adăugate de toți utilizatorii aplicației.

• “Last 24h” – vor fi afișate doar comentariile care au fost adă-ugate în ultimele 24 de ore. Această opțiune se preconizează a fi folosită de amatorii de “city break”-uri, astfel încât va oferi o imagine asupra ceea ce s-a întâmplat în orașul respectiv în ultimele 24 de ore.

• “Last Month” – este o opțiune care, după cum sugerează numele, va afișa toate comentariile adăugate în ultima lună.

Screen-ul principal al aplicației va include afișarea tuturor mesajelor în conformitate cu regulile de history selectate de uti-lizator și animațiile aferente balanței de comentarii pozitive și negative.

După cum se poate observa în imaginea prezentată mai sus, “love smiley face”-ul a împins balanța spre dreapta datorită faptului că feedback-ul pozitiv rezultat are o pondere mai mare

decât cel negativ, “scorul” fiind evidențiat direct utilizatorului.

Pentru adăugarea unui comentariu pozitiv, un utili-zator va apasă butonul “Love”, acesta fiind introdus în screen-ul de adăugare al unui nou comentariu având imaginea “love smiley face”, iar pentru adăugarea unui feedback nega-tiv, se va apăsa butonul “Hate”, de data aceasta utilizatorul fiind introdus în screen-ul de adăugare al unui nou comen-tariu având imaginea de “hate smiley face”.

Utilizatorii pot accesa orice comentariu adăugat din lista și vor fi introduși în screen-ul de detalii al fiecărui comentariu,

unde se vor prezenta titlul comentariului, textul și imaginea afe-rentă comentariului respectiv, dacă este pozitiv sau negativ. Din același screen ei vor avea posibilitatea să adauge un nou comenta-riu apăsând butonul “Post a Feedback”.

De fiecare dată când se va introduce un nou feedback, se va prezenta utilizatorului a nouă animație în funcție de comentariul introdus, dacă acesta este un feedback pozitiv sau negativ. În cazul în care feedback-ul introdus este unul pozitiv, “hate smiley face”-ul va lua foc și va fi împins înspre dreapta de către “love smiley face”, în cazul contrar animația se va desfășura in direcție inversă.

Alături de funcționalitățile prezentate, fiecare utiliza-tor va avea opțiunea de a căuta după cuvintele cheie folosind funcționalitatea de căutare disponibilă în aplicație. În cazul în care nu este decis asupra anumitor cuvinte “cheie” de căutare, el are la dispoziție funcționalitatea de Trending Searches prin care cuvintele cheie căutate de alți utilizatori vor fi afișate.

Scurte detalii tehniceAplicația I Love I Hate NY se desprinde ușor de la design

pattern-ul clasic “client-server”, aceasta migrând majoritatea procesării datelor pe partea de client, iar server-ul va fi folosit strict doar pentru stocarea datelor, astfel îmbinând cu succes un design arhitectural de tip “peer-to-peer”, format din clienți inteligenți capabil să gestioneze datele globale și să editeze resur-sele venite de pe server, urmând apoi salvarea lor, după tiparul clasic “client-server”.

Figure 2: Main Screen


Figure 3: Main Screen with Flame Animation

Pentru implementarea acestui mecanism s-a folosit framework-ul Parse, versiunea dedicate platformei iOS, care faci-litează stocarea și scrierea de date pe serverele puse la dispoziția dezvoltatorilor de platforma Parse.

Acest mod de abordare a dezvoltării aplicațiilor mobile și a migrării unei părți din business logic de pe server pe partea de client, poate fi foarte utilă startup-urilor, deoarece oferă o posibilă soluție la o mai bună gestionare a resurselor financiare. Serverele Parse pot fi configurate și utilizate cu foarte mare ușurință de către dezvoltatorii aplicațiilor mobile fără a fi nevoie de cunoștințe de dezvoltare a aplicațiilor back-end, lucru care oferă o perspectiva pozitivă asupra velocității proiectului și a resurselor financiare care vor fi utilizate pentru implementarea proiectului respectiv.

Overview Diagram

Figure 4: Overview Diagram

Parse Framework În vederea îmbunătățirii comunicării dintre aplicație și ser-

verele Parse s-a implementat clasa ParseManager, cu acest rol. Datorită faptului că modelul Parse acceptă un număr limitat de tipuri de date, orice obiect mai complex va trebui redus la astfel de tipuri de date pentru a fi salvat pe server, motiv pentru care arhi-tectura aplicației trebuie dezvoltată în considerație cu modelul bazei de date care va fi salvat folosind serverele Parse.

Toate obiectele de genul Feedback și Trending Search au echi-valentul atât in bazele de date ale serverelor Parse sub forma de PFObjects (Parse Framework Objects) cât și în Modelul definit al aplicației, acesta fiind resetat cu fiecare reactualizare a datelor, astfel încât în orice moment, utilizatorul va avea în față ultima versiune a bazei de date cu toate comentariile de feedback adău-gate in funcție filtrul specificat.

Modelul de comunicare implementat cât și modelul de date, facilitează scalabilitatea proiectului. Noi tipuri de obiecte sunt definite foarte ușor și au ca efect o mai bună performanță a tim-pului de răspuns.

Alte funcționalități utile ale platformei Parse sunt:• Data Storage ,• Local Data Storage (offline mode),• Cloud Computing,• Push Notifications Services,• Facebook Login,• Twitter Login,• Parse Analytics.

Software Design DetailsPentru o mai bună performanță și o îmbunătățire a

experienței utilizatorului, toate animațiile aplicației sunt gestio-nate de un AnimationManager. Acesta ascultă toate evenimentele utilizatorului și gestionează animațiile care vor fi efectuate pe Main Screen-ul aplicației.

Animațiile implementate au fost realizate folosind funcționalitățile de autolayout disponibile în iOS sdk. În acest fel s-au realizat animații la un nivel de complexitate mult mai înalt și performant, algoritmii fiind considerabil simplificați față de soluția implementării direct pe proprietatea de frame a fiecărui . Animația de tip fire aplicată celor două “smiley face”-uri prezente în aplicație, a fost realizată folosind clasa CAEmitterLayer, aceasta făcând posibilă adăugarea unui sistem emițător de particule peste

orice obiect de tip UIView. Acest lucru poate fi realizat datorită faptului că CAEmitterLayer este o subclasă a CALayer, deci poate fi adăugat cu ușurință ca sub-layer la orice obiect de tip UIView.

Implementarea emițătorului de particule folo-sind clasa CAEmitterLayer a evitat introducerea librăriei Cocos2D în proiect, fapt care ar fi afectat performanța. Datorită utilizării primei soluții, s-au valorificat în mod optim facilitățile grafice suportate de platforma iOS și s-a atins performanța maximă în ceea ce privește timpul de execuție, complexitatea și

memoria folosite.

startupsI Love I Hate NY



Prin intermediul clasei menționate în secțiunea precedentă, ParseManager, se realizează întreaga comunicare cu serverele Parse, decărcarea obiectelor de feedback, actualizarea obiecte-lor de Trending Search cât și transmiterea notificărilor aferente aplicației atunci când toate obiectele au fost încărcate în aplicație, astfel se asigură integritatea și validitatea datelor primite.

Funcționalitatea de share din cadrul aplicației a fost reali-zată folosindu-se framework-ul Social disponibil în platforma iOS, din nou evitându-se folosirea altor framework-uri externe care ar fi afectat memoria folosită de către aplicație la instalare și performanța vitezei.

Dezvoltări ulterioare“I Love I Hate” nu reprezintă altceva decât o idee al cărei

“proof of concept” s-a concretizat prin aplicația iOS “I Love I Hate NY”. Pe viitor este luată în considerare și implementarea altor versiuni ale aplicației destinate altor orașe care pot fi consi-derate atracții turistice sau altor domenii de interes.

Pentru versiunile ulterioare sunt luate in considerare urmă-toarele funcționalități:

• Posibilitatea de a oferi replica unui feedback,• Push notifications,• Distribuire pe diferite platforme de socializare și prin mail,• Introducerea locației unui anumit feedback ,• Modul Offline,• Funcționalitatea de Login .


La ACADEMY+PLUS se ajunge după o testare online și după o preselecție difi-cilă - Piscina de 28 de zile. Primul an academic a început în noiembrie 2014, iar prima generație se află în etapa obligatorie de internship. Flexibilitatea progra-

mului constă și în faptul că această etapă poate fi făcută oricând în funcție de rezultatele avute la proiectele din academie. Astfel, datorită performanțelor atinse, elevii Academiei au început stagii sau chiar s-au angajat în firme de IT.

Treisprezece dintre ei ocupă locuri la birourile din PITECH+PLUS, în aceeași clădire cu sediul academiei. Povestea fie-căruia dintre ei este diferită. Au ajuns să lucreze pe diverse roluri, de aceea am decis să le facem cunoscută evoluția, pen-tru a vedea ce poate însemna experiența ACADEMY+PLUS (A+) după câteva etape parcurse.

Cum se ajunge la academie?În funcție de vârsta fiecăruia și

ocupațiile lor, fiecare candidat a avut propria motivație pentru a urma această academie și a aflat de existența ei din diverse surse. Fiecare Piscină are parte de o diversitate care ajută la formarea elevi-lor. Background-urile diverse, nivelul de experiență diferit și vârsta, sunt factori importanți care contribuie la o dezvoltare multilaterală a acestora.

Prezentările de la liceu i-au făcut curioși pe Paul și pe Luca. Erau în clasa a 12-a, știau că vor să facă facultatea de informatică, au intrat la UBB și au apli-cat și la Academie. Astfel, ultima lună de vacanță și-au petrecut-o în Piscină.

”Inițial am crezut că e prea frumos să fie adevărat. Ne-au prezentat o platformă cu exerciții și jocuri. Era și gratuit. După trei zile de Piscină voiam să mă las, pentru că nu era deloc ușor. ”- a spus Luca. La fel s-a întâmplat și în cazul lui Vlad în Târgu-Mureș. Staff-ul A+ a fost și în licee din alte orașe, să prezinte programul. ”Oricum îmi doream să merg la facultate în Cluj. Academia era un bonus. Am intrat la Poli și am trecut de Piscină în luna august.”

”Profa ne-a recomandat să mergem și cum eram mai mulți am încercat cu toții. În piscină am tras unii de alții, ne-am motivat reciproc”. – recunoaște Marius

Elevii ACADEMY+PLUS

în internship-uri și poziții de junior

educație

Gloria [email protected]

Marketing Specialist @ Pitech+Plus



care a ales să urmeze cursurile de la FSEGA, Informatică economică.

Andrei a aflat de pe un link pe Facebook în timp ce era plecat în vacanță. ”O dată ajuns acasă am făcut testele, am trecut și am intrat în cea de-a treia pis-cină. A fost cea mai bună decizie pe care puteam s-o iau. Era octombrie, prima lună din ultimul an la facultate. Cu ingi-neria medicală nu aveam perspective prea largi, iar IT-ul m-a atras dintotdeauna. ACADEMY+PLUS părea o oportunitate bună de a intra în domeniu.”

Alina a făcut liceul de muzică și nu voia să urmeze o facultate, își dorea o formă de învățământ neconvențională. ”Știam de școala 42 din Franța, am des-coperit-o pe internet și am început să caut ceva asemănător. Așa am dat peste A+.

N-am vrut să fac testele, am crezut că nu o să trec, dar am încercat.” Academia s-a promovat în perioada BAC-ului la liceele unde se dădeau probele de info. ”Pe mine m-au prins chiar după ce am ieșit de la BAC. Erau niște fete cu tricouri cu mesaje geeky care mi-au povestit despre A+. Am făcut testele și am intrat în piscină.”- își amintește Daniel râzând.

PISCINA28 de zile intense cu exerciții zilnice,

examene săptămânale, proiecte individu-ale ori de grup – deadline-uri exigente, punctaje stricte.

Pentru Gabi, care și-a dorit să facă aca-demia pentru a-și schimba profesia, a fost o adevărată provocare. A terminat Instalații și avea un job de 8 ore. De trei ani cocheta

cu programarea, a făcut cursuri online, însă acestea ”nu se compară cu ce se întâm-plă în academie, unde e alta motivația, ai colegi care te ajută, cu care te poți sfătui”. ”A fost wow, a fost greu. Plecam de la job, stăteam până pe la 11-12. Dimineața o luam de la capăt, job, academie și asta timp de 28 de zile.” - mărturisește zâmbind Gabi. Ligia era și ea angajată, însă știa că nu o să rămână în domeniu pentru că voia mai mult. ”După ce am terminat Masterul am reluat puțin programarea, pentru a-mi aminti ce făcusem în liceu. Îmi căutam un job și aș fi vrut să încerc în IT. Am terminat Ingineria Construcțiilor și am găsit un job în domeniu. Dar am văzut la TV o emisi-une despre A+ și am dat testele. Piscina a fost o perioadă grea. Job, piscină, job, pis-cină. Dar a meritat. Am primit ofertă de


job din mai și mă bucur că am ajuns în PITECH+PLUS”.Pentru Andrei a fost ”Cel mai bun regim de slăbit, dar mai

ales cel mai bun regim pentru a te educa. Am învățat să privesc altfel lucrurile, timpul a căpătat noi dimensiuni, organizarea era cuvântul cheie pentru a reuși să faci cât mai multe într-o zi. Mai multe astfel de zile se transformă în obișnuință.” Și în cazul lui a fost puțin mai greu, însă a demonstrat că se poate să fii în ultimul an la Politehnică, la o specializare care nu are legătură cu infor-matica, să îți iei examenele și licența, să treci de piscină și să te ții de academie.

Materia din piscinăLegat de ceea ce au învățat fiecare în piscină, teoretic și prac-

tic, au fost cu toții de acord că se învață exact ceea ce trebuie. C-ul e baza, iar proiectele pe care trebuiau să le finalizeze le-au format modelul de gândire. O dată înțeleasă și sedimentată algoritmica, gândirea logică se formează, iar ceea ce a urmat după proiectele din preselecție părea mai ușor, aceasta indiferent de nivelul lor de cunoștințe atât de diferit.

”Ai la dispoziție un volum mare de informații. Ceea ce mi-a plăcut e că poți tu să-ți structurezi așa cum vrei informațiile, să cauți mai mult despre ce te interesează, nu ți se impune nimic.” – spune Sami.

”A fost singurul lucru greu care chiar mi-a plăcut” – recunoaște Anca cu puțină nostalgie. Studentă în anul 2, a dorit să-și completeze studiile de la Info UBB cu ceva practic, care să o ajute să-și dea seama în ce direcție să meargă, pe ce ramură să se angajeze. Piscina a învățat-o să fie organizată cu timpul ei și să știe cum să se raporteze la deadline-uri, care uneori tot în al 12-lea ceas ajung să se finalizeze, ca și în cazul proiectelor de la școală.

Anul academicÎn noiembrie au început cu toții cursurile academiei, unde

ritmul nu a mai fost atât de alert ca și în piscină, însă a crescut nivelul de dificultate al proiectelor, după cum recunosc cu toții. Au avut tot mai multe proiecte de grup în care trebuiau să formeze o echipă pentru a evolua. Cu toții cred în puterea comunității: ”Chiar dacă sunt diferențe mari de vârstă, avem cu toții progra-marea în comun, pasiunea pentru cod și asta ne leagă.”- Daniel

Academia i-a ajutat pe Paul, Luca, Vlad și Anca pe parcursul facultății să înțeleagă mai bine, mai practic ceea ce fac la cursuri, proiectele se regăsesc atât în proiectele de la Babeș, cât și de la Poli. ”Se completează materia”.

Alinei nu i s-a părut greu, ”erau multe lucruri noi și îmi plăcea mult atmosfera. Am avut parte de mulți oameni optimiști, care au crezut în mine.”

Ce au învățat și ce le-a plăcutCele patru module învățate în primul an sunt Unix,

Algoritmie, Infografie și Web. ”Algoritmia și Infografia sunt cele mai faine. La infografie vezi efectiv ceva ce iese din mâna ta, vezi rezultatul muncii tale pe monitor.”– zice Sami.

Marius a participat și la 3 Day Startup împreună cu colegi din academie și de atunci, cu echipa formată acolo a lucrat și FrontEnd . ”Era o aplicație web și mobilă pe care se actualiza starea pârtiilor prin review-uri și comentarii. Mi-am dat seama că îmi place partea asta de FrontEnd și m-am bucurat că m-am putut angaja deja, să fac exact ceea ce îmi place.”

Când e bine să faci aceste cursuri?Exemplele atât de diverse ne fac să credem în continuare

că oricând este momentul potrivit pentru a urma Academia.

educațieElevii ACADEMY+PLUS în internship-uri și poziții de junior



Condițiile esențiale sunt însă motivația și pasiunea pentru programare. Dacă ai voință se poate începe oricând, fie că ești în ultimul an de facultate, fie că ai deja un job.

Dar Paul recunoaște că, dacă ar fi fost încă la liceu, nu s-ar fi ținut de Academie, așa, în paralel cu facultatea i se pare cea mai bună rețetă.

”Academia în sine e mult mai lejeră decât Piscina. Poți să o faci de acasă, împreună cu școala sau jobul.” spune Ligia.

Planuri de viitorAlinei i-au plăcut toate modulele pe care

le-a făcut: ”Nu știu încă ce vreau să fac, vreau să învăț mai multe. Mă bucur că am făcut internship-ul pe Sys Admin, și aștept anul doi să văd ce o să mă atragă în continuare.”

Nici Vlad nu știe încă ce își dorește, dar internship-ul pe mobile l-a ajutat să-și facă o idee mai bună. ”Aș vrea mai mult partea de programare, decât web, mă interesează mai mult funcționalitatea aplicațiilor.”

Ligia este angajată din mai ca Business Analyst, și așteaptă următorul an pentru a învăța și alte limbaje. ”Consider că cel mai bine e să învăț mai multe limbaje dacă am ocazia, asta o să îmi ofere mai multe posibilități pe viitor. Nu vreau să știu doar ceea ce se cere acum pe piață.”

Daniel ar vrea să rămână pe Sys Admin, dar vrea să continue și academia. ”Îmi place mai mult decât developmentul, Sys Admin-ul necesită mai multe cunoștințe generale, îți dezvolți puterea de analiză.”

”Cel mai mult m-a atras PHP-ul și am ajuns să lucrez pe Zend. Sper să am ocazia să aprofundez Typo3, și posibil pe viitor să mă îndrept spre Symfony.”- spune Andrei.

Bogdan Herea, CEO PITECH+PLUS, fondator ACADEMY+PLUS a afirmat în legătură cu activitatea academiei din anul 2015 următoarele:

”Anul 2015 vine cu schimbări în ceea ce privește platforma de pe care vor învăța cei care trec de Piscinele din vara asta și pentru cei care vor continua anul 2. Aceștia vor putea alege limbajele pe care vor să le învețe și să le aprofundeze. Astfel au ocazia să își crească nivelul de cunoștințe, dar să îl și diversifice în cazul în care nu știu încă ce anume le place.

De asemenea, ne dorim să încheiem cât mai multe colaborări cu firmele de IT inte-resate de forța de muncă. În academie se formează oameni pe cele mai diferite tehno-logii și sunt soluția pentru cererea actuală de pe piața de IT.”


Din perspectiva impozitării, orice bun, serviciu sau sumă de bani oferită salariaților, dacă nu intră într-una din excepțiile expres evidențiate de legislația în vigoare și pentru care nu s-au întocmit documentele necesare pentru a fi încadrate în categoria respectivă, reprezintă salarii plătite în natură, pentru care trebuie să se rețină toate contribuțiile și impozitul pe venit.

În mod similar, în cazul asociaților participanți la societate, bunurile, serviciile sau sumele de bani care nu intră într-una din excepțiile prevăzute de lege sau pen-tru care nu s-au întocmit documentele justificative necesare pentru a fi încadrate în categoria respectivă vor fi socotite divi-dende și se va calcula impozitul aferent. În plus, pentru decontarea acestor cheltuieli personale se datorează și impozit pe pro-fit, deoarece sumele sunt nedeductibile la calculul impozitului pe profit.

Scutirile prevăzute de lege

DiurnaReprezintă indemnizația acordată

personalului angajat și doar personalului angajat pentru deplasările efectuate pe distanțe mai mari de 5 km de localitatea în care își are sediu permanent.

Art. 55 alin. (2) lit. i) din Codul fis-cal, prevede faptul că până la cuantumul de 2,5 ori indemnizația stabilită pentru sectorul public, nu se datorează impozit pentru diurnele acordate legal salariaților.

De asemenea, prin art. 296^15 lit. g) din Codul fiscal se prevede că în același cuantum, nu se datorează nici contribuții sociale.

În ultima formă a Codului Fiscal, nu se amintesc aceste indemnizații în rândul cheltuielilor deductibile, articolul fiind abrogat. Cu toate acestea, în practică se socotesc deductibile, cel mai uzat articol pentru justificare fiind art. 21. Alin. 1 din Codul fiscal.

Diferența de sume acordate ce depășește plafonul de 2,5 ori indemnizația stabilită pentru personalul din sistemul bugetar vă fi socotită avantaj în natură, se vor calcula contribuții și se va reține impo-zitul aferent.

Pentru personalul din sistemul bugetar valoarea diurnei este definită prin HG nr. 1860/2006 privind delegarea și deplasarea, cu modificări ulterioare. Ultima modi-ficare a intrat în vigoare de la 1 ianuarie 2015 și a ridicat nivelul diurnei la 17 lei pe zi, ceea ce înseamnă că pentru sectorul privat, valoarea deductibilă a diurnei este de 42,5 lei. Această valoare se aplică pen-tru deplasările în cadrul României. Pentru diurnele externe, sunt prevăzute valori pentru fiecare țară în parte în monedele locale.

Acest lucru înseamnă că pentru diurnele plătite salariaților ce depășesc plafoanele amintite se datorează impozite și taxe similar salariilor de aproximativ 52%.

Mai amintim și faptul că legea nu

impune o valoare minimă sau maximă a diurnei, aceasta fiind stabilită între anga-jator și salariat.

Cheltuielile de transportÎn cazul cheltuielilor cu transportul se

vorbește de mai multe spețe posibile pe care le vom detalia în rândurile următoare.

Decontarea transportului când anga-jatul este stabilit în alta localitate decât cea de unde este locația punctului de lucru unde se desfășoară activitatea.

Conform art. 55 alin. (4) lit. f) și art. 296^15 lit. f ) din Codul fiscal, nu sunt asimilate veniturilor din salarii și nu se vor reține impozitul pe venit aferent și contribuțiile pentru decontarea cheltuieli-lor de transport la și de la locul de muncă, în cazul în care nu se asigură locuință sau se suportă cheltuielile cu chiria. Plafonul maxim este echivalentul unui abona-ment lunar. Pentru aceste cheltuieli nu se specifică obligativitatea înscrierii unor prevederi în contractul de muncă sau con-tractul colectiv de muncă.

Dacă salariatul primește o mașină de serviciu, iar acesta efectuează trans-portul pe distanța domiciliu-localitatea de serviciu, există mai multe situații fis-cale ce trebuie dezvoltate punctual, în funcție de existența transportului public și suprapunerea transportului public asu-pra programului de lucru. Dacă există transport public, TVA de la combustibili

Beneficiile extrasalariale sub lupă în 2015

Având în vedere faptul că preocuparea principală al organelor fiscale cu atribuții de control a fost în acest an identificarea altor venituri de natură salarială sau asimilate salariilor, am considerat oportună o trecere în revistă a principalelor cheltuieli efectuate de către companii, aparent în beneficiul direct al angajaților, dar care pot fi reinterpretate ca avantaje în natură și

impozitate ca atare.

contabilitate


este cheltuială nedeductibilă integral și se va înregistra în costul cu alimentarea autoturismului. Pentru a beneficia de o deductibilitate integrală a cheltuielilor cu combustibilii se impune obligatoriu întoc-mirea foilor de parcurs, pentru a se vedea că autoturismul este folosit în mod exclusiv pentru societate.

În lipsa foilor de parcurs, se prezumă acordarea unei deductibilități de 50% atât pentru TVA cât și pentru cheltuieli, iar autoritățile fiscale, în ultimul timp, tratează partea nedeductibilă de 50% ca avantaj în natură.

Transportul în cadrul delegațieiÎn baza art. 55 alin. (4) lit. g) și art.

296^15 lit. g) din Codul fiscal, nu sunt asimilate veniturilor din salarii acoperi-rea cheltuielilor cu transportul în cazul delegațiilor, motiv pentru care nu se vor calcula impozite și contribuții aferente.

Cheltuiala este deductibilă din punct de vedere al impozitului pe profit conform art. 21 alin. (2) lit. e) din Codul fiscal.

Cheltuieli de transport ale salariaților care sunt domiciliați în aceeași localitate ca și compania

Conform art. 55. alin. (4) lit. a), art. 296^15 lit. b) și art. 21 alin. (3) lit. c) din Codul fiscal, în cazul în care este prevăzut în contractul de muncă sau în contractul colectiv de muncă nu se va interpreta ca avantaj în natură decontarea transportu-lui la și de la locul de muncă și nu se vor reține impozite si contribuții aferente aces-tor costuri.

Normele pentru art. 21 alin. (1) din Codul fiscal regăsite la pct. 23 lit. f) din HG

nr. 44/2004 cu modificări ulterioare permit deductibilitatea integrală.

Este necesar să fie precizat în contrac-tul colectiv faptul că se pot acorda aceste facilități.

Transportul administratorilor în inte-res de serviciu

Conform art. 21. alin. (2) lit. e) din Codul fiscal, cheltuielile efectuate pentru transportul administratorilor, precum și a persoanelor asimilate administratorilor, sunt deductibile.

Decontare combustibilConform art. 145^1 alin. (1) din Codul

fiscal, pentru autoturismele care nu sunt utilizate efectiv în scopul activității, se decontează doar 50% din TVA-ul aferent combustibilului utilizat pentru autotu-rismele care nu sunt utilizate exclusiv în scopul activității economice. TVA-ul con-siderat nedeductibil va fi înregistrat ca o cheltuială cu combustibilul.

Conform art. 21 alin. (4) lit. t) din Codul fiscal, pentru autoturismele care nu sunt utilizate exclusiv în scopul activității, 50% din cheltuiala cu combustibilul ( se va lua în considerare și TVA-ul nedeductibil înregistrat ) va fi socotită nedeductibilă.

Din punct de vedere al interpretării combustibilului drept avantaj în natură sau dividend anticipat, se aplică aceleași reguli ca și pentru cheltuielile de transport menționate anterior.

Mașina de serviciuConform normelor pentru art. 55 din

Codul fiscal regăsite la pct. 77 din HG nr. 44/2004, nu se consideră venit asimilat

salariului utilizarea autoturismului de serviciu în vederea îndeplinirii sarcini-lor de serviciu, motiv pentru care nu se reține impozit și nu se rețin contribuțiile obligatorii.

În cazul în care autoturismul se va folosi în scop personal, se consideră a fi avantaj în natură și se vor calcula impozit și contribuții aferente unei valori repre-zentând 1,7% din valoarea acesteia pentru fiecare lună. (conform normelor pentru art. 55 alin. (3) din Codul fiscal regăsite la pct. 75 din HG nr. 44/2004)

În acest caz, dacă s-a dedus TVA la achiziția autoturismului, o parte din această sumă trebuie plătită la buget, soci-etatea pierzând integralitatea dreptului de deducere. Sunt două proceduri de cal-cul a TVA de plată reglementate în acest moment de art. 148 și art. 149 din Codul fiscal. Analizele trebuie dezvoltate pe un caz concret.

În acest context, dacă autoturismul este autorizat în mod personal doar parțial, într-o anumită perioadă de timp, avantajul în natură se calculează determinându-se ponderea kilometrilor parcurși în interes personal, în total kilometrii parcurși în acea perioadă.

Contravaloarea cheltuielilor calculate prin această pondere reprezintă avantaj în natură. Implicit, fără să fie menționat expres, înțelegem obligația de a întocmi foi de parcurs și atunci când utilizăm o deductibilitate de 50% în astfel de cazuri, deoarece altfel nu putem determina valoa-rea avantajului în natură.

Young spiritMature organizationA shared vision

Join our journey!

www.fortech.ro


Cheltuieli de cazare

Cazarea în cadrul delegațiilor

În baza art. 55 alin. (4) lit. g) și art. 296^15 lit. g) din Codul fiscal, nu sunt asimilate veniturilor din salarii acope-rirea cheltuielilor cu cazarea în cazul delegațiilor, motiv pentru care nu se vor calcula impozite și contribuții aferente.

Cheltuiala este deductibilă din punct de vedere al impozitului pe profit conform art. 21 alin. 2 lit. e), atât timp cât se susține cu documente scopul delegației – în folo-sul activității – vizite la clienți, furnizori, participări la târguri, expoziții, traininguri cu subiecte legate de domeniul de activi-tate. Nu putem extinde această abordare la orice cheltuială cu cazarea făcută de către administratori sau salariați, dacă nu se confirmă din documentele anexate factu-rii de cazare, că deplasarea a fost efectuată în scopul activității. În acest caz, în funcție de beneficiarul serviciilor de cazare, chel-tuiala va fi considerată un dividend, dacă beneficiarul este asociatul companiei sau un avantaj în natură, dacă deplasarea a fost efectuată de către un angajat.

Se întâmplă uneori ca documentele de cazare, în principal factură, invoice etc. să fie emise pe numele salariatului cazat în deplasare. În acest caz, cheltuiala și TVA-ul pot fi deductibile, dacă se efectuează în scopul activității. Se impune existența ordinului de deplasare anexă documente-lor de cazare conform normelor de aplicare pentru art. 146 din Codul fiscal regăsite la pct. 46 din HG nr. 44/2004 cu modificări ulterioare.

Asigurări de sănătate / pensii privateAsigurările de sănătate și pensiile pri-

vate oferite salariaților au deductibilitate de la calculul impozitului pe profit, atâta timp cât se respectă condițiile cerute de lege, după cum urmează: asigurările de sănătate într-un plafon de 250 euro pe an/angajat, iar pentru pensii, 400 euro pe an/angajat. ( art. 21 alin. 3 lit. j și k )

Asigurările de sănătate nu trebuie confundate cu abonamentele de la spi-talele private care oferă diverse forme de pachete. Asigurările de sănătate trebuie să respecte principiile impuse de legea sănătății 95/2006. Tot conform acestei legi, la art. 339 lit. i) se prevede faptul că serviciile medicale furnizate sub formă de abonament reprezintă servicii medi-cale preplătite, pe care furnizorii le oferă în mod direct abonaților și nu prin inter-mediul asiguratorilor, în afara serviciilor din pachetul de servicii medicale de bază din sistemul de asigurări sociale de sănă-tate. Astfel, acest abonament, diferit de uzualele contracte de medicină a muncii obligatorii prin efectul legii, trebuie alocat fiecărui salariat și impozitat ca avantaj în natură. Pentru asigurările de sănătate se va reține impozit pe venit, dar nu se vor reține contribuții sociale aferente.

În forma actuală a legislației din Codul Fiscal nu se prevede și varianta în care angajatul își face polița de asigurare și o prezintă angajatorului spre decontare, ci doar varianta în care angajatorul negociază cu firma de asigurare și oferă polița anga-jatului, contractul fiind între angajator și firma de asigurare.

Pensiile private trebuie să fie con-venite de Autoritatea de Supraveghere

Financiară și să fie reglementate con-form legii 204/2006. În această categorie sunt cuprinse pensiile de tip pilonul 3. Variantele de alte tipuri de asigurări, care au prevăzut ca la finalul contractului sumele cumulate să fie plătite sub formă de pensie, nu sunt acceptate în baza aces-tor reglementari din Codul Fiscal. Polițele pot fi contractate de angajator și oferite salariaților sau pot fi contractate de către salariați și prezentate angajatorului spre decontare. Pentru aceste pensii nu se plă-tesc contribuții salariale în limita celor 400 euro și, de asemenea, sumele sunt deducti-bile la calculul impozitului pe salarii.

Vouchere de vacanțăSunt reglementate de OUG 8 /2009

cu actualizările ulterioare. Conform Ordonanței, se pot acorda vouchere de vacanță într-un plafon maxim de 6 salarii minime brute pe economie, pentru fiecare angajat, în total pe an.

Aceste cheltuieli sunt deductibile în plafonul indicat mai sus și nu se calculează contribuții art. 296^15 lit. O, dar se dato-rează impozit pe venit conform normelor de la art. 55 pct. 68. Dacă până în iulie 2014 era obligatoriu ca persoana juridică să fi obținut profit în anul precedent pentru a le putea acorda, paragraful respectiv a fost abrogat prin Legea 94/2014. Voucherele de vacanță pot fi utilizate doar la unități autorizate de Autoritatea Națională pentru Turism.

Acestea vor avea valori nominale de 10, 20, 30, 40 și 50 lei. Asemenea tiche-telor de masă și a tichetelor cadou, nu se va putea acorda rest la plata cu voucherele.

Normele de aplicare pentru legea care

contabilitateBeneficiile extrasalariale sub lupă în 2015



reglementează voucherele de vacanță ar trebui să fie publicate până la începutul lunii august și ar trebui să aducă mai multe clarificări referitor la condițiile necesare a fi îndeplinite, cum ar fi: menționarea acestor facilități în contractul colectiv de muncă, încadrarea în cadrul cheltuielilor sociale, etc. .

Cheltuielile cu voucherele de vacanță sunt integral deductibile la calculul impo-zitului pe profit, fără a depăși valoarea anuală de 6 x salariul minim pe economie, pentru fiecare salariat. Voucherele sunt supuse impozitului pe venitul din salarii la nivelul persoanei fizice.

Cheltuieli „protocol” intern birouPentru societăți nu există o definiție

legală a noțiunii de protocol, singura reglementare ce explicitează această chel-tuială fiind dată în reglementările privind impozitarea PFA. Conform acestui temei normativ, cheltuielile de protocol sunt chel-tuieli de reprezentare a contribuabilului.

În prac t i c ă , în cont abi l i t ate a societăților, în această categorie includem apa, cafeaua, laptele, ceaiul, fructele, dul-ciurile și alte asemenea produse cu valoare unitară mică, care sunt folosite pentru uzul intern.

Din păcate, aceste cheltuieli sunt cele mai reinterpretate în cadrul controale-lor fiscale din anul 2015. Reglementările legale nu sunt suficient de specifice pen-tru a face o încadrare corespunzătoare acestor tipuri de tratații, totodată trebuie ținut cont și de specificul companiei, atât ca domeniu de activitate, cât și ca număr de angajați, etc. . Există cazuri când aceste mici tratații în cadrul activității au fost încadrate drept avantaje în natură și s-a calculat impozit și contribuții aferente, deși nu există practic posibilitatea alo-cării concrete a acestor cheltuieli pentru fiecare salariat, ceea ce transformă această abordare într-un act absolut subiectiv și inechitabil. Considerăm că, ajungându-se în situația de a întocmi liste cu consumul de cafea, lapte, zahăr, bomboane etc. pen-tru fiecare salariat în parte (singurul mod în care am putea trata corect aceste „avan-taje” ) îndepărtează mult compania de la obiectivul de business pe care și l-a propus și care trebuie avut în vedere –profit, cifra de afaceri, eficiența, productivitate - înspre o activitate administrativă și care implică și alte costuri nejustificate.

Aceste tipuri de achiziții nu pot fi încadrate în rândul cheltuielilor de proto-col, acestea fiind considerate ”cheltuielile

de protocol ocazionate de acordarea unor cadouri, tratații și mese partenerilor de afaceri, efectuate în scopul afacerii” și automat, legislația aferentă nu se aplică.

Beauty&spa, acces săli de sport/fitness etc.Tot mai mult în ultimii ani, pachetele

salariale ale angajaților din multinaționale, companii de IT și de servicii cuprind pe lângă salariul de bază și o serie de alte „beneficii” extra, acestea fiind extrem de importante în atragerea de noi angajați sau în fidelizarea echipelor existente. Aceste beneficii pot cuprinde, fără a se limita: abonamente la săli de sport, cen-tre de frumusețe, închirieri de terenuri de sport, bilete la concerte, spectacole și alte evenimente sociale. Din păcate, prevede-rile Codului Fiscal sunt destul de clare cu aceste alte tipuri de „remunerații în natură” și sunt considerate avantaje salariale, și impozitate ca atare, cu impozit pe venit și toate contribuțiile sociale. Încercarea de a „cosmetiza„ efectuarea acestor chel-tuieli din unele practici personale, în folosul direct al angajatului, în cheltuieli deductibile, care contribuie la optimizarea rezultatelor, nu are o bază legală stabilă și nu va fi acceptată în contextul unui control fiscal având ca obiect identificarea avanta-jelor în natură.

În concluzie, dacă ne raportăm și la impozitul pe profit, considerăm că aces-tea sunt deductibile în procentul de 2% pe seama cheltuielilor sociale atâta timp cât sunt generate de un contract individual de muncă, contract colectiv de muncă etc. .

Cadouri diverse (obiecte, îmbrăcăminte, produse alimentare, carduri cadou etc.)

Există totuși în Codul fiscal, la art. 21 pct. 3 lit. c), o limită de 2% aplicată fondu-lui total de salarii al companiei, în cadrul căreia societățile au dreptul să efectueze anumite cheltuieli, în beneficiul angajaților, fără ca acestea să fie considerate asimilate salariilor. În vederea luării unor decizii de optimizare fiscală, recomandăm a se ana-liza în detaliu și posibilitățile oferite de aceste prevederi, pentru a le putea exploata în anumite situații permise. Astfel, în categoria cheltuielilor sociale sunt înca-drate și cadourile oferite copiilor minori cu ocazia Paștelui, Crăciunului, zilei de 1 Iunie, în limita unui plafon de 150 lei, cadouri oferite salariatelor cu ocazia zilei de 8 Martie. Sumele încadrate în plafonul de mai sus sunt deductibile fiscal și nu se datorează impozit (art. 55 alin. 4 lit. a) și nici contribuții sociale ( art. 296^15 lit. b ). Sumele ce depășesc plafonul de 150

lei/ persoana, precum și acordarea lor cu oricare altă ocazie decât cele prevă-zute de lege, sunt considerate avantaje în natură și vor fi impozitate și se vor reține contribuțiile aferente.

Aceste cheltuieli sunt deductibile fiscal, în baza art. 21 alin. 3 lit. C, în limita unui plafon de 2% din fondul de salarii.

Chiar dacă cadourile oferite sunt sub pragul de 150 lei, dacă sunt oferite cu alte ocazii decât cele menționate sau către alte persoane decât cele prevăzute, vor fi con-siderate avantaj în natură și se vor reține contribuții și impozit. Mai mult de atât, dacă se depășește plafonul de 2% din fon-dul de salarii, chiar dacă se rețin contribuții salariale și impozit, pentru societate, chel-tuiala va fi nedeductibilă.

Chiar dacă exprimarea din lege este „acordarea unor bunuri în bani sau în natură”, în această categorie scutită de impozit pe venit nu regăsim tichetele cadou ce urmează un alt tratament fiscal.

Tichetele cadouConform art. 2 din Legea nr. 193/2006

privind tichetele cadou, tichetele cadou pot fi acordate intern sub formă de chel-tuieli sociale.

Fiind încadrate în această categorie, cheltuiala cu tichetele cadou va fi deduc-tibilă la calculul impozitului pe profit într-un plafon de 2% din fondul de salarii. Pentru aceste tichete se reține impozit pe venit în procent de 16% conform art. 55 alin. (3) lit. h) din Codul fiscal, dar nu se datorează contribuții sociale conform art. 296^15 lit. o) din Codul fiscal. Din inter-pretarea acestui temei normativ, respectiv scutirea la asigurările sociale acordate con-form legii, considerăm că nu se datorează asigurări sociale pentru tichetele cadou, chiar dacă cheltuiala cu acestea depășește la calculul impozitului pe profit plafonul de 2% de cheltuieli sociale. În argumentația noastră amintim că aceste tichete cadou sunt date conform legii tichetelor cadou ce presupune achiziția doar de la unități autorizate și utilizarea unor formate pre-definite, condiții îndeplinite. S-ar fi datorat asigurări sociale pentru aceste tichete cadou, dacă erau achiziționate de la unități neautorizate sau erau date la salariați într-un alt mod decât cel prevăzut în lege.

Este important ca în contractul colec-tiv de muncă să se precizeze condițiile în care se vor putea oferi aceste tichete cadou salariaților. Este indicat ca evenimentele pentru care se acorda aceste tichete să aibă caracter ocazional.


Ajutoarele de înmormântare, naștere, boli grave și incurabile

Conform art. 55. alin. 4 lit. a) și art. 296^15 lit. b), pentru aceste ajutoare nu se rețin contribuții și nici impozit. Dacă se încadrează în cei 2% din fondul de salarii atunci sunt deductibile fiscal. În caz con-trar, chiar dacă s-au reținut impozitul și contribuțiile, vor fi înregistrate drept nedeductibile.

Team building-uri, mese festive, alte ieșiri sau evenimente organizate

În funcție de scopul pe care îl au aceste evenimente vom putea sa le încadrăm din punct de vedere a deductibilității sau a reținerilor.

Astfel, în cazul în care discutăm de un eveniment care are drept scop pre-gătirea profesională și perfecționarea angajatului în legătură cu activitatea desfășurată, atunci costurile aferente vor fi deductibile și nu se vor reține impozit

pe venit și nici contribuții sociale. ( art. 21 alin. 2 lit. h , art. 55 alin. 4 lit. n, și art. 296^15 al 3 lit. k ). În vederea înca-drării în această categorie trebuie să se prezinte documente care să justifice sco-pul. Este indicat să se întocmească un dosar al acțiunii de team-building, care să cuprindă agenda desfășurată a eveni-mentului, lista participanților la fiecare training sau activitate din program. Totodată ar fi indicat să existe o abordare de ansamblu la nivelul scopului urmărit, adică o decizie a managementului privind oportunitatea efectuării acestor cheltuieli prin prisma rezultatelor ce vor fi obținute. La încheierea evenimentului sau ulte-rior, după un timp estimat, se pot evalua rezultatele obținute, prin fișe de feedback ale participanților și constatări efective ale celor responsabili (Departamentul de Resurse umane, managerii de echipe, de proiect etc.). În cazul în care scopul nu este pregătirea profesională, atunci aceste evenimente vor fi încadrate în

rândul avantajelor în natură si se vor calcula contribuții sociale și impozit în cotă parte pentru fiecare salariat prezent. Diminuarea riscului fiscal se poate rea-liza arătând în mod concret participanții la aceste evenimente, pe cât posibil actu-ali clienți sau potențiali colaboratori ai societății din perspectiva fie a furnizorilor, fie a posibililor beneficiari.

contabilitate

Adrian Beșleagă[email protected]

Manager Operatiuni @ A&I Consulting

Adrian Benta [email protected]

Consultant Fiscal @ Benta Consult

Beneficiile extrasalariale sub lupă în 2015


Când e vorba de sănătatea noastră, apelăm la un specialist. Și de obicei, îl vrem pe cel mai bun, ale cărui indicații și tratamente le respectăm atent. Nu ne luăm după ce am citit pe internet sau nu îi spunem doctorului cum să ne opereze.

Până la urmă e în joc sănătatea și viața noastră. Dar oare facem așa și când vine vorba de firma noastră?

Ne doare, dar refuzăm tratamentul re-comandat

Ne doare. Suntem conștienți de asta: nu avem echipa pe care ne-o dorim, rezul-tatele nu sunt cele așteptate sau pur și simplu echipa nu este pe cât de consolidată ar trebui. Ne doare. Sănătatea organizației noastre ,,scârțâie”, și ne hotărâm să luăm atitudine: organizăm un team building! Dar ,,ne putem trata’’ noi singuri, nu? Îl putem organiza noi, intern, până la urmă nu e chiar atât de greu! Oamenii trebuie să se simtă bine, să se distreze, facem și paintball, bungee jumping și partea de socializare va veni de la sine. Investim niște bani, timp, resurse, în ,,tratament’’ și la final observăm că nu vedem efectele dorite. Poate pentru că ,,tratamentul’’ administrat nu a fost cel corect.

Faptul că socializarea are un impact major asupra performanței echipei nu este o noutate. Evenimentele infor-male contribuie la: eliberarea stresului după o perioadă aglomerată, dezvolta-rea relațiilor interpersonale, sărbătorirea succeselor și realizărilor, oferirea unui impuls motivațional. Aceste evenimente însă nu pot substitui evenimentele ade-vărate de team building. Programele de team building au roluri si obiective dife-rite. Teambuilding-ul este ,,tratamentul’’ prin care provocăm un grup de oameni să lucreze împreună în mod eficient ca o echipă, prin intermediul unor activități și evenimente menite să crească motivația și să promoveze cooperarea. Este vorba despre un set de activități facilitate de trai-neri pentru a crește performanța echipei și a ajuta la îndeplinirea unor obiective organizaționale specifice.

Când ne doare, mergem la medic

management

Szilárd Kacsó[email protected]

CEO & Trainer @ Azimut Happy Employees


Ce trebuie să urmărească ,,tratamentul’’ administrat?Dacă ne-am dat seama că este spre binele ,,sănătății’’

organizației noastre să apelăm la un ,,doctor’’, este recomandat să urmăm ,,tratamentul’’ prescris. Chiar dacă unele etape din pro-gramul de team building nu ni se par importante, este spre binele nostru să le respectăm, pentru rezultate optime.

Care sunt elementele unui team building de la care nu ar tre-bui să se facă rabat?

1.Obiective clar def inite, corelate cu obiectivele organizaționale.

2. Program personalizat, adaptat obiectivelor programului, grupului, situațiilor specifice cu care se confruntă participanții sau stagiul în care se află echipa, locația.

3. Să faciliteze transferul de cunoștințe: pentru ca participanții să fie capabili să utilizeze cele învățate la team building și în mediul profesional este crucială prezența unui debrief calitativ.

4. Raport de evaluare a programului de team building: observațiile structurate pot fi baza unei analize de nevoi care să ajute la dezvoltarea unor programe de follow-up.

5. Program de follow-up: studii științifice [1], dar și experiența noastră ne arată că programele de follow-up (training, coaching, dezvoltare organizațională) pot asigura eficacitatea programelor de team building și creșterea performanței pe termen lung.

6. ,,Elemente speciale’’: care oferă o experiență unică participanților, ajută la îndeplinirea obiectivelor și facilitează învățarea: tematică de team building, elemente de joc (gamifica-tion), programe tematice de seară.

Cum ne poate ajuta ,,tratamentul’’ administrat corect?Dacă apelăm la specialiști și urmăm recomandările lor, astfel

de programe pot ajuta la sănătatea noastră organizațională prin:• Creșterea coeziunii echipei,• Dezvoltarea unor noi modalități de a lucra eficient în

echipă,• Dezvoltarea abilităților de conducere (leadership),• Dezvoltarea abilităților de rezolvare a problemelor în

echipă,• Facilitarea soluționării conflictelor în echipă,• Îmbunătățirea comunicării în echipă,• Creșterea gradului de încredere în echipă,• Conștientizarea unor probleme sau nevoi (care pot fi adre-

sate în programele de follow-up),• Oferirea unui impuls motivațional.

În concluzie, dacă observăm anumite lipsuri sau lucruri de îmbunătățit în organizația noastră este de preferat să apelăm la serviciile unor profesioniști și să nu facem rabat de la calitatea acestor programe. Dacă ne doare, mergem la medic în loc să ne tratăm singuri, nu?

(1)- Tannenbaum, Beard, Salas: Chapter 5 Team Building and its Influence on Team Effectiveness: an Examination of Conceptual and Empirical Developments

managementCând ne doare, mergem la medic


Vă întrebați cumva care este relevanța acestui subiect pentru domeniul IT? Iată trei aspecte la care merită să vă gândiți:

• Strategia de brand în cyberspace ar trebui să se afle pe agenda oricărei com-panii care vrea să se dezvolte în epoca digitală.

• Cele mai multe afaceri din dome-niul IT își “trăiesc viața” preponderent în lumea digitală – așadar, ar trebui să fie interesate de cum își pot folosi numele de domenii și mărcile pe Internet.

• Schimbările curg rapid la nivel global, iar companiile trebuie să se adap-teze. De exemplu, în prezent, asistăm la o expansiune fără precedent a numelor de domenii – noile gTLD-uri (generic top-level domain names). În curând, domeniile .tech, .software, .technology, .game, .SRL, .online, .web, .site sau .web-site vor fi foarte uzuale, având un mare potențial de conflict asupra companiilor ce activează în IT și în online.

Așa că este prudent să fiți informați privind unele riscuri și mecanisme de protecție.

De ce există conflicte între mărci și nume de domenii?

Conflictele apar, în principiu, din cauza riscului de confuzie în rândul clienților.

Cu toate că numele de domenii sunt, ca și mărcile, înregistrate pe principiul «primul venit, primul servit», ele nu oferă același nivel de protecție precum măr-cile. În practică, de cele mai multe ori, se consideră că drepturile titularului unei mărci pot fi afectate dacă altcineva înre-gistrează un nume de domeniu de internet ce conține o denumire asemănătoare sau identică cu acea marcă.

Există cazuri, nu puține la număr, când – dacă nu sunteți suficient de activi în mediul online – puteți afla că marca

vă este deja folosită în numele de dome-niu al altcuiva. Acest «altcineva» poate fi un cybersquatter (care înregistrează cu rea-credință nume de domenii ce conțin mărci înregistrate sau notorii, cu scopul de a le revinde ulterior la un preț avantajos) sau chiar un comerciant care, cu bună-credință, vinde sau prestează produse sau servicii (concurente sau nu).

Până recent, «bătălia» s-a dat în general pe extensiile .ro și .com. Dar în contextul apariției noilor gTLD-uri la care m-am referit mai sus, disputele dintre mărci și nume de domenii vor crește exponențial cel mai probabil și vor fi din ce în ce mai complexe.

Ce poate fi făcut?Dacă sunteți titularul unei mărci

înregistrare și țineți la unicitatea și exclu-sivitatea acesteia, cu siguranță veți dori să evitați ca o altă persoană să folosească pe internet un domeniu care reflectă acea marcă, mai ales dacă domeniul în cauză vă poate face concurență sau vă împie-dică să vă extindeți activitatea în altă zonă geografică.

Dacă ați monitorizat și ați aflat că există un asemenea domeniu, încercați - în primă etapă - să contactați persoana care l-a înregistrat și să-l preluați amiabil. Este important să punctați în mod persuasiv drepturile pe care vă bazați cererea.

Dacă nu aveți succes în acest prim pas, puteți trece la o etapă formală. De obicei, procedura depinde de tipul extensiei (.ro, .eu, .com, gTLD nou, etc.) – puteți opta

Bătălia din online:

marcă vs domeniu de Internet

management

Claudia [email protected]

Avocat & Consilier în domeniul marcilor @IP Boutique


pentru o procedură de arbitraj sau mediere (de exemplu, prin WIPO Arbitration and Mediation Centre1 ) sau pentru o acțiune în instanță (dar care poate consuma mai multe resurse). Însă, în aceste cazuri, dacă vreți să vă fie apărate drepturile corespunză-tor, recomandarea este să apelați la ajutor juridic de specialitate.

De exemplu, unul dintre clienții mei, o companie românească de IT, deține atât marcă națională, cât și comunitară – reflec-tată în domeniile aferente .ro și .com. Având în plan extinderea activității în Marea Britanie, clientul a dorit să înregistreze și domeniul aferent .co.uk, însă a aflat că este deja înregistrat de un cetățean britanic. Domeniul era inactiv. Clientul meu a apelat la procedura de mediere oferită de Nominet UK (corespondentul britanic al ROTLD) și, în urma argumentelor pe care le-am invo-cat, a obținut rapid și amiabil transferul domeniului, în schimbul unei sume negociate rezonabil.

Dacă ați înregistrat un domeniu ce include o denumire identică sau similară mărcii altei persoane, strategia depinde și de modul concret în care dumneavoastră folosiți respectivul domeniu. De regulă, vă poate avantaja dacă aveți sau nu un interes legitim să-l folosiți - de exemplu, pe acel domeniu web ați dezvoltat cu bună-credință un serviciu sau produs pe care îl oferiți clienților dumneavoastră, etc.- , dacă aveți drepturi ante-rioare asupra acelei denumiri (de exemplu, o marcă proprie sau numele propriei companii), etc.

De aceea, în cazul în care ați primit o notificare din partea titularului unei mărci care vă solicită (amenințător sau nu) tran-sferul domeniului, unul dintre primele lucruri pe care ar trebui să le faceți este să apelați la un expert care să analizeze situația și să evalueze șansele pe care le aveți pentru a putea păstra domeniul.

Rețineți faptul că situația se analizează întotdeauna de la caz la caz, iar analiza nu este mereu simplă. Nu faceți eroarea de a renunța imediat la domeniu, înainte de a primi o opinie speciali-zată; s-ar putea să aveți surpriza ca dreptatea să fie (și) de partea dumneavoastră. În urmă cu câteva luni, un client din zona online mi-a solicitat să verific o denumire pe care dorea să o folosească în noul său domeniu. Înainte să mă contacteze, primise o notifi-care formală din partea unei companii din Germania care deținea o marcă comunitară (așadar, protejată inclusiv în România) și pretindea transferul imediat al domeniului. Clientul s-a speriat și a acceptat transferul, optând pentru un rebranding și costurile aferente, fără să ceară opinia unui expert. De înțeles, în cazul noului nume de domeniu pe care l-a înregistrat, a fost diligent și

1 Organizația Mondială a Proprietății Intelectuale - www.wipo.int/amc/en/domains

a căutat ajutor. Dar, din păcate, a aflat și faptul că avea argumente solide pentru a păstra domeniul inițial la care a renunțat.

Pe scurt, despre noile gTLD-uriÎn privința noilor gTLD-uri, puteți găsi aici2 un infogra-

fic realizat de Internet Corporation for Assigned Names and Numbers (ICANN3) privind modul în care titularii își pot proteja mărcile în mediul online, în urma «revoluției» noilor nume de domenii (de exemplu, prin înregistrarea în Trademark Clearinghouse).

Trademark Clearinghouse este o bază centralizată de date (pusă la dispoziție de ICANN și administrată de Deloitte și IBM) în care titularii pot alege să își includă mărcile în perioada Sunrise și să înregistreze domeniile aferente. Mărcile, după ce sunt vali-date, obțin prioritate la înregistrarea noilor gTLD-uri, iar titularii mărcilor sunt informați când un terț încearcă să înregistreze un nou gTLD care include respectiva marcă, evitând, astfel, situațiile neplăcute în care trebuie să lupte ca să redobândească domeniu în cauză.

Puteți verifica statusul oricărui nou gTLD accesând acest link4 . Iar dacă doriți să aflați mai multe detalii privind domeniul .tech, puteți vizualiza această prezentare5.

În concluzie, cine învinge în conflictul dintre mărci și nume de domenii? Aș îndrăzni să spun că, în general, învinge titularul mai informat care își cunoaște mai bine drepturile și știe cum să le folosească în propriul avantaj.

Estimez că, în viitor, noile nume de domenii vor crea pro-bleme destul de serioase titularilor de mărci. Companiile inclusiv cele din domeniul IT care oferă servicii și produse disponibile în mai multe arii geografice, trebuie să se adapteze la noul peisaj creat de interferența dintre mărci și numele de domenii și să pună mai mare accent pe strategia juridică din mediul online. Dar important de reținut este și faptul că există mai mereu opțiuni pentru a rezolva situațiile conflictuale rezultate din folosirea măr-cilor și a numelor de domenii. Rămâne să o alegeți pe cea mai potrivită situației concrete cu care vă confruntați; iar acest lucru e posibil numai dacă sunteți informați sau sfătuiți corect și la timp.

2 newgtlds.icann.org/en/announcements-and-media/infographics/tm-protection

3 www.icann.org

4 http://www.trademark-clearinghouse.com/gtld-calendar

5 http://www.trademark-clearinghouse.com/sites/default/files/files/downloads/150617_

webinar_tech.pdf

managementBătălia din online: marcă vs domeniu de Internet

Testează-ți abilitățile

În curând

programez.ro

powered by

sponsori

today software magazine n38/2015

Documents