Sunt Catalin Grigoroscuta, si vreau sa va vorbesc despre cateva lucruri foarte interesante la care lucram in Adobe Romania, lucruri despre care poate putina lume stie ca sunt facute la noi, si despre echipa care lucreaza la ele.

Numele echipei in care lucrez acum la Adobe Romania este “WebKit Expressiveness”, iar misiunea noastra este de a impinge mai departe limitele a ceea ce este posibil sa faci folosind tehnologii Web. Adobe a fost inca de la inceput si continua sa fie partenerul designerilor si al oamenilor creativi in general, ajutandu-i sa-si transpuna ideile in spatiul online. Pentru asta, am facut tools-uri destinate oamenilor de creatie (gen Photoshop, Illustrator, Flash Authoring, si restul aplicatiilor care formeaza Creative Suite), insa i-am ajutat si in a-si aduce creatiile in fata utilizatorilor. Astfel, pe vremea cand standardele web permiteau putin peste  simple documente HTML, noi am facut Flash Player-ul – care in esenta nu este decat o platforma ce permite afisarea unui continut mult mai “rich” decat permiteau browserele si standardele din spatele lor.

Intre timp lucrurile au evoluat, a aparut explozia device-urilor mobile (smart phones, tablete), HTML(5) s-a impus ca standard de facto pentru prezentarea continutului cross-devices si a evoluat foarte mult ca standard, insa misiunea noastra a ramas aceeasi: de a ajuta oamenii creativi sa faca continut cat mai bun, pe care sa-l poata distribui unui numar cat mai mare de oameni. Desi standardele web au evoluat foarte mult in ultima vreme (ajunge sa runcati o privire pe www.theexpressiveweb.com ca sa va faceti o idee cam unde s-a ajuns), noi credem ca mai sunt inca multe lucruri de imbunatatit, si vrem sa ajutam activ la asta.

Am inceput acum un an si ceva, cand lucram cu o ehipa din statele unite la un prototip – o incercare de a publica continut profesional pentru reviste in formatul HTML. Desi poti face multe lucruri intr-o pagina HTML, afisarea unei pagini dintr-o revista profesionala (gen Wired Magazine), al carei design este facut cu tool-uri profesionale (gen InDesign, Illustrator), la un nivel inalt de fidelitate, care sa se vada bine pe orice tableta, pur si simplu nu este posibil. Nu voi intra aici in detalii din lumea print-ului, insa doua dintre limitarile majore de care ne-am lovit au fost: cum sa faci un text sa “curga” in mai multe regiuni definite in pagina, astfel incat sa arate bine pe cat mai multe rezolutii, si cum sa “decupezi” textul in jurul unor imagini cu forma arbitrara. Solutii tehnice au fost gasite pe moment, insa presupuneau cunostinte foarte avansate de JavaScript, si o complexitate foarte ridicata. Asa ca ne-am gandit: ce-ar fi sa impingem mai departe standardele HTML/CSS astfel incat lucrurile acestea sa fie simplu de realizat intr-o pagina HTML de catre oricine?

Asa au aparut CSS Regions si CSS Exclusions, primele noastre contributii la standardele web (ma refer aici la Adobe Romania). Acum un an, la MAX 2010, am aratat primul prototip de regions si exclusions. Am luat WebKit-ul (HTML layout engine-ul din spatele cunoscutelor browsere Chrome si Safari, si pe baza caruia sunt implementate si browserele de pe Android si iOS), si am inceput sa-l modificam pentru a adauga suport de regions si exclusions. Am reusit apoi sa instalam acest WebKit modificat pe o tableta Android (lucru nu chiar trivial – dar despre asta in alt post), si l-am prezentat la MAX. Alexandru Chiculita (aka Chicu), Virgil Palanciuc si Andrei Bucur au fost temerarii care au reusit sa faca prototipul de WebKit, iar Razvan Caliman (aka TSK) ne-a aratat ce poate face un web designer cu noile feature-uri ce CSS.

Reactia comunitatii web a fost una foarte buna, asa ca am mers mai departe pe doua directii: una de standardizare, contretizata sub forma unei propuneri de specificatie pentru W3C (organismul care se ocupa de standardele HTML si CSS), si a doua de implementare a specificatiei in WebKit. Si nu ma refer aici la un prototip peste WebKit, ci chiar la contribuitia in proiectul WebKit – proiect open source. La nici un an de cand am inceput sa facem asta, CSS Regions si CSS Exclusions au ajuns specificatii W3C, prima parte din CSS Regions a fost implementata in WebKit  si se gaseste deja in Chrome 15, iar Microsoft a implementat deja acest spec in IE10. Doi dintre colegii mei, Alexandru Chiculita si Mihnea Ovidenie sunt acum committers in WebKit (titlu acordat de ceilalti membri ai proiectului ca recunoastere a contirbutiilor aduse), si lucram impreuna cu Apple si Google la WebKit (de altfel, ingineri de la Apple au ajutat chiar la implementarea de CSS Regions). Mai multe despre CSS Regions puteti gasi pe Adobe Labs; pentru un quick intro puteti citi acest articol, iar aici gasiti un demo inregistrat.

Nu ne-am oprit insa la Regions si Exclusions: o alta directie pe care ne-am hotarat sa o exploram este cea aplicarii de efecte pe elemente HTML. SVG-ul permite deja aplicarea anumitor efecte pe elemente SVG (gen blur, shadow), iar acum se lucreaza activ la aplicarea acestor efecte pe elemente HTML. Lista efectelor posibile este insa una restransa, limitand creativitatea autorilor de continut. Inspirandu-ne din lumea jocurilor, ne-am dat seama ca putem extinde concepul de “filtre” din SVG (si apoi HTML) permitand autorilor sa-si creeze propriile filtre prin vertex shaders si pixel shaders. Prin aplicarea de shaders arbitrare pe orice element HTML, posibilitatile deschise sunt uimitoare. Puteti vedea aici un quick demo cu cateva dintre lucrurile care se pot face, si mai multe in acest articol introductiv.  Echipa din Romania, cu ajutorul unor interni, a implementat un prototip de CSS Shaders in WebKit, care a fost prezentat la MAX 2011. In prezent, lucram la standardizarea lui (cu ajutorul unui coleg din Statele Unite), si la implementarea din WebKit mainline.

Nu voi mai intra in alte detalii despre aceste lucruri, insa as vrea sa vorbesc putin si despre echipa care sta in spatele lor (Chicu, Mihnea, Raul, TSK). Intai de toate, sunt oameni foarte pasionati (de web, de design, de a face lucruri noi si creative), care vor sa schimbe status quo-ul. Apoi, sunt oameni cu foarte multa experienta in programare. Chicu, Mihnea si Raul sunt programatori C++, insa cunosc foarte bine tehnologiile web (JavaScript, HTML, CSS), si programeaza atat pe Windows cat si pe OS X. Si bineinteles, la baza au cunostinte solide din ceea ce numim generic “computer science” (algoritmi, structuri de date, concepte si paradigme de programare). TSK este un web developer, care actioneaza ca o legatura intre lumea C++ si lumea dezvoltatorilor de aplicatii web, si ne ajuta sa ne dam seama cum vor folosi dezvoltatorii web feature-urile pe care le propunem.

Este o echipa mica, insa talentata, creativa si foarte ambitioasa, cu planuri mari. Am dori sa gasim si alti oameni la fel de pasionati si talentati care sa ni se alature in aceasta misiune de a face web-ul mai bun, si chiar avem pozitii deschise in echipa si cautam activ.Asa ca, daca sunteti sau cunoasteti oameni cu experienta in C++, pasionati de web, si care vor sa contribuie la ceea ce facem noi, trimiteti-ne un CV (aici gasiti mai multe detalii despre ce trebuie sa stiti pentru a aplica pe aceasta pozitie).

Admiterea pentru “Summer Internship 2011” s-a încheiat, a fost un real succes, iar în mod extraordinar, “v-am făcut loc” și aţi venit cu 14 mai mult decât ne așteptam inițial.

Ca să ne cunoaștem și să știm cine suntem, iată lista celor admiși:

1              Iulius Curt            DEV

2              Sincu Alina          DEV

3              Adrian Bogdan Marin     DEV

4              Radu Ionut Gabriel          DEV

5              Florian Marcu    DEV

6              Dinu Dan Mihai DEV

7              Dobre Catalin     DEV

8              Pasea Radu         DEV

9              Daniel Petroianu              DEV

10           Laura Sulfineanu              DEV

11           Stefan Spita        QE

12           Alexandra Vieru               DEV

13           Maricel Mihalcea              DEV

14           Paunescu Vlad  DEV

15           Antonescu Andrei           DEV

16           Alin Predoi          QE

17           Alexandra Todiruta         DEV

18           Mihai Ciorobea DEV

19           Dragan Monica  DEV

20           Adrian Chitescu                DEV

21           Onea Andrei      DEV

22           Iordache Bogdan-Cosmin             DEV

23           Andreea Hodea                DEV

24           Tiberiu Popa       DEV

25           Alexandru Dinca               QE

26           Carmen Ruse     UX

27           Patru Elena-Melania       DEV

28           Tudor Scurtu      DEV

29           Adrian Lungu     DEV

30           Tica Mihai            DEV

31           Victor Ungureanu            DEV

32           Tigora Andrei     DEV

Felicitări! Abia aşteptăm să lucrăm împreună pe proiecte.

La final, când am tras linie, am văzut c-au fost:

• 312 studenți;
• 432 aplicări la stagii;
• 65 de teme corectate, fiecare a câte 5 probleme;
• peste 50 de interviuri;
• 32 interni angajați.

Încă o dată, un rezultat super tare pentru toată lumea.

V-așteptăm cu drag, pe cei admiși la sediul nostru, iar pe cei ce se pregătesc în continuare, la Internshipul 2012.

O vară superbă tuturor,

Adobiștii

Cautam un Rambo al Graphic Design-ului + un Agent 007 al UI/Web Development-ului (pt o misiune de o luna sau doua).

Tinta misiunii lor: Partea de frontend – Graphic design+html CSS pt un proiect de genul asta: http://tv.adobe.com/

Ce vor face ei? Vor colabora la nivel strategic cu un User Experience din Romania si cu echipe ”de guerrilla” experte in dezvoltare, distribuite din Statele Unite si India.

Briefing-ul misiunii: Durata proiectului : prima faza 1-2 luni. Misiunea poate continua ulterior, in functie de cum va evolua proiectul.

Cerinte:

Pentru UI/Web Developer, cunostinte f bune de dezvoltare web – front end (HTML, CSS etc). Proiecte prin care sa dovedeasca asta

Pentru Graphic Designer – cunostinte foarte bune de design pt web, design pt aplicatii enterprise. Experienta maxima cu sculele de design. Portofoliu care sa ne dea pe spate.

Pentru ambii: viteza de executie la calitate corespunzatoare, disponibilitate sa lucreze la sediul nostru pentru o luna sau doua,

cunostinte de supravietuire in conditii de termene f agresive si cu schimbari facute pe loc sau din mers.

Membri commando-ului vor primi: echipament de lupta, bani, faima si un loc de cinste in echipa contractorilor nostri

Pentru detalii si inscrieri, contactati centrul de operatiuni la

cfara@adobe.com

0723 688 244

Ce a însemnat «Community Action Week» în Adobe România? Un proiect finalizat și unul în curs, cel finalizat purtând numele plastic de „Păpăm și Donăm”. În spatele „Păpăm și donăm” a stat o echipă de Adobiști cu abilități în ale bucătăriei, care s-au întrecut în prepararea prânzului (și parțial a micului dejun) pentru 112 angajați Adobe, în final meniul având 27 de feluri diferite de mâncare. Prin această activitate, am reusit să strângem peste 5,000 RON pe care i-am donat către Crucea Roșie. Bravo copii !Pe lângă sentimentul că am facut o treabă bună, s-a adăugat și o atmosfera super la prânz în sala de mese, asa cum se poate vedea in poze

Urmează «Toys for Joy» – o inițiativă prin care vom dona jucării copiilor de la Valea Plopului.

Vă ținem la curent,
echipa CSR

Pentru DEV-i:

• Înainte să trimiți rezolvările tale, verifică să îndeplinești următoarele condiții (nerespectarea se depunctează):
  • Codul tău se compilează și trece cu success de exemplele postate de noi. Această condiție este eliminatorie.
  • nume.prenume – Arhiva pe care o trimiți conține un folder cu numele tău, iar în interior foldere pentru fiecare din problemele pe care le-ai rezolvat
  • Codul sursă este însoțit și de un script de build (ant sau makefile sau măcar un .bat sau .sh – click pe nume pentru exemple ).
  • Arhiva include toate bibliotecile pe care le-ai folosit. Asta înseamnă fișiere .h care există doar la tine pe calculator, precum și jar-uri sau pachete specifice limbajului în care ai rezolvat.
• Avem 5 probleme, textul și baremele sunt aici:
  • Problema 1
  • Problema 2
  • Problema 3
  • Problema 4
  • Problema 5
• Timpul de rezolvare și trimitere a temelor este de 36 de ore – până duminică seara la ora 22:00. Trebuie să rezolvi cât mai multe dintre cele 5 probleme – punctajul final este suma punctajului de la fiecare problemă.

Pentru QE-i:

• Avem 2 probleme, textul și baremul îl găsești aici
• Timpul de rezolvare și trimitere a temelor este de 36 de ore – până duminică seara la ora 22:00.

Pentru UX-i:

• Avem o problemă, textul și baremul sunt aici
• Timpul de rezolvare și trimitere a temelor este de o saptămână.

Ce urmează să se întâmple?

• În decursul zilei de sâmbătă și duminică vom răspunde la toate întrebările trimise pe forum, în cel mai scurt timp posibil;
• Duminică vom posta explicațiile rezolvărilor pentru DEV-i;
• Ne trimiți rezolvarea prin e-mail la educatie@adobe.com. Daca atasamentul este mare, foloseste un serviciu de transfer de fisiere – precum transfer.ro pentru upload.
• În două săptămâni vom termina de corectat și vom începe interviurile. Dacă nu ai fost contactat în maxim 3 săptămâni de astăzi înseamnă că nu ai trecut mai departe. Dacă vrei feedback despre rezolvarea ta, dă-ne un e-mail la educatie@adobe.com și iți vom răspunde cât de repede putem.

Urmărește-ne blogul ca să fii la curent!

Ați fost contactat de către proprietarul unui cabinet de stomatologie pentru a crea site-ul de prezentare al cabinetului.

Sarcina voastră este să definiți și să creați respectivul site, din punct de vedere structural, interacțiuni, design. Partea de dezvoltare web a site-ului nu face parte din temă.

Descrieți în câteva fraze pașii pe care îi faceți ca să definiți site-ul și argumentați deciziile luate, pentru fiecare dintre etape.

Ce ne așteptăm să primim de la voi:

• Wireframes care să acopere layout-ul general, principalele funcționalități și primele nivele structurale ale website-ului
• O propunere de design (hi-definition design) pentru pagina “Programări” – în care clienții își pot face o programare online la cabinetul stomatologic
• Cel mult o pagină A4 cu explicații referitoare la deciziile de design luate

Notă: Tot ceea ce ne trimiteți ar fi de preferat să fie într-un singur fișier (eventual PDF).

Alte considerente:

• Elementele de design și conținutul text al site-ului este la alegerea voastra
• Termenul limită este de o saptamana (1) de la data anuntarii pe site-ul myadobe.ro
• Orice intrebari aveti referitoare la test puteti sa le puneti ca si comentarii (ganditi-va ca autorul acestui articol este proprietarul cabinetului)

Ce vrem de la tine? Un test plan și/sau o listă de test-case-uri care să acopere cât mai bine posibilele cazuri de folosire ale aplicației. De asemenea, o listă cu defectele din aplicație e mai mult decât binevenită. Le poți trimite în fișiere diferite sau în același fișier. Important e să fie clar structurate ca să ne dăm și noi seama what’s what. Atenție: contează calitatea și mai puțin cantitatea – nu veți primi extra-credit pentru template-uri completate pe sfert doar ca să iasă PDFul mai gros

Tema 2:

Ce teste ai efectua pentru a te asigura că funcția Search din sistemul de operare Windows funcționează corect. Presupunem din start că ne referim doar la bătrânul “Search Companion”, prezent în toate sistemele Windows.
Scrie o listă cât mai cuprinzătoare de teste, și raportează ceea ce ție ți se pare un defect din punct de vedere al calității acestui feature.
Punctaj suplimentar se va acorda pentru testele automate atașate temei.

Barem – adică ce urmărim:

• Structura si corectitudinea planului de teste
• Granularitatea si calitatea testelor funcționale și nefuncționale;
• Claritatea si calitatea bug reporturilor.
• Claritatea și ușurința de utilizare a testelor automate;

Restricții și precizări:
Numărul întreg pozitiv n este mai mic decat 2⁶³ și va fi citit de la tastatura. Se garanteaza faptul că intrarea va reprezenta un numar valid in baza 10.
O mulțime are prin definiție elemente două câte două distincte. Astfel, nu sunt considerate bune soluțiile în care într-una din mulțimile A sau B se repetă elemente. La fel, mulțimile A si B trebuie sa fie disjuncte.

Exemplul 1:
Date intrare:

23

Date ieșire:

0 1
3

Exemplul 2:
Date intrare:

2011

Date ieșire:

3 5
0 1 2 4 7

Barem:

• 3p – descrierea în README.txt a algoritmului, complexitate, de ce functionează – se acordă maximul doar dacă complexitatea este cea optimă;
• 2p – funcționarea pe exemple precum cele din enunț;
• 5p – Cod funcțional de complexitate optimă;
  • +/- 1p Coding style;
  • -2p Complexitate neoptimă;
  • -4p Complexitate total neoptimă;
• Punctajul este intre 0-10.

Update:

Practic se cere să se scrie un numar n ca sume și diferențe de puteri distincte ale lui 3. Problema este legată de ceea ce se numeste descompunere ternara balansată în care se încearcă scrierea unui număr într-o bază de numerație b folosind numai cifrele -1,0 si 1 in loc de 0,1,2,…,b-1. De exemplu:

49 = 3*4²+1*4⁰=301₍₄₎ dar și
49 = 4³-4²+4⁰ , folosind ca și factori doar elemente din {-1,0,1}.

Nu orice număr și nu în orice bază de numerație se poate obține o astfel de descompunere. De exemplu, pentru n=6,10,14.. nu există o descompunere ternară pentru baza b=4. În cazul particular al bazei 3, orice număr se poate reprezenta în această formă în mod unic. Exemple:

2 = 3¹-3⁰
42 = 3⁴-3³-3²-3¹
2011 = 3⁷-3⁵+3⁴-3³+3²+3¹+3⁰.

Se dă un graf orientat aciclic cu N noduri și M arce.
Fie K numărul de drumuri distincte de la nodul 1 la nodul N. Se cere restul obținut prin împărțirea lui K la 2011.

Programul primește datele de intrare din fișierul “drumuri.in”, ce conține pe prima linie numerele N si M, iar pe urmatoarele M linii câte două numere separate prin spațiu, “x y”, reprezentând câte un arc din graf (de la nodul x la nodul y). În fișierul “drumuri.out” trebuie afișat numărul cerut – restul obținut prin împărțirea numărului de drumuri la 2011.

Restricții și precizări:

• 2<=N<=1.000.000.
• 1<=M<=1.000.000.
• Între două noduri pot exista mai multe arce.

Exemplul 1:

Fișier de intrare: drumuri.in:

4 5
1 2
1 3
3 2
3 2
2 4

Fișier de iesire: drumuri.out:

3

Explicație: sunt 3 drumuri: 1->3->2->4, 1->3->2->4 (exista 2 arce 3->2), 1->2->4.

Exemplul 2:

Fișier de intrare: drumuri.in:

3 2
1 2
3 1

Fișier de ieșire: drumuri.out:

0

Explicație: nu există nici un drum de la nodul 1 la nodul 3 (graful este orientat).

Barem:

• 3p – descrierea în README.txt a algoritmului, complexitate, de ce functionează – se acordă maximul doar dacă complexitatea este cea optimă;
• 2p – funcționarea pe exemple precum cele din enunț;
• 5p – Cod funcțional de complexitate optimă;
  • +/- 1p Coding style;
  • -2p Complexitate neoptimă;
  • -4p Complexitate total neoptimă;
• Punctajul este intre 0-10.

Update:

• Mai intâi sortăm topologic nodurile grafului.
• În continuare construim pas cu pas numarul de drumuri de la nodul 1 până la fiecare nod care se află după el, în urma sortării topologice:
  • Dacă nodul N este inaintea nodului 1, atunci rezultatul este 0.
  • De la nodul 1 până la el insuși există un singur drum (drumul fără niciun arc).
  • De la nodul 1 până la următorul (conform ordinii date de sortare) există un număr de drumuri egal cu numărul de arce dintre cele doua noduri.
  • Pentru un nod oarecare X, având calculate numerele de drumuri de la nodul 1 până la nodurile precedente lui X, fiecare arc de forma (Y, X) care intră în X, adaugă D drumuri, unde D este numărul de drumuri până la Y (fiecare D este cunoscut, pentru că orice nod Y pentru care există arc (Y, X) este înaintea lui X dupa sortarea topologică).
• În momentul în care s-a calculat numărul de drumuri pentru nodul N, se poate afișa valoarea cerută. Întrucât numărul de drumuri până la un nod poate fi foarte mare, numerele intermediare din cadrul soluției sunt considerate modulo 2011.

Complexitate: O(N+M) (atât sortarea topologică, cât și a doua parte au aceeași complexitate).

Restricții și precizări:

• nr noduri < 1000
• -1000< valoarea nod < 1000
• secvența trebuie să fie consecutivă
• nu se poate “sări” de pe un branch al arborelui pe altul pt a completa secvența
• programul trebuie să primească 2 parametri: numele fișierului de intrare si de ieșire
• în fișierul de ieșire se va scrie numărul de secvențe

Exemplul 1

Formatul fișierului de intrare:

• Pe prima linie numărul de noduri din arbore.
• Urmează n linii de forma i-j, unde i este numărul nodului și j valoarea lui.
• Apoi urmează n-1 linii de forma k,l din care rezultă că l este fiul lui k.
• Apoi urmeaza o linie pe care se trece suma de obtinut

13
1 1
2 2
3 5
4 1
5 -1
6 3
7 -2
8 3
9 -2
10 4
11 -4
12 3
13 3
1 2
1 3
2 4
2 5
2 6
3 7
3 8
6 9
7 10
8 11
8 12
9 13
4

Conținutul fișierului de iesire:

6

Explicație:
Pentru suma 4 solutia e reprezentata de urmatoare cai :

1 2 1
1 2 3 -2
1 5 -2
4
3 -2 3
5 3 -4

Barem:

• 3p – descrierea în README.txt a algoritmului, complexitate, de ce functionează – se acordă maximul doar dacă complexitatea este cea optimă;
• 2p – funcționarea pe exemple precum cele din enunț;
• 5p – Cod funcțional de complexitate optimă;
  • +/- 1p Coding style;
  • -2p Complexitate neoptimă;
  • -4p Complexitate total neoptimă;
• Punctajul este intre 0-10.

Update: Se face o parcurgere în adâncime. Asta reduce problema la găsirea unei secvențe de valori într-o lista simplă care au ca sumă valoarea de input.
Subproblema se rezolvă optim în modul următor:

• Pentru fiecare poziție i din listă se ține într-o tabela de hash-uri suma numerelor de la poziția 0 la poziția i;
• Când ajungem la o poziție j se verifică dacă sum(0,j) – valoarea_input există în hashmap;
• În acest caz secvența începe de la i și se termină la j;