Codetaku

Intr-o curiozitate sa caut tutoriale despre game programming pentru Mac OS am dat peste cartea din dreapta care poate fi descarcata gratuit.

ABOUT THE BOOK

If you’ve ever thought about becoming a video game developer then this book is for you! This intermediate-level programming book contains all the tricks of the trade that you need to know to build a game engine for Mac OS X.

You’ll learn about all of the nuances dealing with the various Mac OS technologies such as the HID Manager, OpenGL, OpenAL, Core Graphics, Rendezvous, Quicktime, and more! You’ll also learn how to write a plug-in for Maya, do stereo 3D rendering, networking, AltiVec optimizations, and even how to copy-protect your games. For developers interested in self-publishing their games, there is an entire chapter dedicated to marketing and sales strategies.

Never before has so much critical Mac game programming information been available in a single book! But don’t take our word for it; here are some quotes from well-known Mac folks:

Credeti sau nu dar cel mai important pas in realizarea unui proiect web sau software nu o reprezinta programarea ci designul.

Trebuie sa ai la inceput o viziune de ansamblu dar si clara in acelasi timp a proiectului inainte sa te apuci sa lucrezi la taskuri.
Spre exemplu: sa zicem ca sunt un producator de automobile si vreau sa fac o aplicatie prin care pun la dispozitie un inventar cu masinile pe care le am disponibile iar dealerii le pot comanda sau rezerva.

Urmatorul pas ar fi detalierea planului si descrierea fiecarui task.
Cum ar fi:

• Conturile dealerilor vor fi create de catre o persoana care se ocupa cu delegarea conturilor;
• Dealerii trebuie sa completeze niste formulare pentru a avea acces la aplicatie;
• Dealerii pot vedea in ce culori si motorizari sunt disponibile masinile;
• In aplicatie voi avea un newsletter despre productia de automobile din fabrica mea in care voi tine la curent pe dealerii mei; etc

Urmeaza o detaliere si mai in amanunt a fiecarui task in parte.

• Culorile sunt globale pentru toata firma
• Modelele de masini au culorile alese din lista predefinita.
• Culorile sunt stabilite de catre un reprezentant al firmei si nu de catre administrator

In final se leaga toate modulele pentru a descrie un task complet. Pentru vizualizarea acestora se pot folosi diagrame de activitate sau de secventa.

Toti acesti pasi de mai sus se pot face pe hartie, se fac drafturi si se discuta cu viitorul client pe toata aceasta durata.

Acum urmeaza partea interesanta. Aici intervine inginerul software si anume detaliile despre structura programului. Dar tot nu se va ajunge la programare inca.

Aici se stabilesc structura datelor (adica clasele programului) si algoritmii.
Pentru acestea se folosesc diagramele UML pentru o reprezentare vizuala a claselor si flowcharturi pentru vizualizarea algoritmilor. Din pacate nu voi putea intra in detalii aici dar o sa va dau un mic ajutor.

Un tip de diagrama UML este reprezentarea vizuala a algoritmilor pe care toti profesorii v-au aratat-o in liceu si la facultate si probabil v-a si pus sa o desenati pentru un nou algoritm.
In general o diagrama UML este un graf in care nodurile sunt blocuri cu o descriere amanuntita a unui task, obiect sau actiune.

Printre acestea se numara:

Diagramele de clasa

Fiecare bloc este compus din 3 parti despartite de linii orizontale: numele, membrii si metodele; Sagetile indica faptul ca Student si Profesor se deriva din clasa Person; + inseamna ca membrul acela este public; un - ar fi insemnat ca membrul sau metoda respectiva este privata

Diagramele de secventa

Acestea detaliaza o activitate a utilizatorului privind din toate cele 3 planuri: presentation (interfata cu utilizatorul), business logic (programul ce ofera informatii catre planul de prezentare) si backbone (totalitatea bazelor de date).

Diagramele de relationare

Se folosesc pentru designul bazelor de date relationare.

Mai sunt multe altele dar acestea ar fi de ajuns pentru inceput.

Avand acestea gata facute se poate trece la delegarea taskurilor catre programatori si inceperea programarii bazelor de date, a interfetei si a logicii.

Anul acesta particip la Stud IT 08 care are loc la Timisoara.

Concursul are loc in perioada 3-5 mai (sambata-luni la sfarsitul vacantei de paste) si cazarea si masa este gratuita.

Puteti participa cu la una din urmatoarele categorii:

• Cercetare
• Web design - aici particip eu
• Soft utilitar + aplicatii
• Soft educational
• Retele si Securitate

Inscrierile se fac prin email la pdraghia@gmail.com

Eu voi veni cu Alex iar daca este cineva interesat, poate ne vedem acolo.

De multe ori ne-am intrebat la facultate sau liceu de ce invatam niste lucruri (uneori teoretice) pe care nu prea le vom folosi. De multe ori acele lucruri sunt introduceri catre niveluri inalte de cunoastere a unui limbaj, calculator sau a unei materii.

De abia prin anul 2 de facultate am inceput sa invatam cateva lucruri de nivel scazut legat de calculatoare: assembly, achizitii de date, aritectura calculatoarelor, retele de calculatoare. Sa stii cum lucreaza o functie, o comanda sau un protocol te ajuta foarte mult sa eviti bottleneck-uri, sa-ti optimizezi codul sau sa folosesti comenzile cele mai optime pentru operatiile potrivite.

Spre exemplu daca vreti sa inmultiti un numar cu o putere de a lui 2 e mai usor si mai optim sa lucrezi cu operatori pe biti: >> <<:

X << 5 este acelasi lucru cu X=X*2^5. Invers, X >> 5 rezulta in X = X/2^5. Asta fiindca in binar deplasarea la stanga cu o cifra a unui numar inseamna inmultirea acelui numar cu 2 (identic si in sistemul zecimal, unde deplasarea la stanga inseamna inmultire cu 10).

In domeniul retelelor de calculatoare afli cum functioneaza metodele de detectare si corectie a erorilor ceea ce te vor ajuta mai tarziu daca doresti sa dezvolti un algoritm de criptare.

Trebuie si sa stii cum sa folosesti optim resursele calculatorului, cum functioneaza garbage collectorul limbajului pe care-l folosesti, daca chiar trebuie sa folosesti int in loc de char sau chiar byte, ce sunt indexii in domeniul bazelor de date, cum functioneaza si cum sa-i folosesti.

Trebuie sa-ti cunosti mediul ca sa-l folosesti optim si ca sa supravietuiesti.

Nu intotdeauna socoteala din targ se potriveste cu cea de acasa. La fel si cu optimizarile: nu intotdeauna ceea ce ai calculat se simte si in viata reala.

Spre exemplu in linux poate parea ca fisierele sunt copiate dintr-o parte in alta cu viteza mare si desi este adevarat, viteza comparativa cu Windows poate nu fi asa mare. In linux nu avem progress bar pe cand in windows da. Cam asa este si cu Windows XP vs Windows Vista. Windows Vista care are un algoritm improvizat de copiere fata de XP de fapt copiaza mai rapid fisierele dintr-o parte in alta din 2 motive:
1. Au facut estimarea idioata a timpului de copiere (care dureaza 12 secunde) inainte sa se inceapa copierea
2. Progress bar-ul in Vista ramane permanent pe ecran pana cand se scrie ultimul bit pe cand nu asa se intampla si la XP unde progress barul dispare dupa cache-uirea (copierea in memorie, nu si pe hdd) ultimului bit.

Alt test interesant este acest studiu in care se ruleaza progress baruri care sunt afisate de catre functii diferite dar toate dureaza au aceeasi durata de executie. Persoanele care au participat in acest test nu au stiut ca toate ruleaza la fel de mult si li s-au parut ca unul e mai rapid ca altul.

Mai multe puteti citi si de la Jeff Atwood.

Despre optimizarea performantei cu utilizatorii in gand este interesant acest articol. De aici exemplul cu lifturile mi-a placut foarte mult:

A classic example occurred in the 1930s in New York City, where “users” in a large new high-rise office building consistently complained about the wait times at the elevators. Engineers consulted concluded that there was no way to either speed up the elevators or to increase the number or capacity of the elevators. A designer was then called in, and he was able to solve the problem.

What the designer understood was that the real problem was not that wait time was too long, but that the wait time was perceived as too long. The designer solved the perception problem by placing floor-to-ceiling mirrors all around the elevator lobbies. People now engaged in looking at themselves and in surreptitiously looking at others, through the bounce off multiple mirrors. Their minds were fully occupied and time flew by.

Nu am observat asta decat de curand cand am deschis ochii la cum arata produsele software de pe windows. Ce au in comun majoritatea aplicatiilor de pe Mac OS X (daca stiti) ? O interfata identica. Ce au in comun majoritatea aplicatiilor in Windows? Doar borderul ferestrei.

Si am urat asta la Mac. Am urat si am zis ca sunt foarte lipsiti de inspiratie.

Pana astazi. Am vazut cum vroiau sa integreze Mozilla sa integreze in Firefox 3 pentru Vista un look & feel nativ (imagine) si atunci m-a traznit. Poate chiar e mai bine asa. De altfel majoritatea aplicatiilor din Windows singurul lucru pe care il au in comun este borderul albastru, meniul care incepe cu File si se termina cu Help si Status bar-ul.

La aproape 4 luni dupa ce au anuntat Mozilla ca vroiau sa schimbe interfata la Firefox in Vista au scos un beta in care interfata arata total diferit de ce se dorea. Si m-am gandit de ce dracu? E chiar asa de greu? Dar de altfel, de ce nu prea exista aplicatii pentru windows xp cu bara aceea din stanga din Control Panel sau Explorer? Pentru ca nu e nativa! E implementata doar pentru Windows Explorer.

Dar tot nu mi-am dat seama de asta decat dupa ce am instalat Visual C# 2008 Express si am incercat sa folosesc controale de Windows Vista in aplicatie. Da, mai bine nu. Dupa cautari pe forum msdn si google cel mai aproape am ajuns de acest set de controale care au trebuit implementate separat de .net fx 3-ul din Vista. Dar tot lipsește ce vroiam eu mai mult și anume partile de sus (adress bar, search bar, menu bar) si de jos (status bar) din explorerul din vista. Ar mai fi RadControls care ofera o implementare din ce lipseste din documentatia si API-ul pentru Windows SDK dar e pe multi ($799) bani.

Te gandesti ca dupa ce au facut atata reclama la noua interfata din Vista, Microsoft ti-ar da si instrumentele cu care sa faci ceva asemanator ca majoritatea aplicatiilor sa aiba o interfata consistenta in Windows (in afara de cele ale lor), dar de ce sa-i copie altii?

De-a lungul anilor tehnicile de programare si algoritmii s-au imbunatatit considerabil de mult. Dar tu, ai invatat ceva de-a lungul anilor? Cat de mult ti-ai imbunatatit “tehnicile”?

Eu am invatat .php intr-un timp relativ scurt: o zi. Doar atat mi-a trebuit ca sa-mi dau seama singur mai apoi cum se fac treburi putin mai complexe. Si asta e valabil in multe limbaje de programare daca ai invatat alt limbaj de programare in trecut. In momentul cand invatam php facusem pascal de 4 ani si stiam programare structurala destul de bine inclusiv cum sa-mi imbunatatesc codul optimizandu-l. Invatasem si foarte putin C incat sa stiu despre tipurile de date si sintaxele functiilor cele mai des intalnite. Astfel a fost foarte usor de invatat il php.

De aici cel mai bun prieten mi-a fost documentatia php, care daca nu sunteti familiara cu ea atunci nu stiu cum puteti trai. In orice limbaj de programare cel mai bun prieten iti este documentatia, API-ul, help-ul sau cum se mai numeste si apoi Google. Dar uneori poate ce cauti fie se poate face altfel, mai usor de implementat, fie intr-o maniera putin mai complexa dar mai customizabila si usor de intretinut pe termen lung.

Din aceasta nevoie am inceput sa ma uit pe codurile (programele, scripturile) altora si am observat implementari inteligente sau am descoperit functii noi peste care nu dadeam in documentatie fiindca nu m-am gandit niciodata sa caut asa ceva. Printre codurile interesante s-au numarat cele la concursul InfoEducatie si proiecte open-source precum: phpBB, SPAW si Wordpress. Si nu numai din php ci si din Javascript sau CSS. Si aici nu vorbesc despre algoritmi sau portiuni intregi de cod ci de cum foloseau limbajul aferent pentru a realiza un lucru. (de ex: cautari folosind regexp, butoane de lungimi variabile in css, validari de campuri in js, etc)

Au fost momente cand cautam ceva nou sa invat sa ma perfectionez si implicit sa-mi micsoreze timpul destinat implementarii folosind diverse unelte. Primul lucru peste care m-am uitat cred ca a fost Smarty si a fost foarte fain. Cat am lucrat cu el. La un moment dat ajunsesem sa scriu mai mult cod in template-urile smarty sau in implementarea template-urilor decat in codul aplicatiei/sitului propriu-zis. Si apoi m-a traznit ca pot face un template engine cu implementare mult mai simpla si renuntand la sintaxa diferita smarty in favoarea codului php folosind functii deja existente in php. La fel cum functioneaza template-urile wordpress :).

PEAR a urmat si am inceput sa ma gandesc cum as putea sa integrez PEAR in orice site/aplicatie pe care o voi crea. Dupa cateva “lucrari” mi-am dat seama ca nu prea se merita in majoritatea aplicatiilor dezvoltate pe php ci doar in cele mai complexe si foarte modulare. Ce-i drept a fost perioada cand scriam foarte ordonat si totul avea o logica de nu-ti venea sa crezi. Dar cum limbajul nu incurajeaza OOP prin integrarea PEAR-ului, clasificarea functiilor si implementarea unei structuri logice atunci… de ce ai face-o tu, cand deja exista rails?

Si ajungem la faimosul Ruby on Rails (RoR), raiul oricarui programator web si probabil designer web cu a sa filosofie Model-View-Controller (MVC) care e minunata! Cand am auzit despre RoR am descoperit nirvana si cand am citit despre ce poate ruby si mai ales cum am avut orgasm intelectual. Ce a urmat dupa, poate in alt post.
Dar de la RoR am invatat multe inclusiv cat de simplu poate sa fie un template engine si cat de puternic, dar si cat de important e C-ul din MVC. Combinat cu ce am invatat din C# si Java despre limbaje event-based am reusit sa inteleg cum sa creez un site engine modular si usor de imbunatatit pe termen lung.

Ben Collins-Sussman amintea ca sunt 2 tipuri de programatori:

There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%.

The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.

Cu alte cuvinte primul tip de programatori sunt cei care cauta sa se “auto-cultive”, sunt la curent cu cele mai noi trenduri in programare si testeaza tot feluri de tehnologii noi. Celalalt este tipicul student roman iesit de la politehnica si se angajeaza ca programator java, isi ia leafa (grasa chiar), il mai trimite firma pe la un training si este fericit.

Eu nu as vrea sa ajung ca tipul numarul 2. Voi?

Facultatea este facuta ca sa te pregateasca de lumea reala, de conditiile de munca din industrie, dar de cele mai multe ori isi rateaza obiectivele.

Dar ceea ce nu prea te pregateste facultatea sunt:

1. Munca in echipa

Majoritatea facultatilor desemneaza proiecte in echipe in anul 2 deobicei dar nu in timpul facultatii ci acasa. Adica ti se da o tema si iti alegi colegii cu care vrei sa lucrezi si faceti asta in privat. Nu te verifica nimeni, nu stie nimeni sigur cat a facut fiecare si de ce. De aceea sunt cativa care prefera sa faca grosul pentru toata echipa si astfel nu se castiga experienta din munca in echipa.

Nu se invata sa se citeasca si sa se utilizeze codul altora si nu se invata coordonarea. In ciuda acestui fapt multi trec pe cv ca sunt buni coechipieri.

Solutie propusa: Sa se formeze echipe de cate 2 studenti ca sa fie cat mai multe echipe. Se va face schema de lucru pentru un soft si apoi se vor delega sarcinile. Aceeasi sarcina sa fie facuta de cate 2 sau 3 echipe, separat; fiecare echipa va crea sarcina independent ce celelalte echipe. Dupa ce acestea au fost facute sa se trimita ce a lucrat fiecare echipa la alta echipa care va implementa ce a lucrat cu ce a primit de la cealalta echipa. Lucrul acesta sa se faca aleator, si daca se poate, echipele sa nu comunice intre ele, avand la dispozitie doar documentatia pentru subprogramul/clasa/libraria primita.

2. UI

Interfata grafica este ceea ce atrage utilizatorul si ceea ce face programul mai usor sau mai greu de utilizat. Ar trebui sa se predea in facultati despre importanta interfetelor grafice si niste concepte importante despre intefete. Desigur, un programator nu ar trebui sa se omoare sa gaseasca el interfata grafica propriu-zisa ci inginerul software, iar cu asta se lauda facultatile ca “produc”: ingineri software.

Solutie propusa: O materie noua introdusa despre interfete grafice si utilizabilitate. Ca test se va da o cerinta in care sa se gandeasca o interfata grafica cat mai intuitiva/usor de utilizat pentru un anumit soft.

3. Source control

Tot ca parte importanta cand lucrezi in echipa o are si source control-ul. Este aplicatia care tine evidenta codului scris, modificat cand, la ce ora si de catre cine. Este foarte important acest lucru fiindca ajuta la depistarea bugurilor si poti aduce un fisier la versiune anterioara chiar daca ai uitat ce modificari ai facut.

Solutie propusa: Ar trebui sa se creeze un curs despre inginerie software in care sa se predea despre aceste concepte si sa invete sa utilizeze programe de source control precum svn.

Nota: Nici eu nu am folosit vreodata source control si presupun ca nu voi invata acest lucru la facultate.

4. Deployment

Invatam sa programam si sa compilam dar cum publicam ce am lucrat? Da, poti sa arhivezi si sa urci pe un site si sa pui la downloadat dar cat de atractiva este optiunea asta?

Ar trebui sa se predea despre crearea unui installer pentru aplicatie, despre salvarea si reutilizarea setarilor, despre user space si program space, despre versiuni si updatare automata. Daca folositi Visual Studio atunci lucrurile acestea sunt foarte usor de utilizat si creat. In Delphi nu stiu cum sta treaba. Dar pentru java? Multi colegi ma intrebau cum se creeaza un executabil (sau de ce nu are executabil) sau daca merge aplicatia creata in java pe orice calculator.

Solutia propusa: In cadrul aceluiasi curs propus mai sus sa se predea si despre cum se creeaza un installer, cum se foloseste registry-ul, unde ar trebui salvate datele folosite de program (setari de ex.) si unde ar trebui salvate datele prelucrate de utilizator, cum se face un updater automatic, etc.

Acestea sunt unele din problemele despre care nu inveti in facultati dar care te vei lovi mai mult ca sigur cand vei lucra pentru o firma adevarata de software.

Inspirat din articolul How Should We Teach Computer Science? al lui Jeff Atwood, Coding Horror.

Programmers joke si este adevarat.

31₈ = 25₁₀

Cu alte cuvinte 25 (din baza 10, decimala) se traduce in 31 in baza 8 (octala).

De asta unii programatori confunda Halloween-ul cu Craciunul.