Review networking sections

chapters/app-dev/extra.rst

@@ -1,44 +1,74 @@
-Exerciții suplimentare
+Exercițîi suplimentare
 ======================
 
 Pregătirea mediului de lucru
 ----------------------------
 
-Aici vor clona un repository de la noi care conține cel puțin un fișier cod sursă și unul header.
-Aceste fișiere vor fi folosite pentru crearea unei biblioteci. Proiectul deja conține un Makefile minimal.
+În această secțiune vom exersa cunoștiințele acumulate despre GitHub în timp ce vom învăța despre utilizarea bibliotecilor statice și dinamice.
 
-Crearea și folosirea unei biblioteci statice
+Pentru asta, clonati repository-ul de la adresa https://github.com/(TO DO) ce conține:
+* un fișier sursă *.c* cu funcția main
+* un fișier header *.h* ce implementează o funcție ușoară și un fișier *.c* asociat acestui header
+* un Makefile minimal.
+De acestea ne vom ajuta să înțelegem practic cele două tipuri de biblioteci existente.
+
+Ce sunt bibliotecile
+---------------------------------------------
+Aceeași utilitate pe care o au și funcțiile din limbajul C, aceea de a permite scrierea unui cod modularizat și reutilizabil, în același sens funcționează și bibliotecile, permit reutilizarea codului sursă.
+Pe scurt, bibliotecile reprezintă un pachet de funcțîi precompilate care te ajută în dezvoltarea mai rapidă a programelor, pentru că tu să nu rescrii acele funcțîi de la zero. Printre cele mai cunoscute biblioteci de C reamintim: stdio.h, strîng.h, stdlib.h, math.h.
+Însă, este de avut în vedere faptul că bibliotecile nu sunt executabile, ci doar fișiere de tip header ce includ în procesul de linkeditare fișierul obiect asociat lor, permițându-ți să foloseșți conținutul acestora.
+
+În limbajul C, regăsim două tipuri de biblioteci: *statice* și *dinamice*.
+* Diferența majoră dintre ele este faptul că cele statice sunt incluse în fișierul executabil final în compile-time, combinând munca ta cu librăria, în timp ce bibliotecile dinamice sunt combinate la run-time, astfel că nu au nevoie de recompilare sau relink-uire.
+* O altă diferență rezultată din prima este faptul că bibliotecile statice sunt mai rapide, deoarece codul binar este inclus direct în cod, dar rezultă și dezavantajul faptului că executabilul final va avea o dimensiune mult mai mare. În schimb, în cazul bibliotecilor dinamice, ele 'trăiesc' independent de program și doar oferă funcțiile care sunt apelate, rezultând un executabil de dimensiuni mai mici,
+cu costul timpului care va fi mai mare, datorită faptului că acea funcție trebuie căutată în acesta librărie de fiecare dată.
+* În final, avantajul folosirii unei biblioteci dinamice este faptul că poate fi folosită de mai multe procese în același timp, în timp ce o bibliotecă statică este legată de un singur proces.
+
+
+Crearea unei biblioteci statice și utilizarea ei
 ---------------------------------------------
 
-Legarea la biblioteca statică creată
-------------------------------------
+Crearea unei biblioteci statice este mai simplă decât a unei biblioteci dinamice.
 
-Legarea se mai numește și linking.
-Aici după ce o vor crea și după ce vor crea fișierul executabul vor observa 
-dimesiunea executabilului.
+În trecut, pentru librării precum math, adăugam comenzii de compilare opțiunea: -lm (l - opțiunea de linkuire, m - numele bibliotecii noastre).
+În același fel o să procedăm și acum.
 
-Adăugarea unei reguli noi în Makefile pentru crearea bibliotecii statice
+Pași:
+- Creăm un fișier obiect din fișierul ce implementează funcțiile noastre: gcc -c functions.c
+- Arhivam fișierul obiect utilizând comanda: 'ar rcs liball.a functions.o'
+# ar - achieve # rcs (c - create / update, r - insert files (replace existing), s - sorted index - pentru acces mai rapid la funcțiile din librăria nou creată).
+
+Utilizare: gcc -o exec main.c -L -lall (L - opțiune ce indică căutarea în fișierul curent, l - opțiunea de linkurile, all - numele pe care l-am dat noi arhivei: *lib* + **all**).
+
+Bibliotecile statice se numesc *archive libraries*, de acolo extensia '.a' a fișierului liball.
+
+Exercițiu
 ------------------------------------------------------------------------
+Adăugați opțiunea de link-uire și în Makefile.
 
 Crearea unei biblioteci dinamice
 --------------------------------
 
-Legarea la biblioteca dinamică creată
--------------------------------------
+Pași:
+* Creăm fișierul obiect: gcc -o functions.c 
+* Adăugăm fișierului obiect opțiunea 'shared': gcc functions.o -shared -o liball.so.
+* În final, fiindcă bibliotecile dinamice pot fi utilizate de mai multe procese în același timp, trebuie să îi facem cunoscută locația către variabilă de mediu (Environmental Variables) LD_LIBRARY_PATH. Rulăm comandă: export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH.
 
-Vor observa din nou dimensiunea (mai mică de data asta) a fișierului executabil.
+Utilizare: gcc -o exec main.c liball.so
 
-Adăugarea unei reguli noi în Makefile pentru crearea bibliotecii dinamice
--------------------------------------------------------------------------
+Bibliotecile dinamice se mai numesc și shared objects, de acolo extensia '.so' a fișierului liball.
 
-LD_PRELOAD și beneficiile sale
-------------------------------
+Exercițiu
+------------------------------------------------------------------------
+Adăugați o regulă nouă în Makefile pentru crearea bibliotecii dinamice
 
-Aici vor scrie singuri o bibliotecă care să conțină o funcție sqrt similară cu cea 
-din biblioteca math, o vor compila și vor folosi LD_PRELOAD pentru a vedea cum pot să 
-folosească propria funcție sqrt, chiar dacă executabilul este legat și la biblioteca math.
+Self-Study
+------------------------------------------------------------------------
+1. Scrieți propria bibliotecă în care să implementați o funcție similară funcției sqrt din math.h.
+Că orice inginer, uneori trebuie să ne rezolvăm singuri problemele.
+Documentați-va despre LD_PRELOAD și vedeți cum puteți să faceți astfel încât să folosiți *propria* funcție sqrt, chiar dacă executabilul vostru este legat și la biblioteca math.
+Testați asta afișând și un scurt mesaj pentru a arată că sqrt-ul vostru a fost chemat, nu cel al bibliotecii math.
 
-Gist pe GitHub
---------------
+Hint: Dacă setați LD_PRELOAD către locația unei fișier de tip shared-objects(librărie dinamică, cu extensia .so), acel fișier va fi prioritizat în defavoarea oricăror altele. Comandă: LD_PRELOAD=/path/to/my/library.so
 
-Vor învăța cum să creeze un gist pe GitHub-ul lor.
+2. Pentru o aprofundare mai vastă a GitHub și a posibilităților oferite de acesta, documentați-va despre Github Gist.

chapters/app-dev/git-first-commits.rst

@@ -19,6 +19,10 @@ Având commiturile în repository putem să gestionăm mai ușor proiectul, adic
 * să vedem cine este autorul anumitor modificări
 * să creăm o ramură de dezvoltare separată pornind de la un commit anterior, pe care să încercăm o funcționalitate nouă, fără a afecta restul proiectului
 
+Putem să ne gândim la un commit ca la un checkpoint. Când lucrăm pe repository-ul local, orice modificări aducem sunt doar la noi pe calculator.
+Asta înseamnă că un coleg cu care lucrezi la proiect nu va vedea ce ai lucrat tu. Astfel că, atunci când lucrăm la un proiect, periodic sau când terminăm un anumit task / o funcție importantă ce vrem să fim singuri că s-a salvat, vom face un commit.
+Mai exact, salvăm tot ce am lucrat într-un checkpoint cu nume sugestiv (un mesaj de commit) la care vom putea reveni mai târziu în cazul în care stricăm ceva în program.
+
 Git se ocupă de păstrarea și gestiunea istoricului repository-ului nostru prin păstrarea listei de commituri făcute.
 Adică Git păstrează un istoric de versiuni al proiectului.
 

chapters/app-dev/git-intro.rst

@@ -3,21 +3,24 @@
 Introducere în Git și GitHub
 ============================
 
-Vor fi cazuri când vom *strica* o versiune a codului și vom avea nevoie să revenim la o versiune corectă, caz în care un istoric de versiuni ne-ar fi de folos.
-Vom putea să lucrăm la un proiect de pe un alt sistem, în afară de al nostru, sau vom vrea să cerem feedback pe codul scris de noi.
+`GitHub <http://www.github.com/>`_ este o platformă online, pe care dezvoltatorii o pot folosi pentru a stoca și versiona codul lor sursă.
+**Git** este un sistem de management și versionare a codului sursă care permite lucrul eficient la un proiect software.
+
+Astfel, Git este utilitarul folosit în terminal, iar GitHub este serverul și aplicația web pe care rulează acesta, locul în care păstrăm repository-ul remote.
+
+Folosim Github pentru:
+
+* Vor fi cazuri când vom *strica* o versiune a codului și vom avea nevoie să revenim la o versiune corectă, caz în care un istoric de versiuni ne-ar fi de folos. În caz contrar, va trebui să salvăm diferite versiuni a proiectului nostru că niște checkpoints pe PC-ul nostru, ocupând mult spațiu de depozitare.
+
+* Vom putea să lucrăm la un proiect de pe un alt sistem, în afară de al nostru, sau vom vrea să cerem feedback pe codul scris de noi.
 
-Când vorbim despre un proiect software vrem să avem dezvoltatori, oameni care să lucreze împreună cu noi la proiect.
-Dezvoltatorii au nevoie de acces la codul sursă al proiectului software la care lucrăm.
-După ce le dăm acces, vrem ca fiecare dezvoltator să știe la ce a lucrat și la ce lucrează ceilalți; ca să nu se suprapună, ca să ajute și ca să ofere feedback.
+* Când vorbim despre un proiect software vrem să avem dezvoltatori, oameni care să lucreze împreună cu noi la proiect.
+Dezvoltatorii au nevoie de acces la codul sursă al proiectului software la care lucrăm. După ce le dăm acces, vrem ca fiecare dezvoltator să știe la ce a lucrat și la ce lucrează ceilalți; ca să nu se suprapună, ca să ajute și ca să ofere feedback.
 
-Pentru a putea rezolva problemele de sincronizare între doi sau mai mulți colegi de echipă care lucrează la același proiect, ne ajută să avem un **sistem de versionare a codului**, adică să avem un istoric de modificări.
+* Pentru a putea rezolva problemele de sincronizare între doi sau mai mulți colegi de echipă care lucrează la același proiect, ne ajută să avem un **sistem de versionare a codului**, adică să avem un istoric de modificări.
 Fiecare modificare înseamnă o nouă versiune a proiectului; avem astfel o listă de versiuni gestionată de sistemul de versionare a codului.
 Pe lângă rezolvarea problemelor de sincronizare, versionarea codului aduce și alte avantaje cum ar fi revenirea la o versiune mai veche a proiectului, găsirea rapidă a autorului unei secvențe de cod sau, pur și simplu, organizarea unui proiect.
 
-**Git** este un sistem de management și versionare a codului sursă care permite lucrul eficient la un proiect software.
-
-`GitHub <http://www.github.com/>`_ este o platformă online, bazată pe Git, pe care dezvoltatorii o pot folosi pentru a stoca și versiona codul lor sursă.
-Git este utilitarul folosit, iar GitHub este serverul și aplicația web pe care rulează acesta, locul în care păstrăm repository-ul remote.
 
 .. note:: 
 
@@ -75,11 +78,16 @@ De exemplu, pentru autorul acestei secțiuni, comenzile rulate sunt:
 
 .. _app_dev_create_first_repo:
 
+Această configurare trebuie făcută o singură dată pe PC / Virtual Machine.
+Pentru a verifica că setările s-au salvat, verificăm rulând acest lucru rulând ``gît config --list``.
+
 Crearea primului repository
 ---------------------------
 
 Pentru a lucra la un proiect software, creăm un **repository software**.
-Vom crea unul pe GitHub, unul local, după care le vom interconecta.
+Un repository reprezintă o metodă de împărțire a proiectelor: poate fi o temă la o materie, poate conține chiar toate temele la o materie, în directoare diferite sau poate conține doar un simplu README.md;
+
+Vom crea unul pe GitHub (numit de acum remote), unul local (la noi pe PC), după care le vom interconecta.
 
 .. admonition:: **Repository software**
 
@@ -107,18 +115,18 @@ Urmărim pașii prezentați în imaginea de mai jos și explicați imediat după
 .. figure:: ./gifs/GitHub-create-repo.gif
   :alt: Crearea unui repository nou pe GitHub
 
-#. Apăsăm pe săgeată din meniul din dreapta sus și vedem ceva similar cu imaginea de mai sus.
+#. Apăsăm pe săgeata din meniul din dreapta sus și vedem ceva similar cu imaginea de mai sus.
 
 #. Apăsăm pe ``Your profile`` pentru a merge pe profilul nostru.
    Aici este locul în care vom putea vedea contribuțiile noastre pe GitHub.
-   În partea de sus a ecranului vom vedea un meniu orizonatal care conține 4 opțiuni: ``Overview``, ``Repositories``, ``Projects`` și ``Packages``.
+   În partea de sus a ecranului vom vedea un meniu orizontal care conține 4 opțiuni: ``Overview``, ``Repositories``, ``Projects`` și ``Packages``.
 
 #. Apăsăm pe ``Repositories``.
    Acum vom vedea întreaga listă de repository-uri pe care le avem. Pentru a crea unul nou, apăsăm pe butonul verde din dreapta sus pe care scrie ``New``.
 
 #. Acum este momentul în care vom da un nume proiectului nostru, o descriere succintă a acestuia și vom putea decide dacă să fie **public** (vizibil tuturor utilizatorilor) sau **privat** (vizibil doar pentru noi și eventualii colaboratori ai proiectului).
    Ne va apărea un formular similar cu cel din imaginea de mai sus.
-   Pentru acest tutorial vom crea un repository **public**.
+   Pentru acest tutorial vom crea un repository **public** ).
    Este indicat ca numele repository-ului să descrie bine proiectul, în cazul nostru ``array-sorting-algorithms``.
    Descrierea proiectului este opțională, dar e recomandat să o adăugăm pentru a fi ușor de înțeles pentru cei care vor ajunge la proiectul nostru.
 
@@ -166,7 +174,7 @@ Acum avem un repository creat local, numit ``array-sorting-algorithms``.
 Conectarea celor două repository-uri
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Am creat până în acest moment un repository local și unul remote.
+Am creat până în acest moment un repository local (pe PC-ul nostru) și unul remote (platforma GitHub).
 Trebuie să le interconectăm pentru a lucra cu ele.
 
 În cazul în care suntem mai mulți membri în echipă, fiecare membru va conecta repository-ul său local, la repository-ul remote.
@@ -187,3 +195,4 @@ Sincronizarea lor se face prin intermediul operațiilor **push** și **pull** ca
 .. figure:: ./gifs/GitHub-remote-local-repos.gif
     :alt: Conectarea repository-ului local cu cel remote
     :scale: 50%
+

chapters/app-dev/intro.rst

@@ -3,8 +3,8 @@
 Introducere
 ===========
 
-Toate dispozitivele electronice pe care le folosim în viața de zi cu zi, de la latopuri sau calculatoare personale, până la telefoane mobile sau smart watch-uri, au în comun un lucru: rulează software.
-Având în vedere cât de variate sunt sistemele pe care rulează aplicațiile, trebuie să avem mereu în minte sistemul pentru care creăm o aplicație.
+Toate dispozitivele electronice pe care le folosim în viața de zi cu zi, de la laptopuri sau calculatoare personale, până la telefoane mobile, frigidere smart sau dispozitive inteligente, au în comun un lucru: *rulează software*.
+Având în vedere cât de variate sunt sistemele pe care rulează aplicațiile, trebuie să avem mereu în minte sistemul pentru care dorim să creăm o aplicație.
 De exemplu, dacă aplicația noastră este gândită pentru un ceas inteligent, atunci trebuie să ținem în minte că resursele vor fi limitate; apare astfel o constrângere din punctul de vedere al memoriei disponibile.
 
 Astfel, trebuie să ținem cont de următoarele:
@@ -42,7 +42,7 @@ Exemple de limbaje compilate sunt **C**, **C++**, **Fortran**, **Rust**, **Go**,
 Limbaje de programare interpretate
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Atunci când scriem un program într-un limbaj **interpretat**, programul este trecut printr-un alt program, numit *interpretor* care analizează și rulează fiecare linie de cod scrisă, pe rând.
+Atunci când scriem un program într-un limbaj **interpretat**, programul este trecut printr-un alt program, numit *interpretor* care analizează și rulează fiecare linie de cod scrisă, *pe rând*. Acest lucru înseamnă că programul poate să ruleze 999 de linii de cod, să afișeze ce trebuie, și să se oprească la un 'print' scris greșit pe linia 1000.
 Dacă alegem să scriem un program într-un limbaj de programare interpretat, atunci programul nostru este **portabil**, adică putem să îl rulăm pe orice sistem pe care avem interpretorul instalat.
 Din cauza faptului că programele sunt analizate și rulate linie cu linie, execuția lor poate fi mai lentă.
 
@@ -62,17 +62,16 @@ Exemple de limbare hibride sunt **Python**, **Java** și **C#**.
 Scrierea codului sursă
 ----------------------
 
-Atunci când spunem că *dezvoltăm o aplicație*, spunem, de fapt, că scriem codul sursă, îl compilăm, îl verificăm de erori.
+Atunci când spunem că *dezvoltăm o aplicație*, spunem, de fapt, că scriem codul sursă, îl verificăm de erori, îl compilăm și reiterăm procesul până când obținem rezultatul dorit.
 Pentru scrierea codului sursă putem să alegem **editoare de text** sau `medii de dezvoltare integrate <https://www.redhat.com/en/topics/middleware/what-is-ide>`_ (*Integrated Development Environment*, *IDE*).
 
 *Editoarele de text* sunt programe mai simple în care putem edita fișiere text, deci putem dezvolta programe.
-Ele pot permite instalarea de extensii care aduc funcționalități în plus, specifice pentru un anumit limbaj.
 Printre cele mai cunoscute editoare de text se numără `GNU Nano <https://www.nano-editor.org>`_, `Vim <https://www.vim.org>`_, `Sublime <http://sublimetext.com>`_, `Atom <https://atom.io>`_, `Visual Studio Code <https://code.visualstudio.com>`_.
 
 *IDE-urile* au anumite funcționalități avansate, multe dintre ele fiind adaptate unui singur limbaj de programare.
-În plus, ele au integrat un compilator/interpretor pentru limbajul suportat.
-Astfel, la o simplă apăsare de buton programul este rulat.
-Printre IDE-uri se număra: `Microsoft Visual Studio <https://visualstudio.microsoft.com>`_, `Eclipse <https://www.eclipse.org/ide/>`_, `IntelliJ <https://www.jetbrains.com/idea/>`_, `XCode <https://developer.apple.com/xcode/>`_.
+În plus, ele au integrat un **compilator/interpretor** pentru limbajul/limbajele suportat/e.
+Astfel, la o simplă apăsare de buton, programul este rulat.
+Printre IDE-uri se număra: `Microsoft Visual Studio <https://visualstudio.microsoft.com>`_, `Eclipse <https://www.eclipse.org/ide/>`_, `IntelliJ <https://www.jetbrains.com/idea/>`_, `Pycharm <https://www.jetbrains.com/pycharm/>`_.
 
 În această carte vom folosi *GNU Nano* ca editor de text principal.
 Este un editor CLI și se pornește folosind comanda ``nano``, așa cum a fost prezentat în capitolul *Lucrul cu fișiere*.