use pdf for vector graphics

src/content/beggining.tex

@@ -19,7 +19,7 @@ A felhőalapú számítástechnikában a felhasználó elől elrejtve, a szolgá
 \subsubsection{Kubernetes}
 A Kubernetes egy Go nyelven írt, nyílt forráskódú konténer orkesztrációs platform, amely képes konténerek automatikus konfigurációjára, skálázására, valamint bizonyos hibák automatikus elhárítására is. Több konténer technológiát \cite{kubernetes-runtimes} támogat, köztük a Dockert is. Nagyon népszerű, gyors fejlesztés alatt álló projekt. Emiatt felhasználói és programozói interfésze gyakran változik, megkövetelve a ráépülő megoldásoktól a hasonló sebességű fejlesztést. Jól definiált interfésze miatt sok ráépülő, azt kiegészítő projekt létezik. A Kubernetes kiváló keretet nyújt mikroszolgáltatás alapú alkalmazások fejlesztésére. 
 
-Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet több darab, de legalább egy-egy példány kötelező. A \ref{fig:k8s-chart} \'abr\'an l\'athat\'o, hogy egy Kubernetes klaszter \cite{kubernetes-nodes} legal\'abb egy Masterből \'es Workerből \'ep\"ul fel, ezek több komponensből állnak. 
+Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet több darab, de legalább egy-egy példány kötelező. Egy Kubernetes klaszter \cite{kubernetes-nodes} legal\'abb egy Masterből \'es Workerből \'ep\"ul fel, ezek több komponensből állnak. 
 
 A Kubernetes Master felelős a klaszterben lezajló folyamatok \cite{kubernetes-concepts} irányításáért, a Slave-ek vagy más néven Worker-ek, valamint az alkalmazások állapotának nyilvántartásáért. A klaszterben történő eseményekre válaszul klaszterszintű választ ad - például egy pod elindítása. Egy Master node számos komponensből áll, ezek a Master egy-egy feladatáért felelnek. Több Master node futtatása esetén - úgynevezett multimaster mode - csak az API Server \cite{kubernetes-api} és az etcd \cite{etcd} komponensekből jön létre több példány, a többiből egyszerre csak egy példány lehet aktív.A Pod \cite{kubernetes-pods} egy vagy több konténert összefogó logikai hoszt. Egy podon belül lévő konténerek osztoznak a hálózaton és a háttértáron, valamint azonos a futtatási specifikációjuk. Ez azt jelenti, hogy az egy podon belüli konténerek localhost-on keresztül elérik egymást, valamint van lehetőség, hogy a konténerekben futó alkalmazások lássák a másik konténerben futó folyamatokat. Egy Kubernetes rendszerben a Pod a legkisebb egység, amit futásra lehet ütemezni. 
 

src/content/work.tex

@@ -9,7 +9,7 @@ Jelenleg a rendszer csővezetékként működik, egyik végén beérkeznek a bem
 
 \begin{figure}[!ht]
 \centering
-\includegraphics[width=120mm, keepaspectratio]{figures/architecture-simple.png}
+\includegraphics[width=\textwidth]{figures/architecture-simple.pdf}
 \caption{A rendszer komponensei \'es azok k\"oz\"otti kapcsolatok}
 \label{fig:birbnetes-architecture}
 \end{figure}
@@ -21,7 +21,7 @@ Fogadja a bemeneti hangfájlokat, ezeket továbbítja a hosszú idejű tárolás
 
 Kapcsolódik egy relációs adatbázishoz, amelyben lementi az információkat, amelyeket fogadott a hangfájllal együtt. Ezeket összerendeli az egyedi azonosítóval, amelyet ő adott a hangfájlnak.  
 
-Miután a Storage Service lementette a hangfájlt, a service publikál egy üzenetet az üzenetsorba, amely tartalmazza a mentett hangfájl címkéjét. A feliratkozott komponensek ezekután a tag használatával letölthetik a lementett hangot és folytathatják rajta a feldolgozást.
+Miután a Storage Service lementette a hangfájlt, a service publikál egy üzenetet az üzenetsorba, amely tartalmazza a mentett hangfájl címkéjét. A feliratkozott komponensek ezekután a c\'imke használatával letölthetik a lementett hangot és folytathatják rajta a feldolgozást.
 
 \subsubsection{Independent Results Service}
 Feldolgozza a mesterséges intelligencia kimenetét, letárolja azt egy tetszőleges relációs adatbázisban. Lekérdezhető tőle - egymástól függetlenül - az egyes hangfájlokról hozott döntés. Az itt tárolt adatok összevethetők az Input Service-ben található adatokkal. Ez segíthet a hiba keresésben, valamint az itt található adatok segítségével a rendszerbe tanulás illeszthető.
@@ -30,13 +30,13 @@ Feldolgozza a mesterséges intelligencia kimenetét, letárolja azt egy tetszől
 Feldolgozza a mesterséges intelligencia kimenetét. Az eredményeket egy idősoros adatbázisban tárolja le. Ez az adatbázis sokkal alkalmasabb és hatékonyabb az eredmények "mérés" szerű kezelésén, de cserébe nem lehet lekérni tőle egyesével a hangfájlokról hozott döntéseket. Használata lehetővé teszi dashboardok készítését, ahol heat-map vagy más grafikonok segítségével tájékozódhat a felhasználó.
 
 \subsection{API-k tervez\'ese}
-Mivel a projekten ketten dolgoztunk, fontos volt számunkra az egyes szolgáltatások API-jainak definiálása. Erre Swagger-t használtunk, ami egy jól dokumentált, nyitott definíciós eszköztár RESTful API-k leírására. Itt lényeges volt számomra, hogy az elvárt bemeneti formátumon felül minden lehetséges visszatérési státusz kódja és üzenetformátuma dokumentálva legyen az általam fejlesztett szolgáltatásoknak, ugyanis ez megkönnyíti a fejlesztést és a lehetséges félreértéseket is elkerüli. A rendszerben bevezettük a címkék vagy tagek fogalmát, amely egyedi azonosítója minden beküldött hangfájlnak. Az egyes tagekhez tárolt metaadatokat is le lehet kérdezni egy endpoint segítségével. 
+Mivel a projekten ketten dolgoztunk, fontos volt számunkra az egyes szolgáltatások API-jainak definiálása. Erre Swagger-t használtunk, ami egy jól dokumentált, nyitott definíciós eszköztár RESTful API-k leírására. Itt lényeges volt számomra, hogy az elvárt bemeneti formátumon felül minden lehetséges visszatérési státusz kódja és üzenetformátuma dokumentálva legyen az általam fejlesztett szolgáltatásoknak, ugyanis ez megkönnyíti a fejlesztést és a lehetséges félreértéseket is elkerüli. A rendszerben bevezettük a címkék fogalmát, amely egyedi azonosítója minden beküldött hangfájlnak. Az egyes c\'imk\'ekhez tárolt metaadatokat is le lehet kérdezni egy endpoint segítségével. 
 
 Az Input Service API-ján kifejezetten sokat gondolkodtam, ugyanis a fájlok és az azokat kísérő metaadatok fogadására több alternatíva létezik. Állományok feltöltése miatt adódik a http mulipart form használata, viszont a metaadatok kerülhetnek külön részbe a kérésnek, vagy egybe valamilyen JSON formátumú adatstruktúrában. Végül az utóbbi mellett döntöttem, ugyanis Pythonhoz rendkívül kiforrott JSON sémavalidációs könyvtárak érhetők el, ezzel szemben ilyen eszközt, ami elegánsan képes multipart formok sémáját validálni, nem találtam. 
 
 A Results Statistics Service nem szolgál ki REST-es API-t, csupán fogadja a message queue-n érkező eredményeket és azokat letárolja a hozzá kapcsolódó timeseries adatbázisban. 
 
-Ez előbbivel szemben az Independent Results Service egyik legfontosabb tulajdonsága, hogy egy REST API-t nyújt. Itt kihasználva a relációs adatbázis által nyújtott lehetőségeket definiáltam olyan végpontokat, melyek visszaadnak minden pozitív vagy negatív eredményt, valamint adott dátum előtt, illetve után rögzített eredményeket. A cél az volt, hogy le lehessen kérdezni azegyes hangfájlokhoz tartozó adatokat, és ezt egy olyan endpoint segítségével lehet megtenni, amelyben a hangfájl tagje alapján azonosítható ez be.
+Ez előbbivel szemben az Independent Results Service egyik legfontosabb tulajdonsága, hogy egy REST API-t nyújt. Itt kihasználva a relációs adatbázis által nyújtott lehetőségeket definiáltam olyan végpontokat, melyek visszaadnak minden pozitív vagy negatív eredményt, valamint adott dátum előtt, illetve után rögzített eredményeket. A cél az volt, hogy le lehessen kérdezni azegyes hangfájlokhoz tartozó adatokat, és ezt egy olyan endpoint segítségével lehet megtenni, amelyben a hangfájl c\'imk\'eje alapján azonosítható ez be.
 
 \subsection{Fejleszt\'es folyamata}
 Fejlesztés során igyekeztem arra figyelni, hogy az általam írt kód helyes legyen, ezért a projekthez beállítottam egy folyamatos integrációs rendszert, amely minden git commitra lefuttatott teszteket, és amennyiben a kód átment ezeken a tesztken, container image-et épített és publikált az általam beállított container registry-be. Később a Kubernetes rendszerbe is innen kerültek be az egyes mikroszolgáltatások. 
@@ -122,6 +122,8 @@ A mikroszolgáltatások fejlesztése közben önmagukban teszteltem őket és pr
 
 Előkerültek olyan hibák, amik eltérő feltételezésekből következnek. Ezen esetekben egyeztettük a konvencióink, majd a javítás után újra teszteltük a működést.
 
+A folyamat eredm\'enyek\'ek\'ent kaptunk egy műk\"odő rendszert, aminek minden komponense k\'epes volt egym\'assal egy\"uttműk\"odni. Beadtunk p\'eld\'aul egy olyan hangf\'ajlt, amely sereg\'ely \'eneket \'es egy olyat, amin motorhang volt. R\"ovid idő eltelt\'evel lek\'erzhető volt az eredm\'eny az Independent Results Service-től, mindkettőt motorhangk\'ent klasszifik\'alta az MI. Ugyanekor az InfluxDB-ből lek\'erezhető volt az időpontokban t\"ort\'ent m\'er\'esek. Ez nem probl\'ema a mi projekt\"unk szempontj\'ab\'ol, elv\'egre a f\'el\'ev elej\'en kiindul\'o felt\'etelez\'es\"unk volt, hogy az MI modellek adottak, azokon nem c\'elunk v\'altoztatni, azokat jav\'itani.
+
 \subsection{\"Osszefoglal\'as}
 A félév során számos új tudással bővültem, többek között elsajátítottam a Kotlin nyelv alapszintű működését, valamint megtanultam, hogy kell mikroszolgáltatás alapú rendszert tervezni, fejleszteni és az ezek Kubernetesbe telepítésével kapcsolatos megontolásokat is részletesebben megismertem. Több technológia működésébe nyertem betekintést, ezzel tágítva az eszköztáram.