De ce WebKit?

Încă de la începuturi, Adobe România a fost focalizată pe zona de Web. Asta a însemnat realizarea de produse ce foloseau atât web-ul ca platformă dar și produse care foloseau tehnologii web în afara contextului clasic de browsing. Unul din aceste produse a fost Adobe AIR – la care echipa din România a contribuit încă de la primele iterații, cu suportul pentru realizarea de aplicații AIR folosind HTML, CSS și JavaScript. Toate astea, folosind motorul de randare HTML WebKit (regăsit în Apple Safari, Google Chrome și majoritatea browserelor de pe plaformele mobile non-Microsoft).
Ulterior, în vremurile mai recente, WebKit a fost folosit de către echipe din România și din US ca bază pentru prototipuri care au ajuns noi specificații CSS (CSS Regions, CSS Exclusions, CSS Shaders). Cu alte cuvinte exista deja o masă critică de oameni cu experiență de WebKit și dorința de-a învăța și pe alții.

Ce presupune un hackathon?

Un hackathon este în principiu un eveniment în cadrul căruia un grup de programatori (dar nu numai, nu neapărat) se adună pentru a lucra la un produs sau la o idee. Ce rezultă în urma unui hackathon variază foarte mult, de la simple noi teste în jurul unei funcționalități, până la repararea de bug-uri sau prototiparea unor funcționalități noi.

Acesta a fost primul hackathon de WebKit organizat 100% de echipa din București (deși unii colegi aveau deja 1-2 hackathoane la activ, împreună cu echipele din US). În final ne-am strâns ~16 oameni, cam în proporții egale ingineri din Adobe România și studenți din Politehnică. Pentru studenții din Poli, Adobe a pus la dispoziție toată infrastructura (laptopuri, acces la Internet, locație) și utilitățile necesare (suc/ceai/cafea, pizza la prânz și bere după demo-urile de vineri), totul sub atenta organizare a lui Mihnea Pe lângă demitizarea procesului de contribuție, unul din scopurile hackathonului a fost și promovarea contribuției la WebKit printre studenții la Poli.

Prima zi a fost mai mult de familiarizare cu codul și procesele din jurul WebKit – Mihnea și Răzvan au ținut prezentări despre arhitectura și comunitatea WebKit, procesul de submitare de patch-uri, how-to-s sau proiectele la care lucrăm acum. Apoi s-au format echipe, în jurul diferitelor idei. În ciuda unor probleme în configurațiile software, la finalul zilei, aproape toți reușiseră măcar să compileze WebKit-ul. „Grosul” dezvoltării s-a făcut în a doua zi și în prima parte a celei de-a treia zile, iar vineri după-masă echipele și-au prezentat realizările. În ciuda unor dificultăți tehnice care au încetinit prezentările vineri, totul a mers bine, la final având un număr mare de demo-uri în stare aproape finală. Lucru cu atât mai îmbucurător cu cât doar câțiva dintre participanți aveau experiență de lucru cu WebKit (pentru mine a fost prima dată când am deschis cod de WebKit în XCode ).

Demo time!

www.youtube.com/watch?v=cvywEynl2gM

În cele ce urmează, veți găsi o scurtă descriere pentru fiecare din proiectele realizate în timpul hackathonului, împreună cu screenshot-uri, video-uri și, acolo unde este cazul, link-uri la codul produs.

Resize event pentru orice element HTML

În HTML singurul obiect care aruncă evenimente de tip resize este window. Uneori însă, în layout-uri complexe sau în situații în care conținutul se poate modifica dinamic, codul pentru a detecta schimbări de dimensiune ale elementelor poate fi destul de complicat. Prototipul realizat de Mihai Maerean, Cătălin Badea și Mihai Bivol adaugă evenimente de tip resize pe orice element DOM din HTML.

www.youtube.com/watch?v=k-1kq3amVa0

Suport pentru CSS Regions în DRT

Dump Render Tree (sau pe scurt DRT) este o componentă din WebKit folosită de frameworkul de testare automată. Folosind DRT, poziția pe ecran și relația elementelor DOM poate fi exportată în format textual sau ca imagini, permițând compararea rezultatelor cu niște valori așteptate, considerate corecte. În cazul CSS regions, pentru elementele care sunt poziționate într-o regiune, această informație nu este expusă de DRT în format text. Asta face imposibilă crearea de teste automate care folosesc compararea textuală a rezultatelor. Patch-ul la care au lucrat Ion Roșca și Cătălin Ușurelu permite folosirea DRT pentru teste de CSS Regions cu rezultat text. De asemenea pentru a putea lucra pe Windows la acest patch, Ion a trebuit să mai rezolve un bug.

www.youtube.com/watch?v=ErVNZwUZoVY

Poziționarea subtitrărilor în <video> (WebVTT)

www.youtube.com/watch?v=tTdleDoXo5o

Una din specificațiile referitoare la video în HTML 5 este WebVTT. WebVTT standardizează modul de tratare și afișare a track-urilor de tip text într-un element <video>, fie că e vorba de subtitrări, closed-captions sau orice alt fel de conținut text adăugat peste un element video. Patch-ul lui Victor Cărbune îmbunătățește suportul pentru WebVTT din WebKit, asigurând vizibilitatea textului indiferent unde este el poziționat.

www.youtube.com/watch?v=ZcQUCuHmjt0

background-clip și border-radius

În ultima versiune de Safari, proprietatea background-clip nu este aplicată corect în cazul în care un element are mai multe imagini de fundal și elementul are specificat și border-radius – aka colțuri rotunjite. Vladimir Grecescu a implementat un fix pentru acest bug dar, după cum spunea și el în prezentare, mai sunt încă niște pași de făcut până ce patch-ul va fi acceptat în trunk-ul WebKit.

www.youtube.com/watch?v=snhNp0ZoNNc

WebInspector bug

Un bug destul de sâcâitor în Web Inspector-ul din WebKit apare la editarea regulilor CSS „read-only” – de exemplu cele provenite din style-sheet-ul implicit al browser-ului sau din setările utilizatorului. În mod normal, dublu-click într-o regulă CSS adaugă o nouă pereche proprietate-valoare, care poate fi editată. În cazul anterior însă, dublu-click adaugă o pereche nouă vidă care nu poate fi editată. Încercarea de-a o edita cu dublu-click duce la adăugarea a încă o astfel de pereche. Nimic grav, dar destul de sâcâitor. Patch-ul realizat de Vlad Voicu rezolvă acest bug și a fost deja submitat și inclus în trunk-ul de WebKit.

www.youtube.com/watch?v=Y32huMwU_C4

CSS counter-set

CSS 2.1 permite un oarecare control asupra contoarelor CSS (folosite de exemplu de listele ordonate) prin proprietățile counter-reset și counter-increment. CSS 3 adaugă o proprietate nouă – counter-set – pentru mai mult control. Cu toate acestea, counter-set nu este încă implementat în WebKit. Patch-ul lui Andrian Cucu adaugă suport pentru această proprietate.

www.youtube.com/watch?v=jm5Q1ap28wY

Web Inspector à la «Inventing on principle»

Prezentarea lui Bret Victor «Inventing on principle» a stârnit multe conversații în jurul instrumentelor de dezvoltare actuale și a celor viitoare. Horia a încercat să prototipeze câteva din ideile din «Inventing on principle» referitoare la editarea vizuală și cu feedback instantaneu de CSS, peste Web Inspector-ul din WebKit. Ce a ieșit, vedeți mai jos

www.youtube.com/watch?v=I9b-6ihcSWE

Mouse events în CSS Regions

Implementarea curentă de CSS Regions are câteva goluri în zona evenimentelor declanșate de utilizator (mouse events, keyboard events). Unul din ele este faptul că în cazul click-urilor pe conținut poziționat într-o regiune, un dezvoltator JavaScript nu poate afla ușor și direct în ce regiune a fost făcut click-ul în cazul în care conținutul „curge” prin mai multe regiuni. Patch-ul lui Alexandru adaugă la evenimentele de mouse declanșate într-o regiune un nou membru, care conține informații despre regiunea în care a fost făcut click-ul.

www.youtube.com/watch?v=RHlf1jd3iSU

Teste pentru CSS Regions

Deși regulile pentru submitarea de cod în WebKit cer ca pentru orice nou feature să fie adăugate și teste, de cele mai multe ori testele incluse inițial nu sunt acoperitoare. Așa se face că există o categorie aparte de bug-uri în WebKit, care vizează adăugarea de teste pentru anumite părți dintr-un feature, care nu sunt încă acoperite în suita de teste automate (numită LayoutTests). Eu am lucrat la un astfel de bug, submitând teste care verifică faptul că specificitatea și poziția regulilor CSS sunt respectate când se folosește region styling. Ocazie cu care am descoperit încă un bug în aceeași zonă.

www.youtube.com/watch?v=W9UJ8Hwu520

Alte demo-uri

Deși nu apar înregistrați „pe bandă”, au mai participat și:

• Andrei Poenaru – care a lucrat la repararea unor teste de audio și video care erau incorecte
• Radu Apostoleanu – care a încercat să adauge un eveniment overflow pe obiectele NamedFlow din CSS Regions.
• Răzvan Căliman – care a studiat posibilele interacțiuni dintre Shadow DOM și CSS Regions și cum ar putea fi folosite cele două pentru a crea un model mai elegant de folosire a regiunilor. Concluziile celor 3 zile de studiu sunt publice, pe GitHub.
• Mihnea Ovidenie și Raul Hudea – care au ajutat cu sfaturi în orice a însemnat dezvoltare WebKit

Și încheierea de maxim efect

www.youtube.com/watch?v=gWdemNILD4k

Ce mai zic și alții

[...] pe mine m-au bucurat in special oamenii care si-au aratat dedicatia, deschiderea spre comunicare si intelegerea catre cei care nu aveau aceeasi experienta in spate.

Am invatat mai multe despre Webkit si cum este el structurat, m-am lovit de structura implementarii lui (.h, .c, .idl) si toate dependintele care duc la creearea webengine-ului. Am invatat rigoarea in dezvoltarea pe termen lung a unui produs, importanta comment-urilor (care nu prea exista), importanta unui cod usor de inteles si a testelor.

Cu toate ca a fost prima oara cand m-am lovit de webkit si un objective-c riguros, nici Mihnea si nici Raul nu m-au facut sa ma simt nasol sau ca nu as stii destul in ciuda numarului mare de intrebari pe care l-au primit de la mine. [...]

In concluzie evenimentul a fost unul reusit in mare parte datorita tuturor care au avut o atitudine deschisa si au fost gata sa sara peste orice problema de 32 de bitzi.
(Radu Apostoleanu)

Am avut ocazia sa intru in detalii cu Shadow DOM si cum interactioneaza cu CSS Regions.

Am descoperit cateva limitari ale implementarii noastre pe care le putem corecta din timp. Asta e foarte bine! Shadow DOM are foarte mare potential si cred ca trebuie urmarit indeaproape in perioada urmatoare.

Ca urmare a hackatonului am publicat un scurt document cu ce am invatat: https://github.com/oslego/shadow-dom-regions/blob/master/Lessons-learned.md.

Documentul a generat ceva interes in cercurile oamenilor din domeniu. Dimitry Glazkov, initiatorul Shadow DOM si Paul Irish, Google Developer Advocate, au salutat initiativa si au dat mai departe documentul catre followerii lor.

Provocarea a venit din partea documentatiei limitate pentru Shadow DOM. Fiind un feature inca in dezvoltare a trebuit sa ma bazez doar pe LayoutTeste din WebKit si pe specificatia W3C pentru a intelege ce este bug si ce este limitare de implementare.
(Răzvan Căliman)

Hackathon-ul a reprezentat pentru mine o experiență deosebită, întrucât am participat atât ca organizator și mentor, fiind intern Adobe, cât și ca participant la început de drum în privința contribuțiilor în WebKit. Am avut multe lucruri noi de învățat și am fost surprins să văd feature-uri foarte de interesante și complexe dezvoltate într-un interval de timp extrem de scurt. Încă o dată, am înțeles că entuziasmul și perseverența sunt suficiente pentru a mișca lucrurile repede și în direcția potrivită.
(Victor Cărbune)

Mulțumim celor care-au participat, celor care au organizat și… să ne vedem la următorul!

Pentru ca vrem sa te intalnim si sa stam de vorba cu tine, participam si anul acesta la Angajatori de Top (28-29 Octombrie 2011) la Sala Palatului din Bucuresti. Anuntam venirea noastra prin cateva stickere colorate afisate in metrou pe linia albastra (Pipera – IMGB).

Daca se intampla sa le vezi :

… fa o poza cu tine/prietenii tai langa ele

… uploadeaza poza pe pagina noastra de Facebook

… primeste cele mai multe like-uri (pana pe 26 Octombrie cand inchidem concursul) si castiga un premiu din partea noastra: un tricou cu Mo si Foca si o licenta Creative Suite CS 5 (la alegere intre Design sau Web).

Te asteptam sa il ridici de la standul Adobe in cadrul evenimentului (daca esti din Bucuresti) sau ti-l trimitem noi prin posta.

Ti-ai pregatit aparatul foto?

Ce se urmareste in interviul telefonic pentru pozitii tehnice?

Ai ghicit! Subiectele sunt in principal de natura tehnica. Daca esti programator, stilul poate diferi usor de la echipa la echipa, dar asteapta-te sa fii intrebat despre:

• notiuni de baza din programare si despre felul cum ai folosit tehnologiile listate in CV in proiectele la care ai lucrat
• cunostinte tehnice relevante pentru jobul  pentru care recrutam (le gasesti in descrierea postului)
• dorinta ta de a te alatura echipei Adobe Romania pe acea pozitie

Daca aplici pentru un job de QA (testare), trebuie sa stii ca urmarim aspecte tehnice, in aceeasi masura ca si pasiunea pentru si mindframe-ul de QA (mai multe detalii aici)

Pare destul de simplu, nu? Asa credeam si noi. Rezultatele spun insa, ca nu e chiar asa. O parte importanta dintre candidati nu trec de acest pas. Ce putem noi sa te incurajam sa faci pentru ca totul sa decurga cat mai bine? Sa te pregatesti pentru interviu: documenteaza-te despre noi, echipa, tehnologii si incearca sa iti improspatezi memoria cu lucrurile de baza de la care ai pornit la drumul tehnic pe care esti astazi.

Daca aplici pentru un job de programator, e bine sa stii ca vom discuta printre altele despre structuri de date, algoritmi sau OOP. Chiar daca nu rescriem quicksort-ul de mana in fiecare zi, ne intereseaza ca oamenii sa inteleaga foarte bine ce e in spatele conceptelor fundamentale. Stim ca de acolo pleaca totul.

Pe scurt, trebuie sa cunosti foarte bine bazele limbajelor si tehnologiilor pe care le-ai folosit de-a lungul timpului, cu atat mai mult daca sunt relevante pentru viitorul job. Cat de mult vom merge cu intrebarile in directia asta depinde mult de profilul pe care il cautam.

Cat despre CV, aici depinde de tine ce pui inauntru. Dar asteapta-te sa fii intrebat de ce scrie acolo, cu atat mai mult daca e vorba de elemente cheie care apar si in anuntul de job la care ai aplicat. La sfarsitul interviului vei avea ocazia sa ne pui tu intrebarile. Asa ca profita de sansa asta pentru a-ti lamuri aspecte legate de proiect, echipa si Adobe in general. Depinde de tine sa obtii cat mai multe informatii de la noi (salariul nu este o optiune).

Stim ca nu este cazul tau, dar o minima pregatire ne poate salva de situatii penibile gen: ”…si Adobe asta, e un program nu?” Nu uita ca gasesti pe http://myadobe.ro sau www.adobe.com informatiile cele mai importante, foloseste-le cu incredere.

Asta e (aproape) tot. Sunt si mici surprize, dar te lasam sa le descoperi singur(a). Dupa ce ne convingi ca ai o fundatie solida in programare si ca stapanesti tehnologiile cu care ai lucrat, va incepe partea cu adevarat interesanta: interviurile la sediu nostru (face to face). Dar despre asta vom povesti poate alta data.

Pana atunci – asteptam sa te sunam!

Ne-am facut echipa pentru “Let’s do it Romania” si ne gandeam poate vrei sa faci si tu parte din ea. Ce oferim?

• cateva ore de distractie
• discutii interesante
• o sansa sa vezi ce fel de oameni lucreaza la Adobe
• …. si la ce lucreaza

Daca te intereseaza te poti inscrie in echipa Adobe & Friends

• Suntem echipa cu numarul 1997
• Click aici pentru inscriere

Sper sa ne vedem acolo.

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

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⁰.