diff --git a/Byte_Me_snippet/index.md b/Byte_Me_snippet/index.md
deleted file mode 100644
index 3f4affe..0000000
--- a/Byte_Me_snippet/index.md
+++ /dev/null
@@ -1,16 +0,0 @@
-#Tanulságok
-A félév elejét azzal kezdtük, hogy egy excel táblába felírtuk, hogy milyen részfeladatokat kell megoldani. Ezeket felosztottuk egymás között, viszont a követelményeket nem tisztáztuk megfelelően, ebből később problémák lettek, mert a leadás előtt derültek ki, hogy bizonyos funkciók nem úgy lettek leimplementálva, ahogy azt kellett volna.
-
-Az is sokat segített volna, hogy ha milestone-okat tűzünk ki, hogy a félév során folyamatosan haladjon a fejlesztés. A félév végére eléggé besűrűsödött a házifeladatok leadása és jobb lett volna nem a végére hagyni.
-
-A kódoláshoz kapcsolódóan a függőségek megléte, még nem feltétlen jelenti, hogy nem lehet elkezdeni a részfeladatot (Fel kell mérni, hogy mire is van szükség. Ha valami fordítási hibát okozna, akkor ki is lehet kommenteli.)
-
-Ami viszont bevált és sokat segített, hogy készítettünk egy közös excel táblát, amin nyilvántartottuk, hogy kinek mi a feladata, és ha valakinek a feladatának az elvégzéséhez, egy másik embernek a munkája szükséges, azt könnyedén lehetett jelezni. Felvettük rá, hogy milyen problémákkal találkoztunk, hogy ha valakinek a része nem megfelelően működött, akkor itt írtunk róla issue-t. Egy külön lapot hoztunk létre, ahova a kérdéseinket tehettük fel az adott feladathoz vagy a követelménnyel kapcsolatban. Ezeket a kérdéseket igyekeztünk megválaszolni magunktól, vagy előadás után megkérdeztük. A határidőket is ide raktuk fel, így minden fontos információ egy helyen volt elérhető.
-
-Sokat segített, hogy a feladathoz egy teljesen üres projektből indultunk és az STV-t, mint csak iránymutatást használtuk, de nem azt írtuk át. Így, ha valami nem fordult, vagy nem úgy működött, ahogy azt mi elvártuk, tudtuk, hogy az okozza, amit nem régen írtunk, nem pedig valami teljesen más egy teljesen másik fájlban.
-
-A snippetes oldalt nagyon érdemes használni, lehet a félév elejét azzal kellene kezdeni, hogy a többiek tapasztalatait átolvassátok, mert nagyon sokat lehet vele időben nyerni, ha tudjátok, hogy ez a probléma már másnál is felmerült, és ott le van írva, hogy miként oldotta meg.
-
-Ne féljetek a git-et használni, mert több előnye van mint amekkora energiabefektetésbe kerül a megtanulása. Csapaton belül eltért nálunk, hogy terminálból vagy GUI-n keresztül használtuk a git-et, de ha eddig még nem használtatok érdemes inkább GUI-t használni.
-
-Érdemes megjegyezni, hogy a Qt Creatornak is van egy plugin-je (ModelEditor), amivel lehet szép UML diagramokat gyártani, nem csak online tool-okkal vagy Visio-val. Viszont UML diagrammot nem csak "kézzel" lehet készíteni. Lehetőség van C++ forrásból generálni UML diagramot, például a Visual Paradigm segítségével. Amikor telepítitek válasszátok a 30 napos enterprise verziót, mert csak azzal elérhető a számunkra fontos funkció (Tools->Code->Instant reverse...). Az ingyenes próbaverziónak az a hátránya, hogy ha ki szeretnétek importálni a diagramot, akkor tele lesz nyomva vízjellel. Ezt némi ügyeskedéssel (google) el lehet tüntetni.
\ No newline at end of file
diff --git a/Gemfile b/Gemfile
index b687671..681832a 100644
--- a/Gemfile
+++ b/Gemfile
@@ -1,3 +1,4 @@
source 'https://rubygems.org'
gem 'RedCloth', :platforms => :mswin
gem 'github-pages'
+gem 'webrick'
diff --git a/README.md b/README.md
index fc10ee4..1d698bb 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,18 @@
# snippets
A set of example-based tutorials for various classes
+
+## Run locally
+
+To test the webpage locally, you can serve the page using docker. On Windows, you can preferably use Docker Desktop.
+
+1. Open a terminal in the root of the repository.
+
+1. Run the following command in case of Windows (PowerShell), Linux or MacOS:
+
+```bash
+docker run --rm -v ${PWD}:/srv/jekyll -p 4000:4000 jekyll/jekyll jekyll serve --force_polling --livereload
+```
+
+1. Open the [http://localhost:4000/snippets/](http://localhost:4000/snippets/) link in a browser.
+
+1. After every modification, you can see the result in the browser.
\ No newline at end of file
diff --git a/_layouts/default.html b/_layouts/default.html
index 8426392..c99a33b 100644
--- a/_layouts/default.html
+++ b/_layouts/default.html
@@ -18,6 +18,8 @@
- Minden snippet egyszerre, kódnévvel
{% assign skippedTags = 'afhf skipfromindex' %}
{% assign skippedPageTag = 'skipfromindex' %}
@@ -26,14 +25,11 @@
{% endcapture %}
{% assign allTagsArray = allTags | split : ' ' | sort %}
- Minden címke: {% for t in allTagsArray %} {{t}} {% endfor %}
-
- Csak az alkalmazásfejlesztés tárgy snippetjei
-
-
Minden snippet címkék szerint
+
Minden címke:
+ {% for t in allTagsArray %} {{t}} {% endfor %}
{% for tag in allTagsArray %}
-
{{tag}}
+
{{tag}}
{% for page in site.pages %}
{% if page.tags contains tag %}
diff --git a/snippets/0002_Zarovizsga/index.md b/snippets/0002_Zarovizsga/index.md
index 0f445bd..aa4f13f 100644
--- a/snippets/0002_Zarovizsga/index.md
+++ b/snippets/0002_Zarovizsga/index.md
@@ -10,19 +10,73 @@ authors: Csorba Kristóf
FIGYELEM! Ez a snippet az Alkalmazásfejlesztés tantárgyra vonatkozik (VIAUMA09)! Ne keverjétek össze például az Alkalmazásfejlesztési környezetekkel (VIAUAC04)!
-A záróvizsgán a tananyag az Alkalmazásfejlesztés tárgy anyagát fedi le, a konkrét kérdések azonban a záróvizsga koncepciójának megfelelően sokkal inkább koncepciókra és témakörökre fókuszálnak és nem alacsony szintű részletekre. A záróvizsgán a kiinduló kérdések az alábbiak lehetnek:
+Mivel a tematika 2020. őszén megváltozott (C++ és Qt helyett C# és .NET UWP), ezért mindenki az általa hallgatótt anyagból záróvizsgázik, a nektek megfelelő részt vegyétek figyelembe!
+
+A záróvizsgán a tananyag az Alkalmazásfejlesztés tárgy anyagát fedi le, a konkrét kérdések azonban a záróvizsga koncepciójának megfelelően sokkal inkább koncepciókra és témakörökre fókuszálnak és nem alacsony szintű részletekre. A záróvizsgán a kiinduló kérdések például az alábbiak lehetnek:
+
+# Tematika 2020. ősztől (C# és .NET UWP)
+
+ * C#
+ * Delegate típusok és események
+ * IEnumerable és Linq
+ * Sorosítás, XML és JSON
+ * Kommunikáció, HttpClient
+ * Entity Framework
+ * Tesztelés: unit tesztek, Test Driven Development, mockolás és Moq package
+ * UWP témakör
+ * A xaml nyelv: szintaxis alapok, mire jó. Layout managerek, statikus erőforrások, adatkötés (x:Bind) beállításai, kapcsolat a .xaml és a .xaml.cs fájlok között.
+ * Rajzolás, a Shape osztály
+ * MVVM architektúra elemei, hol van adatkötés, INotifyPropertyChanged esemény jelentősége
+ * Tervezés
+ * Dependency injection
+ * SOLID elvek és jelentésük
+ * Test Driven Development
+ * Létrehozási tervezési minták
+ * Factory és abstract factory
+ * Singleton
+ * Parancsvégrehajtási minták
+ * Command, CommandProcessor
+ * Memento
+ * További tervezési minták a tananyagból
+ * Observer
+ * Adapter
+ * Facade
+ * Composite
+ * Prototype
+ * Proxy
+ * Builder
+ * State
+
+Minden témakörben, de különösen a tervezéssel kapcsolatos kérdések esetében előfordulhat olyan kérdés, hogy a diplomatervben szerepel-e valamilyen tervezési minta vagy hogyan érvényesülnek a SOLID elvek. Ha nem szerepelnek benne, akkor hogyan lehetne őket felhasználni, alkalmazni.
+
+Néhány konkrétabb példa kérdés:
+
+ * Egy pályatervező algoritmus strategy patternként kerül bele egy programba. Hogyan lehet átadni a pályatervezést használó objektumoknak a pályatervezőt (stratégiát) úgy, hogy az a tesztelést is jól támogassa? (dependency injection)
+ * Singleton: hogyan lehet implementálni, többszálú programok esetén mire kell figyelni, milyen nehézséget okozhat egy singleton teszteléskor? (Teszteléskor nehéz lecserélni, nem lehet csak úgy egy másik objektumot átadni a tesztelendő kódnak, ha a függőség egy singleton.)
+ * A xaml adatkötés és az INotifyPropertyChanged melyik tervezési mintának felel meg? Hogyan működik és mire kell figyelni az adatkötött propertyk setterjében?
+ * Entity Framework használata esetén nem kell SQL lekérdezéseket írni a forráskódba, az adatbázist nem táblák soraiként érjük el. Hogyan működik ehelyett?
+ * Mi a feladata UWP alatt egy layout managernek? Mondjon pár példát Layout Managerre.
+ * Mire jó a Dependency Injection? Hogyan szokás átadni a függősegeket egy osztálynak?
+ * Mi a kapcsolat a .xaml és .xaml.cs fájlok között? Melyik tartalma melyik osztályba kerül?
+ * Unit tesztek készítésekor mikor van szükség egy osztály mockolására?
+ * A dependency injection mit jelent? Mivel könnyíti a tesztelhetőséget? Miért nem jó, ha a függőségeket a konstruktor példányosítja? Mi a különbség, ha konstruktor paraméterként vagy propertynek adjuk át a függőséget? Mit jelent a mockolás?
+ * Mire ad megoldást az Observer minta? Hogyan tudunk változást detektálni, ha nem használjuk? Milyen szereplői vannak? UWP XAML környezetben hogyan jelenik meg? Mire jó az INotifyPropertyChanged interfész és hogyan működik az x:Bind?
+ * Mutassa be a Builder mintát a StringBuilder klasszikus megoldáson keresztül. Miért választjuk le ezeket a funkciókat a string osztályról? Miben tér el a Builder, a Factory és a Prototype minta?
+
+# Tematika 2019. őszi félévvel bezárólag (C++ és Qt)
* Verziókövetés témakör
* Elosztott és centralizált verziókövetés különbségei (előnyök, hátrányok), a repositoryk szinkronizálása (push, pull, fetch) Git alatt.
- * Csapatmunka git alatt: merge és rebase, git flow (master, development, feature branchek, release branchek, hotfixek stb.)
+ * Csapatmunka git alatt: merge és rebase, git flow (master, development, feature branchek, release branchek, hotfixek stb.), hibák helyre hozása (force push, elrontott merge vagy rebase, visszaállás korábbi verzióra, detached head állapot jelentése).
* C++14, Qt és QML
* C++ smart pointerek (unique, shared és weak pointerek)
* C++ lambda kifejezések, auto kulcsszó és range for
* Teljes fordítási folyamat Qt alatt (compiler, linker, MOC, QRC mechanizmus, statikus és dinamikus library (DLL) jelentése)
* A QML és QmlEngine működése
* QML scriptnyelv, JavaScript, események kezelése, kapcsolat a C++ oldallal
- * QML controlok: listák (model és delegate jelentése), rajzolás (onPaint működése, Context)
+ * QML controlok: listák (model és delegate jelentése), rajzolás (onPaint működése, Context szerepe)
* A signals and slots mechanizmus célja, működése, mi mire fordul le (emit, signal, slot kulcsszavak, a működés alapgondolata és a MOC szerepe)
+ * A QRC mechanizmus jelentése, milyen fájlok és hogyan ágyazhatók be az exe fájlokba? Mit hoz létre ehhez a Meta-object compiler?
* Tervezés
* SOLID elvek és jelentésük
* Létrehozási tervezési minták
@@ -30,3 +84,18 @@ A záróvizsgán a tananyag az Alkalmazásfejlesztés tárgy anyagát fedi le, a
* Viselkedési tervezési minták
Minden témakörben, de különösen a tervezéssel kapcsolatos kérdések esetében előfordulhat olyan kérdés, hogy a diplomatervben szerepel-e valamilyen tervezési minta vagy hogyan érvényesülnek a SOLID elvek. Ha nem szerepelnek benne, akkor hogyan lehetne őket felhasználni, alkalmazni.
+
+Néhány konkrétabb példa kérdés:
+
+ * Git alatt visszaállas korábbi állapotra: reset, checkout, detached head, hard reset jelentése
+ * Egy pályatervező algoritmus strategy patternként kerül bele egy programba. Hogyan lehet átadni a pályatervezést használó objektumoknak a pályatervezőt (stratégiát) úgy, hogy az a tesztelést is jól támogassa? (dependency injection)
+ * Qt alatt hogyan lehet egy PNG fájlt (pl. splash screen) eltárolni az exe fájlban? (QRC, ilyenkor mit generál le a MOC?)
+ * Git branching, merge és rebase, push utáni rebase által okozott gond mibenléte és javítása.
+ * Valójában mi a branch és mi a HEAD. Mit jelentenek? A .git könyvtárban ezek hogyan jelennek meg?
+ * C++11 óta hová tűnt a new operátor? (smart pointerek, működésük)
+ * Qt alatt van signals and slots. Mik ezek és hogyan lehet, hogy szabvány C++ fordító (pl. gcc, msvc) le tudja fordítani az ilyen forráskódot?
+ * Singleton: hogyan lehet implementálni, többszálú programok esetén mire kell figyelni, milyen nehézséget okozhat egy singleton teszteléskor? (Teszteléskor nehéz lecserélni, nem lehet csak úgy egy másik objektumot átadni a tesztelendő kódnak, ha a függőség egy singleton.)
+ * Stringeket összefűzni költséges (miért?), ezen hogy segít a builder minta? (Minden műveletnál új string objektum jön létre, a builder tudja a tartalmát módosítani az összeállítás alatt, nem úgy, mint a QString.)
+ * Miért rossz a force push? Mire kényszeríti a többieket és hogyan lehet "visszacsinálni"?
+ * Qt C++ alatt mire fordul le az emit kulcsszó? A signal és slot közül melyik sima metódus? Ki írja meg őket?
+ * Mi az interaktiv rebase (squashing)? Mire jó?
diff --git a/snippets/0102_Info2Git/images/git-ext-checkout-remote.png b/snippets/0102_Info2Git/images/git-ext-checkout-remote.png
new file mode 100644
index 0000000..cb27594
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-checkout-remote.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-checkout.png b/snippets/0102_Info2Git/images/git-ext-checkout.png
new file mode 100644
index 0000000..da21e24
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-checkout.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-clone.png b/snippets/0102_Info2Git/images/git-ext-clone.png
new file mode 100644
index 0000000..35f2550
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-clone.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-commit.png b/snippets/0102_Info2Git/images/git-ext-commit.png
new file mode 100644
index 0000000..65704c0
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-commit.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-config.png b/snippets/0102_Info2Git/images/git-ext-config.png
new file mode 100644
index 0000000..9f0e23b
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-config.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-init.png b/snippets/0102_Info2Git/images/git-ext-init.png
new file mode 100644
index 0000000..450a2a9
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-init.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-new-branch.png b/snippets/0102_Info2Git/images/git-ext-new-branch.png
new file mode 100644
index 0000000..a12f5ea
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-new-branch.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-postpush.png b/snippets/0102_Info2Git/images/git-ext-postpush.png
new file mode 100644
index 0000000..276b5a1
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-postpush.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-precommit.png b/snippets/0102_Info2Git/images/git-ext-precommit.png
new file mode 100644
index 0000000..84d91c7
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-precommit.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-push.png b/snippets/0102_Info2Git/images/git-ext-push.png
new file mode 100644
index 0000000..d72d702
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-push.png differ
diff --git a/snippets/0102_Info2Git/images/git-ext-status.png b/snippets/0102_Info2Git/images/git-ext-status.png
new file mode 100644
index 0000000..7eea51b
Binary files /dev/null and b/snippets/0102_Info2Git/images/git-ext-status.png differ
diff --git a/snippets/0102_Info2Git/images/github-access-token.png b/snippets/0102_Info2Git/images/github-access-token.png
new file mode 100644
index 0000000..72599f8
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-access-token.png differ
diff --git a/snippets/0102_Info2Git/images/github-authorize-classroom.png b/snippets/0102_Info2Git/images/github-authorize-classroom.png
new file mode 100644
index 0000000..51cc5e1
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-authorize-classroom.png differ
diff --git a/snippets/0102_Info2Git/images/github-classroom-accept.png b/snippets/0102_Info2Git/images/github-classroom-accept.png
new file mode 100644
index 0000000..36b5156
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-classroom-accept.png differ
diff --git a/snippets/0102_Info2Git/images/github-classroom-ready.png b/snippets/0102_Info2Git/images/github-classroom-ready.png
new file mode 100644
index 0000000..d721268
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-classroom-ready.png differ
diff --git a/snippets/0102_Info2Git/images/github-classroom-repository.png b/snippets/0102_Info2Git/images/github-classroom-repository.png
new file mode 100644
index 0000000..b09b876
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-classroom-repository.png differ
diff --git a/snippets/0102_Info2Git/images/github-code-copy.png b/snippets/0102_Info2Git/images/github-code-copy.png
new file mode 100644
index 0000000..85ac432
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-code-copy.png differ
diff --git a/snippets/0102_Info2Git/images/github-create-pr.png b/snippets/0102_Info2Git/images/github-create-pr.png
new file mode 100644
index 0000000..30ecb15
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-create-pr.png differ
diff --git a/snippets/0102_Info2Git/images/github-evaluation-comment.png b/snippets/0102_Info2Git/images/github-evaluation-comment.png
new file mode 100644
index 0000000..314041c
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-evaluation-comment.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-branches.png b/snippets/0102_Info2Git/images/github-pr-branches.png
new file mode 100644
index 0000000..4aa6f1b
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-branches.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-changes-requested.png b/snippets/0102_Info2Git/images/github-pr-changes-requested.png
new file mode 100644
index 0000000..4a346eb
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-changes-requested.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-checks.png b/snippets/0102_Info2Git/images/github-pr-checks.png
new file mode 100644
index 0000000..de719af
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-checks.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-comment.png b/snippets/0102_Info2Git/images/github-pr-comment.png
new file mode 100644
index 0000000..1756971
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-comment.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-description.png b/snippets/0102_Info2Git/images/github-pr-description.png
new file mode 100644
index 0000000..a39c932
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-description.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-draft.png b/snippets/0102_Info2Git/images/github-pr-draft.png
new file mode 100644
index 0000000..fc7fcd9
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-draft.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-open.png b/snippets/0102_Info2Git/images/github-pr-open.png
new file mode 100644
index 0000000..5395afe
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-open.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-ready.png b/snippets/0102_Info2Git/images/github-pr-ready.png
new file mode 100644
index 0000000..7934249
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-ready.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-rerequest.png b/snippets/0102_Info2Git/images/github-pr-rerequest.png
new file mode 100644
index 0000000..81ddb9c
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-rerequest.png differ
diff --git a/snippets/0102_Info2Git/images/github-pr-reviewer.png b/snippets/0102_Info2Git/images/github-pr-reviewer.png
new file mode 100644
index 0000000..9c1d587
Binary files /dev/null and b/snippets/0102_Info2Git/images/github-pr-reviewer.png differ
diff --git a/snippets/0102_Info2Git/index.md b/snippets/0102_Info2Git/index.md
new file mode 100644
index 0000000..e191bbe
--- /dev/null
+++ b/snippets/0102_Info2Git/index.md
@@ -0,0 +1,353 @@
+---
+layout: default
+codename: Info2Git
+title: Info2 feladatok beadása
+tags: git info2
+authors: Knyihár Gábor
+---
+
+> Az utóbbi félévekben több változás is történt laborok beadásának tekintetében, így a korábbi leírások már nem minden esetben érvényesek.
+
+# Info2 feladatok beadása (2024)
+
+Minden feladat beadásához (labor, házi feladat, zh) a **GitHub** platformot használjuk. Minden labor beadása egy-egy GitHub repository-ban történik, melyet a Moodle-ben található linken keresztül fogtok megkapni. A feladatok megoldását ezen repository-ban kell majd elkészíteni, és ide kell feltölteni. A kész megoldás beadása a repository-ba való feltöltés után egy un. **pull request** formájában történik, amelyet mindig a saját laborvezetőtökhöz kell rendelnetek. Ez a snippet, ennek a folyamatnak a részletes leírását tartalmazza.
+
+> **Fontos**:
+> Az itt leírt formai előírások betartása elvárás. A nem ilyen formában beadott megoldásokat nem értékeljük.
+
+## Előkészületek
+
+Első lépésként, ha még nincs ilyenetek, [regisztráljatok](https://github.com/join) magatoknak egy GitHub felhasználót.
+
+A hatékony munkavégzés érdekében ismerkedjünk meg a git alapvető működésével és az alapfogalmakkal, melyhez számos leírás található a [git](/snippets/index.html#git) címke alatt.
+
+## Repository létrehozása
+
+Minden héten az aktuális feladathoz egy meghívó url-t fogtok kapni a Moodle-ben. A meghívás elfogadásával létre fog jönni a saját repository-tok amiben a megoldásokat kell elkészíteni. Az url minden laborhoz más lesz.
+
+1. Keressük meg a Moodle kurzus oldalán a laborhoz tartozó **meghívó url-t**, és nyissuk meg.
+
+1. Ha kéri, adjunk engedélyt a **GitHub Classroom** alkalmazásnak, hogy használja az account adataidat.
+
+
+
+1. Látni fogunk egy oldalt, ahol elfogadhatjuk a feladatot (`Accept the assignment`). Kattintsunk a gombra.
+
+
+
+1. Várjuk meg, amíg elkészül a repository. A repository linkjét itt fogjuk megkapni.
+
+
+
+1. Nyissuk meg a repository-t a webes felületen a linkre kattintva.
+
+
+
+> A repository privát, vagyis csak te és az oktatók látják a tartalmát.
+
+## Repository letöltése
+
+Annak érdekében, hogy a repository-n dolgozni tudjuk, szükségünk van egy lokális verzióra, amit klónozással fogunk létrehozni. A git alapvetően egy parancssoros alkalmazás, vagyis minden műveletet a parancssorba gépelt utasításokkal tudunk végrehajtani. Viszont annak érdekében, hogy ne kelljen különböző utasításokat ismerni, számos vizuális git kliens program készült már. Ha már van kedvencünk, akkor nyugodtan használjuk azt, mivel bármelyikkel el tudjuk végezni a feladatot. Ha még nem ismerünk ilyet, akkor kövessük az alábbi útmutatót, ahol a Git Extensions programot mutatjuk be. Minden egyes lépéshez kiírjuk a parancssoros megfelelőjét is az utasításnak.
+
+> Ha saját gépen dolgozunk, szükségünk lesz a [Git](https://git-scm.com/download/win) valamint a [Git Extensions](https://gitextensions.github.io/) szoftverre.
+
+1. Másoljuk ki a repository linkjét.
+
+ 
+
+1. Nyissuk meg a Git Extensions programot.
+
+1. Első használatkor, vagy a labor kezdetén állítsuk be a nevünket és az email címünket:
+ - Válasszuk a `Tools` > `Settings` menüt.
+ - Navigáljunk el a `Git` > `Config` almenübe a bal oldalon található fában.
+ - Adjuk meg a nevünket és az email címünket, amivel regisztráltunk a GitHub-ra.
+
+ 
+
+ **Parancssorban**
+
+ ```bash
+ git config user.name "nev"
+ git config user.email "nev@email.hu"
+ ```
+
+ Ha saját gépen dolgozunk, használhatjuk a global kapcsolót is, ekkor nem kell minden alkalommal megcsinálni.
+
+ ```bash
+ git config --global user.name "nev"
+ git config --global user.email "nev@email.hu"
+ ```
+
+1. Klónozzuk le a repositoryt.
+ - Válasszuk a ˙Clone repository` opciót.
+ - A `Repository to clone`-hoz adjuk meg a linket amit kimásoltunk.
+ - A `Destionation`-nek adjuk meg, hol szeretnénk létrehozni a lokális másolatot.
+ - Menjünk a `Clone` gombra, majd `OK` és `Igen`
+
+ 
+
+ - Abban az esetben, ha authentikációt kér a program, adjuk meg a felhasználónevünket és egy **personal access token**-t.
+
+ > **Fontos**: 2021 óta a GitHub nem fogad el jelszót az egyes műveletek authentikálásához, emiatt szükségünk lesz egy **Personal Access Token**-re, és mindenhol ezt kell majd használnuk a jelszó helyett.
+ >
+ > Tokent a következő módon lehet generálni:
+ > - Látogassunk el a [https://github.com/settings/tokens](https://github.com/settings/tokens) oldalra.
+ > - Válasszuk a `Generate new token` > `Generate new token (classic)` opciót.
+ > - Adjunk meg egy leírást a `Note` mezőbe.
+ > - Adjuk meg, hogy mikor járjon le a token az `Expiration` mezőbe. Ha saját gépen dolgozunk, akkor választhatunk hosszú időtartamot, mivel a kliens meg fogja jegyezeni. Laborgépeken érdemes minél rövidebb időt kiválasztani, hogy elkerüljük, hogy valaki illetéktelen hozzáférjen a fiókunkhoz.
+ > - A `Scope`-nál pipáljuk be a `repo`-t.
+ >
+ > 
+ >
+ > - Menjünk a `Generate token` gombra a lap alján.
+ > - **Másoljuk ki** a kapott tokent és **mentsük el** valahova, mert többet nem lesz lehetőségünk megnézni.
+ > - Minden alkalommal, amikor a git kliens jelszót kér, a tokent kell megadni.
+
+ 
+
+ **Parancssorban**
+
+ ```bash
+ cd
+ git clone
+ ```
+
+## Új branch létrehozása és Neptun kód megadása
+
+Klónozás után a kiindulási kódunk a master branchen található, ahol még semmilyen nyoma nincs a labor megoldásnak. A beadás során a laborvezető mindig a te munkádara lesz kíváncsi, ezért a beadott megoldást mindig a kiindulási alappal fogja összehasonlítani és a változásokat értékelni. Ennek érdekében a kiindulási alapot meg kell tartanunk abban az állapotban, amiben van, vagyis a **master** branchre ne kommitolj soha! Helyette létrehozunk egy új ágat (branch) és azon fogunk dolgozni, majd pedig a pull requestet adunk be, ami pontosan ezt a két ágat fogja összehasonlítani.
+
+> **Figyelem**:
+> Abban az esetben ha ezt a branchet már korábban létrehoztad és csak folytatni szeretnéd a megkezdett munkád, akkor hagyd ki ezt a lépést és ugorj a [Váltás meglévő branchre](#váltás-meglévő-branchre) lépésre.
+
+1. Hozzunk létre egy új branchet.
+ - Válasszuk a `Commands` > `Create branch...` menüpontot.
+ - Adjunk meg egy nevet az új branchnek. Bármilyen neved adhatunk, de az egységesség kedvéért legyen `megoldas`.
+ - Figyeljünk rá, hogy a branch nevében ne legyen ékezet.
+ - Menjünk a `Create branch` gombra, majd `OK`.
+
+ 
+
+ **Parancssorban**
+
+ ```bash
+ git checkout -b
+ ```
+
+1. Nyissuk meg a repositoryt és töltsük ki a `neptun.txt` fájlt.
+ - A fájlt a repository gyökerében találjuk.
+ - Ne írjunk semmi mást a fájlba, csakis a Neptun kódunk 6 karakterét.
+
+1. Kommitoljuk a változtatást.
+ - Ellenőrizzük, hogy a megfelelő branchen vagyunk, majd menjünk a `Commit` gombra. A szám a felifat mellett a változtatások számát jelenti.
+
+ 
+
+ - Válasszuk ki a változtatásokat, amiket szeretnénk menteni és vigyük le a `Stage` / `Stage all` gombokkal.
+ - Adjunk meg egy üzenetet, hogy mit tartalmaz a kommit.
+ - Menjünk a `Commit` gombra, majd `OK`.
+
+ 
+
+ **Parancssorban**
+
+ ```bash
+ git status # változások lekérése
+
+ git add # adott fájl stagelése
+ git add -A # összes fájl stagelése
+
+ git commit -m # stagelt változtatások kommitolása
+ ```
+
+## Váltás meglévő branchre
+
+Előfordulhat olyan eset, hogy a laboron laborgépen dolgoztál, de nem sikerült befejezni a munkát, ezért otthon folytatni szeretnéd. Ebben az esetben nem kell újra létrehozni a `megoldas` branchet, hanem a meglévőt tudod folytatni. Ahhoz, hogy folytatni tudd, először ki kell választanod a megfelelő branchet.
+
+1. Nyisd le a branch választó legördülő menüt és menj a `Checkout branch` opcióra.
+
+ 
+
+2. Menj a `Remote branch`-re, válaszd az `origin/megoldas` branchet, majd `Checkout` és `OK`.
+
+ 
+
+**Parancssorban**
+
+```bash
+git checkout
+
+# például ebben az esetben:
+
+git checkout megoldas
+```
+
+
+## Megoldások elkészítése
+
+Ezután következik a megoldások elkészítése. Ennek során figyelj a következőkre:
+
+- A feladatokat a kiadott leírás illetve a laborvezető utasításai alapján készítsd el.
+- Gyakran, de legalább minden feladat után kommitolj.
+- Figyelj rá, hogy mindig jó branchen legyél, valamint hogy minden módosítást kommitolj, amit te csináltál.
+- A beállítási fájlokat, fordítási eredményeket (pl.: `.vs`, `bin`, `˙*.mvb`) ne kommitolj.
+- Kommit üzenetnél nem számít, hogy magyarul vagy angolul írod, de mindig értelmes üzenetet adj meg ami tükrözi, hogy mit tartalmaz a változtatás.
+- Amennyiben a feladat képernyőképet kér, azt mindig a megfelelő helyre, a megadott néven mentsd el.
+- Szöveges válaszok esetén a kiadott leírás szövegébe, a megfelelő helyre kell írni a választ.
+
+## Megoldások feltöltése
+
+Miután végeztünk, de legkésőbb a labor végén, töltsük fel a megoldásokat a GitHub szerverére. Ezt a műveletet `push`-nak hívják.
+
+1. Ellenőrizzük, hogy a megfelelő branchen állunk, illetve vannak-e lokális kommitok:
+ - Azt, hogy a branchek melyik kommitra mutatnak, a fában láthatjuk.
+ - A lokális brancheket zöld színnel, a távoli brancheket bordó színnel láthatjuk.
+ - A `megoldas` branch csak lokálisan létezik, mivel nincs sehol `origin/megoldas`.
+ - Amennyiben a lokális és a távoli branch ugyanarra a kommitra mutat, akkor a változtatások szinkronizálva vannak.
+
+ 
+
+ **Parancssorban**
+
+ ```bash
+ git log
+ ```
+
+1. Menjünk a `Push` gombra, majd ismét `Push`, `Igen`, `Igen` és `OK`.
+ - Abban az esetben, ha authentikációt kér, használjuk a korábbi lépésben készített tokent.
+
+ 
+
+ **Parancssorban**
+
+ ```bash
+ git push --set-upstream origin # első alkalommal, amikor még nem létezik a távoli
+
+ git push # minden további alkalommal
+ ```
+
+1. Ellenőrizzük, hogy a szinkronban van-e lokális és a távoli branch.
+ - A lokális és a távoli branch ugyanarra a kommitra mutat.
+ - Nincs nem kommitált változtatás.
+
+ 
+
+ **Parancssorban**
+
+ ```bash
+ git status
+ ```
+
+## Megoldások beadása
+
+Miután feltöltöttünk mindent, még nem vagyunk készen. Még be kell adni a módosításokat amihez egy pull requestet kell létrehozni.
+
+1. Keressük fel a repository oldalát a GitHub-on.
+
+1. Hozzunk létre egy pull requestet.
+ - Ha nem rég pusholtunk, akkor a GitHub fel is ajánla, hogy létrehozhatjuk a pull requestet.
+ - Más esetben menjünk a pull request fülre.
+
+ 
+
+ - Menjünk a `Create pull request` gombra.
+ - A `base` legyen a `master`, a `compare` pedig a `megoldas` branch.
+ - Ellenőrizzük a változtatásainkat, melyek megjelennek lejjebb, majd menjünk a `Create pull request` gombra.
+
+ 
+
+ - Adjuk a pull requestnek címet, lehetőség szerinte értelmeset.
+ - Olvassuk át az alapértelmezett leírást, és szükség szerint írjunk hozzá megjegyzést. (A preview fülre kattintva jobban olvasható.)
+
+ 
+
+ - Ha mindennel elégedettek vagyunk, menjünk a `Create pull request` gombra.
+
+ > **Fontos**:
+ > Miután megnyitottad a pull requestet, le fog futni egy automatikus kiértékelés:
+ > - A kiértékelő az alapvető formai követelményeket ellenőrizni (pl.: kitöltötted-e a `neptun.txt`-t).
+ > - Kigyűjti a képernyőképeket, amiket egy komment formájában fog posztolni.
+ > 
+ > - Ha nem vagy elégedett az eredménnyyel, akkor további kommitokkal tudod javítani.
+ > - Minden egyes alkalommal, amikor pusholsz a branchre, ismét le fog futni az értékelés. Ha ezt nem szeretnéd, állítsd a pull requestet `Draft`-ra.
+ > 
+ > - Ha elégedett vagy a végeredménnyel, és szeretnéd ismét lefuttatni az ellenőrzőt, állítsd a pull request állapotát vissza.
+ > 
+ > - **Maximum 5 alkalommal** futtathatod a kiértékelést, utána nem fogadjuk el a beadott megoldást. Az értékelések számát az **Actions** fülön lehet legkönnyebben leolvasni. Itt azok a futtatások számítanak, amik ténylegesen lefutottak és a státuszuk nem `Skipped`.
+ > 
+
+
+1. Ellenőrizzük a pull request tartalmát.
+
+ - A **Converstaion** fülön látjuk az automatikus kiértékelő futásának eredményét és később a laborvezető visszajelzését.
+ - A **Commits** fülön látjuk a saját kommitjainkat. Abban az esetben, ha a git kliensünk rosszul van konfigurálva, itt a saját nevünk helyett akár másét is láthatjuk.
+ - A **Checks** fülön az auatomatikus kiértékelésekről kaphatunk több információt.
+ - A **Files changed** fülön a változtatásokat látjuk, ami alapján a laborvezető értékelni fogja a munkánkat. Ha itt nem látsz mindent módosítást, akkor valami elrontottál.
+
+1. További munka hozzáadása.
+
+ - Abban az esetben ha valamilyen hibát tapasztaltál, vagy nem vagy elégedett a végeredménnyel, akkor további módosításokat tudsz még hozzáadni.
+ - Nem szükséges a pull request törlése, vagy lezárása!
+ - További kommitok hozzáadása és pusholása után a változtatások automatikusan megjelennek a pull requestben.
+ - Figyelj rá, hogy minden pusholáskor le fog futni a kiértékelés ha nem állítod a pull requestet piszkozat állapotúra.
+
+1. Végül ha mindennel elégedett vagy, rendeljük hozzá a pull requestet a laborvezetőhöz.
+
+ - A beadás akkor véglegesedik, ha a laborvezető hozzá van rendelve.
+ - A reviewers fülön válasszuk ki a megfelelő laborvezetőt.
+ 
+
+1. Bizonyosodjunk meg róla, hogy a pull request állapota `Open`.
+
+ - Ha minden rendben van, akkor készen vagyunk.
+
+ 
+
+## Abban az esetben, ha a laborvezető további módosításokat kér
+
+Előfordulhat olyan eset, hogy a laborvezető csak feltételekkel fogadja el a megoldást és további módosításokat kér. Erről email-ben kapunk értesítést, vagy a **Conversation** fülön is láthatjuk.
+
+
+
+Ebben az esetben ugyanúgy kell eljárni, mint a korábbi lépéseknél:
+
+- Nem szükséges a pull request törlése, vagy lezárása!
+- További kommitok hozzáadása és pusholása után a változtatások automatikusan megjelennek a pull requestben.
+- Figyeljünk az automatikus ellenőrzésre!
+
+Ha készen vagyunk, és elégedettek vagyunk az eredménnyel, menjünk a `Re-request review` gombra, amivel értesítjük a laborvezetőt.
+
+
+
+## Értékelés utáni kérdés vagy reklamáció
+
+Ha a feladatok értékelésével vagy az eredménnyel kapcsolatban kérdésed van, használd a pull request kommentelési lehetőségét erre. Annak érdekében, hogy a laborvezető biztosan értesüljön a kérdésedről, használd a `@név` megemlítési funkciót a **laborvezető** megnevezéséhez. Erről automatikusan kapni fog egy email értesítést.
+
+
+
+> **Reklamáció csak indoklással**:
+> Ha nem értesz egyet az értékeléssel, a bizonyítás téged terhel, azaz alá kell támasztanod a reklamációt (pl. annak leírásával, hogyan tesztelted a megoldást, és mi bizonyítja a helyességét).
+
+## Mit lehet tenni, ha valamit elrontottál
+
+És végül még egy fontos dolog: mi van, ha valamit elrontassz a folyamatban?
+
+ - Ha még nem hoztad létre a pull requestet, akkor senki nem is látta, hogy valami félre ment, kezd nyugodtan újra az egészet, akár onnan is, hogy egy új branchre még egyszer feltöltöd a labor megoldásodat. (Lehet, hogy ott marad akkor egy régi, fel nem használt branch, de az senkit nem zavar.)
+
+- Ha már létrehoztad a pull requestet, de még nem jött el a leadási határidő, így a laborvezetőd nemigen látta, nyugodtan zárd le (esetleg írd oda kommentárba vagy az elején lévő szövegbe, hogy ez nem a végleges és ne vegyük figyelembe).
+
+- Ha a forráskód szinten maradt le valami, esetleg valamit utólag javítassz, akkor ha a pull request ágára (a fenti példában a “labor” ágra) kommitolsz a pull request létrehozása után, a módosítás automatikusan bekerül a pull requestbe is. Igaz, a laborvezetőd látni fogja az időbeli különbséget, így a határidő utáni módosítást is észre fogja venni, de a határidő előtt nyugodtan utólag is “hozzá lehet még csapni” pár módosítást, ahhoz nem is kell új pull requestet létrehozni.
+
+- És ami még egy kavarodási forrás: mi van akkor, ha elfelejtettél új branchet létrehozni és a masterre kommitoltad a megoldást? Általános szabály, hogy a pull request két ág különbsége. Vagyis ilyen esetben létre hozhatsz egy új branchet a labor megoldása előtti kommitra (ahova eredetileg a masternek kellett volna mutatnia), és a pull requestben akkor megfordulnak a szerepek: a master lesz a megoldást tartalmazó és ez az új ág a “base”, vagyis a kiindulási alap. Gondolj arra, hogy a kommitok gráfja a lényeg és az ágak csak egy-egy kommitra mutatnak. Új ágakkal bármikor bárhova mutathatsz, bármelyiket bárhova áthelyezheted (reset művelet). Kommitot elveszíteni igencsak nehéz, az ágakat meg át lehet helyezni, így elég nagy kavarodásokat is viszonylag könnyen rendbe lehet rakni. Ami fontos, hogy mindig a kommit gráfot nézd és abban gondolkodj!
+
+- Előfordulhat olyan is, hogy a masterre kommitoltál és nem tudsz pusholni. Ez azért van, mert egyes beállításoktól függően lehet, hogy a master védett, és nem enged közvetlenül pusholni. Ez egy jó indikátor arra, hogy valamit elrontottál. Ilyenkor több lehetőséged is van.
+ - Létrehozol egy új branchet az utolsó commithoz és azt az új branchet pusholod. Ilyenkor a masteren lévő extra kommitok nem zavarnak be, mivel az csak a saját gépeden léteznek. Ha zavar akkor akár egy git resettel ezeket törölheted is (de csak óvatosan, mivel ezzel a művelettel akár commitokat örökre elveszíthetsz!).
+ - Másik lehetőség, ha nem tudsz új branchet létrehozni (mivel például már adott egy másik amin dolgoznod kéne), akkor egyszerűen állj át arra a branchre amin dolgoznod kéne, majd pedig az egyes commitokat másold át a cherry-pick funkcióval (Jobb klikk a commitra, majd `Cherry-pick this commit` majd `OK`).
+
+
+- Ha megakadsz, kérj segítséget bizalommal!
+
+## Hozzájárulás
+
+Valami kimaradt ebből a leírásból, vagy valami nem elég egyértelmű? Szívesen veszünk minden javítást. A [Mi a Snippet](/snippets/snippets/0000_MiASnippet/) cikkben részletesen leírást találhatsz arról, te hogyan tudsz ehhez az anyaghoz hozzájárulni.
+
+Szerzők, verziók: Knyihár Gábor
diff --git a/snippets/0114_VerziokezelokOsszehasonlitasa/index.md b/snippets/0114_VerziokezelokOsszehasonlitasa/index.md
index 617a90e..a01f808 100644
--- a/snippets/0114_VerziokezelokOsszehasonlitasa/index.md
+++ b/snippets/0114_VerziokezelokOsszehasonlitasa/index.md
@@ -42,7 +42,7 @@ A verziókezelők világában gyakori fogalmak az alábbiak:
## Verziókezelők összehasonlítása
-A verziókezelők összehasonlításával kapcsolatban most elsősorban az eloszott és a centralizált verziókövetők két neves képviselőjét, a Git-et és a Team Foundation Servert fogom röviden összehasonlítani, mivel ennek a két kategóriának a többi képviselője alapvetően nagyon hasonlóan működik.
+A verziókezelők összehasonlításával kapcsolatban most elsősorban az elosztott és a centralizált verziókövetők két neves képviselőjét, a Git-et és a Team Foundation Servert fogom röviden összehasonlítani, mivel ennek a két kategóriának a többi képviselője alapvetően nagyon hasonlóan működik.
* CVS: egy egyetemi projektben készült az első verzió, amikor egy professzor közösen akart fejleszteni két hallgatójával és eltérő volt az időbeosztásuk. 1986, minden verziókezelő atyja, máig lehet vele találkozni.
* SVN: A CVS utódja, nagyon elterjedt (de a GIT egyre inkább kiszorítja). Nagyon sok cégnél lehet vele találkozni, ahol centralizált verziókezelőt szerettek volna és nem akartak Microsoft technológiára építeni.
@@ -53,7 +53,7 @@ A verziókezelők összehasonlításával kapcsolatban most elsősorban az elosz
A számos másik snippetben bemutatott Git-hez képest a TFS fő eltérései az alábbiak:
* Centralizált verziókövető, így a munkához alapvetően online kapcsolat kell a szerverrel.
- * Sokkal inkább a lináris (branch mentes) fejlesztést helyezi előtérbe: elágazások és mergelések helyett mindenki ugyanazon ágon dolgozik és gyakran checkin-el (a git-es commit megfelelője).
+ * Sokkal inkább a lineáris (branch mentes) fejlesztést helyezi előtérbe: elágazások és mergelések helyett mindenki ugyanazon az ágon dolgozik és gyakran checkin-el (a git-es commit megfelelője).
* Amennyiben fejlesztők egymás között olyan kódrészletet akarnak megosztani, ami még nem alkalmas arra, hogy a főágba bekerüljön, a shelving segítségével "kirakhatják egy polcra" a változásokat, amiket egy másik fejlesztő levehet. (Git alatt ilyenkor a két fejlesztő nyitna erre a célra egy branchet.)
* A központi szerver lehetővé teszi fájlok zárolását, ami megakadályozza, hogy két fejlesztő egyszerre nyúljon egy fájl tartalmához. Ennek van egy árnyaltabb változata is, amit a Visual Studio automatikusan is megtesz: a szerkesztett fájlokat checkout-olja, ami azt jelenti, hogy a fájlt megjelöli szerkesztésre. Ezek a megoldások nagyban hozzájárulnak ahhoz, hogy ritkán legyen merge conflict. Jóval ritkábban, mint például Git esetében.
* A TFS kiterjedt integrációs lehetőségei például lehetővé teszik a gated checkint, ami azt jelenti, hogy amíg a unit tesztek nem futnak le sikeresen, addig nem lehet a módosításokat checkinelni. Ez nagy segítség a programozási hibák ellen, viszont túlságosan macerássá is teheti a fejlesztést.
diff --git a/snippets/0115_GitPullRequest/image/01_start.png b/snippets/0115_GitPullRequest/image/01_start.png
new file mode 100644
index 0000000..3aeabab
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/01_start.png differ
diff --git a/snippets/0115_GitPullRequest/image/02_MkBranch.png b/snippets/0115_GitPullRequest/image/02_MkBranch.png
new file mode 100644
index 0000000..101a32c
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/02_MkBranch.png differ
diff --git a/snippets/0115_GitPullRequest/image/03_OnNewBranch.png b/snippets/0115_GitPullRequest/image/03_OnNewBranch.png
new file mode 100644
index 0000000..fac3167
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/03_OnNewBranch.png differ
diff --git a/snippets/0115_GitPullRequest/image/04_InSocketLabDir.png b/snippets/0115_GitPullRequest/image/04_InSocketLabDir.png
new file mode 100644
index 0000000..c6c04b8
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/04_InSocketLabDir.png differ
diff --git a/snippets/0115_GitPullRequest/image/05_Upload.png b/snippets/0115_GitPullRequest/image/05_Upload.png
new file mode 100644
index 0000000..fb8bd1c
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/05_Upload.png differ
diff --git a/snippets/0115_GitPullRequest/image/06_Commit.png b/snippets/0115_GitPullRequest/image/06_Commit.png
new file mode 100644
index 0000000..d42e38b
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/06_Commit.png differ
diff --git a/snippets/0115_GitPullRequest/image/07_CommitDone_ShortcutToPullRequest.png b/snippets/0115_GitPullRequest/image/07_CommitDone_ShortcutToPullRequest.png
new file mode 100644
index 0000000..6408a54
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/07_CommitDone_ShortcutToPullRequest.png differ
diff --git a/snippets/0115_GitPullRequest/image/08_SeeCommittedFile.png b/snippets/0115_GitPullRequest/image/08_SeeCommittedFile.png
new file mode 100644
index 0000000..5c9a4fa
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/08_SeeCommittedFile.png differ
diff --git a/snippets/0115_GitPullRequest/image/09_PullRequests.png b/snippets/0115_GitPullRequest/image/09_PullRequests.png
new file mode 100644
index 0000000..c5a6983
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/09_PullRequests.png differ
diff --git a/snippets/0115_GitPullRequest/image/10_Compare.png b/snippets/0115_GitPullRequest/image/10_Compare.png
new file mode 100644
index 0000000..34ee2fa
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/10_Compare.png differ
diff --git a/snippets/0115_GitPullRequest/image/11_SeeDiff.png b/snippets/0115_GitPullRequest/image/11_SeeDiff.png
new file mode 100644
index 0000000..91cfb59
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/11_SeeDiff.png differ
diff --git a/snippets/0115_GitPullRequest/image/12_SettingUpPullRequest.png b/snippets/0115_GitPullRequest/image/12_SettingUpPullRequest.png
new file mode 100644
index 0000000..df3af26
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/12_SettingUpPullRequest.png differ
diff --git a/snippets/0115_GitPullRequest/image/13_CreatingPullRequest.png b/snippets/0115_GitPullRequest/image/13_CreatingPullRequest.png
new file mode 100644
index 0000000..851be55
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/13_CreatingPullRequest.png differ
diff --git a/snippets/0115_GitPullRequest/image/14_PullRequestReady.png b/snippets/0115_GitPullRequest/image/14_PullRequestReady.png
new file mode 100644
index 0000000..7a9e037
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/14_PullRequestReady.png differ
diff --git a/snippets/0115_GitPullRequest/image/15_CheckingFilesChanged.png b/snippets/0115_GitPullRequest/image/15_CheckingFilesChanged.png
new file mode 100644
index 0000000..0996895
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/15_CheckingFilesChanged.png differ
diff --git a/snippets/0115_GitPullRequest/image/16_PullRequestConversation.png b/snippets/0115_GitPullRequest/image/16_PullRequestConversation.png
new file mode 100644
index 0000000..a02d1bd
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/16_PullRequestConversation.png differ
diff --git a/snippets/0115_GitPullRequest/image/17_PullRequestConversation_DoNotMergeOrClose.png b/snippets/0115_GitPullRequest/image/17_PullRequestConversation_DoNotMergeOrClose.png
new file mode 100644
index 0000000..c0b6e31
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/17_PullRequestConversation_DoNotMergeOrClose.png differ
diff --git a/snippets/0115_GitPullRequest/image/18_ListOfPullRequests.png b/snippets/0115_GitPullRequest/image/18_ListOfPullRequests.png
new file mode 100644
index 0000000..ddcffc5
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/18_ListOfPullRequests.png differ
diff --git a/snippets/0115_GitPullRequest/image/20_GithubSettings.png b/snippets/0115_GitPullRequest/image/20_GithubSettings.png
new file mode 100644
index 0000000..cb0fdc0
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/20_GithubSettings.png differ
diff --git a/snippets/0115_GitPullRequest/image/21_Tokens.png b/snippets/0115_GitPullRequest/image/21_Tokens.png
new file mode 100644
index 0000000..fe74e48
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/21_Tokens.png differ
diff --git a/snippets/0115_GitPullRequest/image/22_GenerateToken.png b/snippets/0115_GitPullRequest/image/22_GenerateToken.png
new file mode 100644
index 0000000..c4aca41
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/22_GenerateToken.png differ
diff --git a/snippets/0115_GitPullRequest/image/23_NewTokenSettings.png b/snippets/0115_GitPullRequest/image/23_NewTokenSettings.png
new file mode 100644
index 0000000..f8114b2
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/23_NewTokenSettings.png differ
diff --git a/snippets/0115_GitPullRequest/image/24_TokenReady.png b/snippets/0115_GitPullRequest/image/24_TokenReady.png
new file mode 100644
index 0000000..a821239
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/24_TokenReady.png differ
diff --git a/snippets/0115_GitPullRequest/image/25_RepoHttpsUrl.png b/snippets/0115_GitPullRequest/image/25_RepoHttpsUrl.png
new file mode 100644
index 0000000..f6122c3
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/25_RepoHttpsUrl.png differ
diff --git a/snippets/0115_GitPullRequest/image/26_Clone.png b/snippets/0115_GitPullRequest/image/26_Clone.png
new file mode 100644
index 0000000..2d4aa58
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/26_Clone.png differ
diff --git a/snippets/0115_GitPullRequest/image/27_GitExtSetToken.png b/snippets/0115_GitPullRequest/image/27_GitExtSetToken.png
new file mode 100644
index 0000000..01fbbae
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/27_GitExtSetToken.png differ
diff --git a/snippets/0115_GitPullRequest/image/28_CreateNewBranchHere.png b/snippets/0115_GitPullRequest/image/28_CreateNewBranchHere.png
new file mode 100644
index 0000000..069ae0e
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/28_CreateNewBranchHere.png differ
diff --git a/snippets/0115_GitPullRequest/image/29_NewBranch.png b/snippets/0115_GitPullRequest/image/29_NewBranch.png
new file mode 100644
index 0000000..80484d6
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/29_NewBranch.png differ
diff --git a/snippets/0115_GitPullRequest/image/30_NewBranchInCommitGraph.png b/snippets/0115_GitPullRequest/image/30_NewBranchInCommitGraph.png
new file mode 100644
index 0000000..4f65d6b
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/30_NewBranchInCommitGraph.png differ
diff --git a/snippets/0115_GitPullRequest/image/31_CommitNewWork.png b/snippets/0115_GitPullRequest/image/31_CommitNewWork.png
new file mode 100644
index 0000000..fc68e88
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/31_CommitNewWork.png differ
diff --git a/snippets/0115_GitPullRequest/image/32_Push.png b/snippets/0115_GitPullRequest/image/32_Push.png
new file mode 100644
index 0000000..9ef0dba
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/32_Push.png differ
diff --git a/snippets/0115_GitPullRequest/image/32_PushResult.png b/snippets/0115_GitPullRequest/image/32_PushResult.png
new file mode 100644
index 0000000..b7e534c
Binary files /dev/null and b/snippets/0115_GitPullRequest/image/32_PushResult.png differ
diff --git a/snippets/0115_GitPullRequest/index.md b/snippets/0115_GitPullRequest/index.md
new file mode 100644
index 0000000..ecdc23f
--- /dev/null
+++ b/snippets/0115_GitPullRequest/index.md
@@ -0,0 +1,182 @@
+---
+layout: default
+codename: GitPullReq
+title: Git pull request
+tags: git
+authors: Csorba Kristóf
+---
+
+# Git pull request
+
+Ebben a snippetben arra látunk egy példát, hogy egy órarendi laboron elkészített forráskódot hogyan lehet csak a github.com felületét használva bejuttatni a github repositorynkba, majd a leadáshoz hogyan lehet egy pull requestet létrehozni, melyben a labor megoldása szerepel.
+
+A példát az Informatika 2 tantárgyhoz kapcsolódóan írom le, de ez csak annyiban tantárgyfüggő, hogy mi a github organization, amiben a repository létrejött, valamint hogy ezúttal a saját repositoryt a github classroom hozta létre. De egyébként egy olyanolyan repositoryról van szó, mint amit magának tud bárki létrehozni.
+
+A kiindulási alap az, hogy van egy github.com repositorynk, melyben a master ágon állunk és ott még semmilyen nyoma nincsen a labor megoldásnak. Mivel a pull request mindig két ágat tud összehasonlítani, a master ág lesz az, ami a labor elkészítése előtti állapotra mutat. Ehhez képest létre fogunk hozni egy új ágat, arra commitoljuk a labor megoldását (egy vagy több committal, ez jelen esetben mindegy), majd a megoldást tartalmazó, új ágat összehasonlítva a master ággal létrehozzuk a pull requestet, melyhez hozzárendeljük a laborvezetőnket, mint reviewer. (Ettől a megoldásunk a laborvezető számára is meg fog jelenni a megnézendő pull requestek között.)
+
+A következőkben két forgatókönyvet is be fogok mutatni. Az elsőben csak a github felületét használjuk, ami nem a szokványos munkafolyamat, de a laborok esetén gyors és egyszerű. A második a preferált eset, amikor a saját gépünkre készítünk egy másolatot a repositoryról, abba dolgozunk, majd a változásokat visszajuttatjuk a szerverre. A pull request létrehozása már mindkét esetben azonos lesz.
+
+# A labor megoldások commitolása egy új branchre - csak a github felületet használva
+
+A kiindulási állapotunk, amikor a saját repositorynkat megnyitjuk a github.com oldalon a következő. Látszik, hogy a BME-VIK-Informatika2 organization alatt található és az aktuális ág (branch) a master:
+
+
+
+Fontos, hogy a labor megoldását új branchen hozzuk létre, mert a master lesz az összehasonlítás alapja, vagyis a masteren nem szabad nyoma lennie a labor megoldásának. Új branchet úgy hozunk létre, hogy legördítjük a branch listát és a szövegmezőbe beírjuk az új branch nevét (most "Lab01Megoldas") és rákattintunk alatta a létrehozás gombra:
+
+
+
+Az új branchen állva (már ez van kiválasztva a legördülő listában) belépünk a labor megoldását váró könyvtárba, hogy oda fel tudjuk majd tölteni a fájlokat:
+
+
+
+Itt miután még egyszer ellenőriztük, hogy a "Lab01Megoldas" ágon és nem a masteren vagyunk, az "Add file" legördülő listában az "Upload files" lehetőséget választjuk:
+
+
+
+Ennek a labornak a megoldása során speciel egy main.cpp fájlt készítettünk el, amit a nagy feltöltő mezőbe dobva tudunk feltölteni. Általános esetben minden a megoldáshoz kapcsolódó fájlt ide kell bedobnunk, amitől azok feltöltődnek és alul megjelennek:
+
+
+
+A git commit létrehozásához ezután meg kell adnunk egy commit üzenetet, amit illik valami kifejezőre választani, mint például a "Lab01 megoldása". Itt a github lehetőséget adna arra is, hogy most, egyetlen lépésben létrehozzunk egy új ágat, commitoljuk rá és már indítsuk is a pull request készítést. Ezt is nyugodtan választhatjátok, de most a lépésenkénti megoldást fogom megmutatni, ahol csak a "Commit directly to the Lab01Megoldas branch." opciót választjuk, majd megnyomjuk a "Commit changes" gombot:
+
+
+
+Itt most visszajutunk a repository kód nézetére, továbbra is a Lab01Megoldas ágon állva. Fent megjelenik egy "Compare & pull request" gomb, amivel egyből ugorhatunk a pull request létrehozásra. Nyugodtan használhatjátok azt is, de most megint csak a lassabb, de részletesebb utat mutatom meg. Lépjünk még be a megoldás alkönyvtárába (LAB01_socket), hogy megnézzük a feltöltött fájlt:
+
+
+
+Itt ismét meggyőződhetünk róla, hogy a Lab01Megoldas ágon a LAB01_socket könyvtárban már ott van feltöltve a megoldás. (Érdemes lehet arra is ránézni, hogy ha átmegyünk a master ágra, akkor a main.cpp el fog tűnni, mivel a master ágon a megoldásnak még nyoma sincs.) Ezután fent menjünk át a "Pull requests" oldalra, ahol most fogjuk létrehozni a pull requestet, vagyis beadjuk a már egy külön ágra feltöltött megoldást.
+
+
+
+Itt érdemes megjegyezni, hogy ha egy desktop git klienst használunk és a saját gépünkön dolgozva a lokális repositoryba commitolunk egy új Lab01Megoldas ágra, majd azt pusholjuk a github.com remote-ra, akkor pont ide jutunk. A fenti példa azt mutatta meg, hogy lokális repository és telepített git és git kliens nélkül is el tudunk ide jutni.
+
+# Klasszikus git munkafolyamat: repository klónozása és a helyi repositoryba dolgozás
+
+A klasszikus megközelítés szerint a github repositoryt klónozzuk (másolatot hozunk létre a saját gépünkre), abba dolgozunk és végül "pusholjuk" a változásokat (fájl módosítások, új branchek) a szerverre.
+
+Ehhez a saját gépünkön vagy parancssorból használjuk a git-et, vagy egy kliensen keresztül, mint a GitExtensions (van egy csomó ilyen és valójában mindegyik csak helyettünk adja ki a parancssori git parancsokat, így sokszor szinte csak a designban térnek el.)
+
+Az első lépés a klónozás, amihez a github felé authentikálni is kell magunkat. A github pár éve megszüntette azt a lehetőséget, hogy a webes felületen használható usernév - jelszó párossal a git kliensünk is be tudjon lépni. Ehhez personal access tokent kell létrehozni, ami egyfajta programok számára készíthető jelszó. A github felületén lehet generálni őket megadva, hogy segítségével mikhez férhet hozzá a program.
+
+## Github personal access token generálása
+
+A github.com oldalra belépve a beállításaink között a bal oldali menü alján található egy Developer Settings:
+
+
+
+Azon belül pedig most a "Personal Access Tokens - Tokens (classic)" rész kell nekünk. Itt vannak az eddig generált tokenjeink. A "Generate new token"-re kattintva generálhatunk egy újat, például minden labor elején, mert a labor gépeken jobb nem elmenteni a korábbiakat. Ha saját gépet használunk, ahhoz nem kell mindig újat létrehozni.
+
+
+Új token generálása:
+
+
+Az új tokennek kell adni egy nevet, amiről tudjuk azonosítani, ha több van. Meg kell adni egy lejárati időt, valamint hogy milyen jogokat biztosítson. Nekünk most a "repo" jog kell majd. Ezután a lista alján lévő nyomógombbal tudjuk legeneráltatni a tokent.
+
+
+
+A kész tokent itt kimásolhatjuk a vágólapra. Tegyük is meg, mert ahogy a github is figyelmeztet, többet ez nem fog megjelenni.
+
+
+
+Ha kész a token, ezt használhatjuk az alkalmazásokban jelszónak. Vagyis ha egy bármilyen git kliens felhasználó nevet és jelszót kér, a felhasználói név a githubos usernevünk, a jelszó pedig ez a token!
+
+## A repository klónozása, munka új branchen
+
+Ezután ha a GitExtensions kliens programot használjuk, két lehetőségünk van az authentikációra: vagy klónozzuk a repositoryt és ha majd a git kéri a felhasználó nevet és jelszót, akkor a jelszónál a fent generált access tokent kell megadni. Vagy ha saját gépen dolgozunk, akkor el is menthetjük az access tokent a "Tools - Settings" menüpont "Plugins - GitHub" részében. A Personal Access Tokent egyszerűen másoljuk a szövegmezőbe és nyomjunk "Apply"-t vagy "OK"-ot. Ekkor később a git már nem fog jelszót kérdezni.
+
+
+
+A klónozáshoz kelleni fog a repository elérési útja, amit a github oldalon a repository kezdőoldalán tudunk megnézni a zöld "Code" nyomógombbal (vagy a github classroom is elárulja, amikor végez a repository létrehozásával):
+
+
+
+A GitExtensions alkalmazás kezdő képernyőjén vagy a program "Start" menüpontján belül "Clone repository"-t választva meg kell adni a repository URL-t és a célkönyvtárat (innen nyílik majd a repository nevével megegyező nevű alkönyvtár):
+
+
+
+A klónozás után a repositoryban elvégezhetjük a labor feladatokat. Mivel más snippetekben ( [Git példafejlesztés](http://bmeaut.github.io/snippets/snippets/0103_GitPeldafejlesztes/) ) ez részletesen le van írva, itt most csak a labor szempontjából legfontosabb pontokat emelem ki.
+
+Első lépésként fontos, hogy létrehozzunk egy új branchet, a master ágon állva jobb gombbal az aktuális commitra kattintva és a "Create new branch here" menüpontot választva:
+
+
+
+A neve például lehet "labor".
+
+
+
+Amikor létrehoztuk, már ez lesz az aktuális branch (a neve előtt kis háromszög jelzi). Ide dolgozunk a labor során:
+
+
+
+Ha a labor feladatokkal végeztünk és commitolni akarjuk, a GitExtensionsben fent középen van egy "Commit" nyomógomb. Ezt megnyomva látjuk a változásokat. Mivel nem feltétlenül akarjuk az összes változást belevenni a létrehozandó commitba, "stagelni" kell azt, amit bele akarunk venni. Ettől azok a változások átkerülnek a bal alsó mezőbe. Ezután egy beszédes commit message megadása után rányomhatunk a "Commit" gombra. (Később látni fogjátok, hogy érdemes minél sűrűbben commitolni, nem csak a legvégén, de ez most még nem elvárás.)
+
+
+
+Az új branch és az új commit(ok) még nincsennek fent a github oldalán, így a pull requestet még nem tudjuk létrehozni. Először fel kell tölteni a változásokat a szerver oldalra is. Git alatt erre a "push" művelet szolgál. (A commit dialógus ablakban a "Commit" helyett nyomhatjuk egyből a "Commit & push"-t is, akkor a push is lefut egyből.) A push ikonja egy kis felfelé nyíl fent középen. A felugró dialógus ablakban semmit nem kell módosítani, az "origin" néven futó, eredeti github repositoryba akarjuk felpusholni a változásokat.
+
+
+
+Itt jön majd két kérdés, hogy az új branchet a távoli repositoryban is létre akarjuk-e hozni és az kövesse-e az itteni megfelelőjét, mindkettőre igen a válasz. Ezután a commit gráfban már megjelenik, hogy a "labor" águnk szinkronban van az "origin/labor" ággal, ami a github oldalán lévő megfelelője:
+
+
+
+Ezzel a labor megoldásunk felkerült a github szerverére is és készen áll a beadásra, amit egy pull request formájában fogunk összeállítani a github.com oldalon. A pull request majd két branch különbségét fogja nekünk "összecsomagolni". A két branch itt most a master (ami ebben a példában a labor elkezdése előtti állapotra mutat), a másik pedig az, amire most a labor alatt commitoltunk (ennek "labor" a neve a példában). Így a pull request tartalma pont a laboron végzett munka lesz.
+
+# A pull request létrehozása
+
+A repositorynk pull requests oldalán a példában még nincsen nyitott pull request, csak 3 lezárt. Mivel nemrég commitoltunk egy ágra, a github ismét felajánlja, hogy egyből használjuk azt a pull requesthez. De didaktikai okból megint azt az utat választjuk, ami mindig működik: válasszuk a "New pull request" gombot.
+
+
+
+Most kell megadnunk, hogy melyik ágat melyik ággal fogjuk összehasonlítani. A base a kiindulási alap, vagyis marad a master, a compare-t pedig át kell állítanunk a megoldásunkat tartalmazóra, vagyis a labor ágra (ha a csak githubos felületet használó utat választottuk, ott "Lab01Megoldas" néven futott):
+
+
+
+A beállítás után egyből láthatjuk a leendő pull request tartalmát, vagyis hogy milyen módosításokat hajtottunk végre a forráskódban a megoldás során. (Itt most csak egy fájl jelenik meg, melynek minden sora új sor, de ha például kiadott keretprogrammal dolgoznánk, itt pirossal megjelenő, törölt sorok is előfordulhatnának.) Itt győződhetünk meg róla, hogy a pull requestben a labor teljes megoldása benne van és felesleges fájlok pedig nincsennek benne. (Ha több commitban van a megoldás, akkor fontos, hogy itt már minden commit tartalma együtt látszik, vagyis minden módosításnak szerepelnie kell benne, mert a laborvezető is pontosan ezeket a változásokat fogja látni.) Ha minden rendben van, nyomjuk meg a "Create pull request" gombot:
+
+
+
+A pull requestnek van egy szöveges üzenet része, amiben alapértelmezés szerint egy sablon szöveg jelenik meg. Itt gyakran egy ellenőrzési listát is elhelyezünk azért, hogy a feladat beadásoknál semmi fontos ne maradjon ki. Ezeket érdemes minden alkalommal végigfutni, hogy helyes pull requestet adjatok le. Közben ide nyugodtan lehet írni bármi egyebet is, ha van valami megjegyzésetek a megoldásotokhoz. Egyes laborokon ide szoktunk screenshotot kérni a futó eredményről, ebbe az oldalba simán lehet copy-pastelni képeket is.)
+
+A szöveges rész kitöltése mellett ekkor lehet reviewert, jelen esetben laborvezetőt hozzárendelni a pull requesthez. Ez azért fontos, mert ettől fog a laborvezetőtöknél megjelenni a labor beadásotok, így szerez majd róla tudomást. A reviewer listát a kis fogaskerék ikonnal tudjátok lenyitni és ellenőrizzétek, hogy a saját laborvezetőtök userneve előtt megjelenik a kis pipa, amikor kiválasztjátok:
+
+
+
+A labvezér beállítása után egy utolsó ellenőrzés, és mehet is a "Create pull request":
+
+
+
+
+
+Ilyenkor még érdemes egy pillantást vetni a pull request "Files changed" oldalára, melyen ismét ellenőrizhetitek, hogy pontosan azok a változások kerültek bele, amiket akartatok.
+
+
+
+A pull request "Conversation" oldala egyébként a megjegyzésként írt szövegetek után tartalmazza időrendi sorrendben az összes eseményt, ami a pull requesttel történt: a benne lévő commitokat, valamint a reviewer felkérést is.
+
+
+
+Fontos, hogy bár ennek a végén nektek is lehetőségetek van mergelni a pull requestet (jelen esetben a tartalma beleolvadna a master ág tartalmába), vagy csak lezárni a pull requestet, ezt NE tegyétek meg, mivel akkor értelmét veszíti az egész pull request és a laborvezetőtök nem is szerez tudomást a beadott labor megoldásról.
+
+Amint a laborvezetőtök értékelte a megoldásotokat, a forráskódhoz fűzött esetleges kommentárjai, valamint az a tény, hogy elfogadta a pull requestet, szintén itt fog megjelenni.
+
+Itt érdemes megjegyezni, hogy a hagyományos munkafolyamatban a pull request sorsának általában az a vége, hogy mergelődik. Itt ennek nincsen feltétlenül értelme: a laborokon mi csak arra használjuk a pull requestet, hogy jelezze a beadást tényét és könnyen lehessen visszajelzést adni. Ha a megoldás utána marad a "labor" ágon és nem mergelődik a master ágra, az a tantárgyi keretek között nem gond. Ettől függetlenül nyugodtan mergelhetitek, miután a labvezér elfogadta.
+
+
+
+A folyamatban lévő, vagyis nyitott pull requestjeiteket mindig meg tudjátok nézni a repositorytok "Pull requests" oldalán:
+
+
+
+És végül még egy fontos dolog: mi van, ha valamit elrontassz a folyamatban?
+
+ - Ha még nem hoztad létre a pull requestet, akkor senki nem is látta, hogy valami félre ment, kezd nyugodtan újra az egészet, akár onnan is, hogy egy új branchre még egyszer feltöltöd a labor megoldásodat. (Lehet, hogy ott marad akkor egy régi, fel nem használt branch, de az senkit nem zavar.)
+ - Ha már létrehoztad a pull requestet, de még nem jött el a leadási határidő, így a laborvezetőd nemigen látta, nyugodtan zárd le (esetleg írd oda kommentárba vagy az elején lévő szövegbe, hogy ez nem a végleges és ne vegyük figyelembe).
+ - Ha a forráskód szinten maradt le valami, esetleg valamit utólag javítassz, akkor ha a pull request ágára (a fenti példában a "labor" ágra) commitolsz a pull request létrehozása után, a módosítás automatikusan bekerül a pull requestbe is. Igaz, a laborvezetőd látni fogja az időbeli különbséget, így a határidő utáni módosítást is észre fogja venni, de a határidő előtt nyugodtan utólag is "hozzá lehet még csapni" pár módosítást, ahhoz nem is kell új pull requestet létrehozni.
+ - Ha a leadási határidő után javítanál valamit, inkább szólj a labvezérednek, hogy készítenél egy új pull requestet, hogy ne legyen kavarodás.
+
+ És ami még egy kavarodási forrás: mi van akkor, ha elfelejtettél új branchet létrehozni és a masterre commitoltad a megoldást? Általános szabály, hogy a pull request két ág különbsége. Vagyis ilyen esetben létre hozhatsz egy új branchet a labor megoldása előtti commitra (ahova eredetileg a masternek kellett volna mutatnia), és a pull requestben akkor megfordulnak a szerepek: a master lesz a megoldást tartalmazó és ez az új ág a "base", vagyis a kiindulási alap. Gondolj arra, hogy a commitok gráfja a lényeg és az ágak csak egy-egy commitra mutatnak. Új ágakkal bármikor bárhova mutathatsz, bármelyiket bárhova áthelyezheted (reset művelet). Commitot elveszíteni igencsak nehéz, az ágakat meg át lehet helyezni, így elég nagy kavarodásokat is viszonylag könnyen rendbe lehet rakni. Ami fontos, hogy mindig a commit gráfot nézd és abban gondolkodj! (Ha pedig megakadsz, kérj segítséget, praktikusan egy commit gráf screenshottal kezdve.)
+
+Szerzők, verziók: Csorba Kristóf
diff --git a/snippets/0128_GitHalado/index.md b/snippets/0128_GitHalado/index.md
index af6ab82..2332be1 100644
--- a/snippets/0128_GitHalado/index.md
+++ b/snippets/0128_GitHalado/index.md
@@ -128,7 +128,7 @@ Ekkor Bazalt még utoljára ellenőrzi, hogy tényleg minden szépen fut-e. Sajn
assert(0);
break;
-Még jó, hogy ellenőrizte. A merge még sem volt olyan zökkenőmentes. Semmi gond, gyors javítás, utána pedig commit. Jobban belegondolva ez a merge része kellett volna, hogy legyen. Mivel a merge commitot még nem pusholta, éppen módosíthatja is. Erre való az "amend commit": a mostani commitot beleolvasztja az előzőbe. Tipikusan akkor használjuk, ha valami lemaradt:
+Még jó, hogy ellenőrizte. A merge mégsem volt olyan zökkenőmentes. Semmi gond, gyors javítás, utána pedig commit. Jobban belegondolva ez a merge része kellett volna, hogy legyen. Mivel a merge commitot még nem pusholta, éppen módosíthatja is. Erre való az "amend commit": a mostani commitot beleolvasztja az előzőbe. Tipikusan akkor használjuk, ha valami lemaradt:

diff --git a/snippets/0129_GitTuzvedelem/index.md b/snippets/0129_GitTuzvedelem/index.md
index 0172102..b17ce36 100644
--- a/snippets/0129_GitTuzvedelem/index.md
+++ b/snippets/0129_GitTuzvedelem/index.md
@@ -34,7 +34,7 @@ Most már csak egy fájl kell, amin lehet kísérletezni. Ez lett a NaivFajl.txt
## Reset current branch
-A következőkben tegyül fel, hogy Andezit kiegészítt a szövegünket egy sorral, és ezt a változtatást utána majd vissza akarja vonni.
+A következőkben tegyül fel, hogy Andezit kiegészíti a szövegünket egy sorral, és ezt a változtatást utána majd vissza akarja vonni.
Ez itt a naív fájl, ami azt hiszi, hogy nyugis helyen van.
Ez meg az a szöveg, aminek a beszúrását majd visszavonjuk.
@@ -103,7 +103,7 @@ Néhány megjegyzés:
## A revert commit (először)
-Ha egy olyan commitot akarunk visszavonni, ami már régebben volt és azóra ráépülek más commitok, akkor nem tudjuk a resettel ilyen könnyen megoldani. Ilyenkor kell a revert commit, vagyis egy olyan commit, ami egy másik "inverze".
+Ha egy olyan commitot akarunk visszavonni, ami már régebben volt, és azóta ráépülnek más commitok, akkor nem tudjuk a resettel ilyen könnyen megoldani. Ilyenkor kell a revert commit, vagyis egy olyan commit, ami egy másik "inverze".
Ezért először Andezit felvesz egy új sort:
@@ -146,7 +146,7 @@ Most lássuk, mit mutat a Commit ablak.

-Látszik, hogy a stagelt változás tényleg szépen visszavonja a törölni kívánt commitot. A commit szövegében pedig benne van, hogy mi történt és mivel volt gond. (Ezt persze nyugodtan átíthatjuk.)
+Látszik, hogy a stagelt változás tényleg szépen visszavonja a törölni kívánt commitot. A commit szövegében pedig benne van, hogy mi történt és mivel volt gond. (Ezt persze nyugodtan átírhatjuk.)
Ami itt még érdekes, az egy "NaivFajl.txt.orig" nevű fájl, ami megjelent. Ennek tartalma:
@@ -191,9 +191,9 @@ Detached head állapotban vagyunk:

-Ha innen commitolunk, akkor az semmilyen formában nem befolyásolja a brancheket, mivel egy új részfát kezdünk el. Ilyesmit leginkább csak akkor szoktunk tenni, ha valamit gyorsan ki akarunk próbáli egy korábbi verzión, bár akkor is szerencsésebb egy branchet létrehozni rá és azt checkout-olni. Erre a lehetőségre hívja fel a figyelmünket az üzenet is: ha meggondolnánk magunkat és amit innen commitolunk, mégis fontos, akkor bármikor létrehozhatunk egy új branchet, ami a mostani helyre fog mutatni.
+Ha innen commitolunk, akkor az semmilyen formában nem befolyásolja a brancheket, mivel egy új részfát kezdünk el. Ilyesmit leginkább csak akkor szoktunk tenni, ha valamit gyorsan ki akarunk próbálni egy korábbi verzión, bár akkor is szerencsésebb egy branchet létrehozni rá és azt checkout-olni. Erre a lehetőségre hívja fel a figyelmünket az üzenet is: ha meggondolnánk magunkat és amit innen commitolunk, mégis fontos, akkor bármikor létrehozhatunk egy új branchet, ami a mostani helyre fog mutatni.
-Csak a teljesség kevéért commitoljunk egyet, hogy megnézzük, milyen az:
+Csak a teljesség kedvéért commitoljunk egyet, hogy megnézzük, milyen az:

@@ -251,7 +251,7 @@ Nézzük meg mindkét verziót:
### A rebaselt ág hátrahagyása
-Áttérve a master ágra és azt fast-forwarddal előrehozva a fromDetachedHead branchre, végül pusholva mastert az alábbi helyzet kapjuk:
+Áttérve a master ágra és azt fast-forwarddal előrehozva a fromDetachedHead branchre, végül pusholva mastert az alábbi helyzetet kapjuk:

diff --git a/snippets/0133_QtQmlDemo/index.md b/snippets/0133_QtQmlDemo/index.md
index 381f9f8..b81a70d 100644
--- a/snippets/0133_QtQmlDemo/index.md
+++ b/snippets/0133_QtQmlDemo/index.md
@@ -214,7 +214,7 @@ Itt példányosítjuk a MainForm elemet. Az "anchors.fill" tulajdonságnak megad
}
}
-Végül létrehozunk még egy MessageDialog objektumot is az ablakon belül, ami egy felugró üzenet ablakot jelent. Adunk neki "id"-t, mert így tudunk rá hivatkozni az eseménykezelőkben. Beállítjuk a title tulajdonságot, valamint definiálunk benne egy JavaScript függvényt. Olyan ez, mintha egy MessageDialog osztályból származtattunk volna egy sajátot, és kiegészítjük egy újabb metódussal. A függvény pedig nem tesz mást, mint a paraméterül kapott szövegre állítja a text tulajdonságot, majd feldobja a dialógus ablakot. (A JavaScript gyengén típusos nyelv, a paraméter típusát nem kell megadni. Lehet bármi, amit a változót használó kódrészek le tudnak majd kezelni.
+Végül létrehozunk még egy MessageDialog objektumot is az ablakon belül, ami egy felugró üzenet ablakot jelent. Adunk neki "id"-t, mert így tudunk rá hivatkozni az eseménykezelőkben. Beállítjuk a title tulajdonságot, valamint definiálunk benne egy JavaScript függvényt. Olyan ez, mintha egy MessageDialog osztályból származtattunk volna egy sajátot, és kiegészítjük egy újabb metódussal. A függvény pedig nem tesz mást, mint a paraméterül kapott szövegre állítja a text tulajdonságot, majd feldobja a dialógus ablakot. (A JavaScript gyengén típusos nyelv, a paraméter típusát nem kell megadni. Lehet bármi, amit a változót használó kódrészek le tudnak majd kezelni.)
}
diff --git a/snippets/0138_GitParancssor/index.md b/snippets/0138_GitParancssor/index.md
index 037bab6..955e918 100644
--- a/snippets/0138_GitParancssor/index.md
+++ b/snippets/0138_GitParancssor/index.md
@@ -8,7 +8,7 @@ authors: Csorba Kristóf
# A Git konzolos használata során gyakran előkerülő parancsok
-Változó, hogy ki mennyire szereti a konzolos megoldásokat. Sokak szerint sokkal gyorsabb, mint kattintgatni. Mivel a Git alapvetően egy parancssoros alkalmazás és a háttérben a grafikus felületei is konzolos parancsokat adnak ki, érdemes összeszedni, mik a leggyakrabban használat parancsok. A leírás feltételezi, hogy a parancsok mögötti koncepciókkal és a működésükkel már tisztában van az Olvasó.
+Változó, hogy ki mennyire szereti a konzolos megoldásokat. Sokak szerint sokkal gyorsabb, mint kattintgatni. Mivel a Git alapvetően egy parancssoros alkalmazás, és a háttérben a grafikus felületei is konzolos parancsokat adnak ki, érdemes összeszedni, mik a leggyakrabban használt parancsok. A leírás feltételezi, hogy a parancsok mögötti koncepciókkal és a működésükkel már tisztában van az Olvasó.
Bármely git parancsról kaphatunk segítséget a ``--help`` opcióval. Pl.
@@ -182,6 +182,6 @@ A kdiff3 beállítása mergetoolnak (ebben a példában Windows alatt):
* [Git dokumentáció](http://git-scm.com/docs/)
* A legtöbb git parancs a --help opció hatására megmutatja a saját dokumentációját. (Pl. ``git status --help``)
* Googlelel rákeresve a git parancsokra (pl. git init) általában első helyen az online dokumentációt kapjuk, ami igen részletes és hasznos.
- * Számos "Git Cheat Sheet" található a weben, melyek tömören összefoglalják a legfontosabb parancsokat. [GitHub Training Cheat Sheet](https://training.github.com/kit/)
+ * Számos "Git Cheat Sheet" található a weben, melyek tömören összefoglalják a legfontosabb parancsokat. [GitHub Training Cheat Sheet](https://education.github.com/git-cheat-sheet-education.pdf)
Szerzők, verziók: Csorba Kristóf
diff --git a/snippets/0200_DesignPatternsBev/index.md b/snippets/0200_DesignPatternsBev/index.md
index 799dfb9..6d34bc3 100644
--- a/snippets/0200_DesignPatternsBev/index.md
+++ b/snippets/0200_DesignPatternsBev/index.md
@@ -21,6 +21,8 @@ Amennyiben egy olyan kis programot készítünk, amit csak egyszer fogunk lefutt
Volt már rá példa, hogy egy tanszéki projekt esetében amikor egy új igény felmerült, hamar kiderült, hogy a forráskódban már megvan a helye a megoldásnak, mivel a szükséges interfészek már régen ki vannak alakítva, még ha addig nem is volt rájuk különösebben szükség.
+Egyszer hallottam egy analógiát a programozás és tervezési minták, valamint a sakk között: amikor valaki elkezd sakkozni, először megtanulja, hogy melyik bábú hogyan tud lépni. Programozásban ezek a nyelvi elemek, hogy egyáltalán mit lehet leírni és mit nem. Utána haladgat előre a tanulással és találkozik olyan trükkökkel, mint a sáncolás, vagyis amikor a királlyal nem kell megkerülni egy csomó lépésben a bástyát, hanem egy lépésben is meg lehet ezt tenni. Programozásban ilyen az API-k és osztálykönyvtárak használata: már nem írunk meg mindent nulláról, hanem használjuk, amit mások gondosan elkészítettek. Így gyorsabban és kevesebb hibával haladunk előre. A sakkban ezután előbb-utóbb eljön az a pont, amikor a lelkes gyakorló elkezd egy könyvben nyitáselméletet nézegetni: az ide-oda lépegetés helyett hogyan is kell ezt jól csinálni? A nagy sakkozók tapasztalatai alapján hogyan érdemes elkezdeni egy játékot? Nyilván lehet hirtelen ötletektől vezérelve is, de azért ha kemény ellenféllel állunk szemben és nem vagyunk résen, a hirtelen ötletek nem biztos, hogy a legjobbak lesznek. Programozásban ilyenek a tervezési minták: korábbi sokéves tapasztalatok eredményei, amik persze csak javaslatok és sokszor nem is bitről bitre követjük őket, de azért nem hátrány, ha a fejünkben vannak. (Ha nincsennek a fejünkben, akkor bár igen, rá tudunk guglizni, de a gugli nem fog nekünk munka közben szólni, hogy "Hello, keress rá a Decorator tervezési mintára, mert épp az kell neked!")
+
Tervezési minta nagyon sok van, az alábbi gyűjtemény természetesen messze nem teljes. Ezen kívül az egyes helyzetekben és fejlesztési környezetekben az egyes minták megvalósítása is nagyon eltérhet egymástól: vagy a követelmények eltérései miatt, vagy egyszerűen az adott programnyelv és keretrendszer képességeitől függően. Ezen kívül az alábbi minta halmazok mellett is léteznek bőven további tervezési minta fajták.
Az egyes mintákról részletesen külön snippetek szólnak.
diff --git a/snippets/0201_DpFactory/index.md b/snippets/0201_DpFactory/index.md
index 4b9cdf2..02c099b 100644
--- a/snippets/0201_DpFactory/index.md
+++ b/snippets/0201_DpFactory/index.md
@@ -10,7 +10,7 @@ authors: Csorba Kristóf
A factory method célja, hogy egy ősosztály leszármazottjai közül az egyiknek létrehozzuk egy példányát, de azt máshol döntjük el, hogy melyiket.
-(A factory method mintánál ennél általánosabb Factory tervezési minta egy olyan objektumot takar, ami másik objektum példányokat hoz létre.)
+(A factory method mintánál általánosabb Factory tervezési minta egy olyan objektumot takar, ami másik objektum példányokat hoz létre.)
### Bevezető példa: játékprogram pályaszerkesztője
@@ -30,5 +30,6 @@ Megjegyzések
* Ez a minta akkor hasznos, ha a létrehozás helyén nem akarom eldönteni, hogy pontosan milyen példányt akarok létrehozni. Vagy azért, mert a kliens osztálynak ehhez semmi köze, vagy azért, mert nagyon sok helyen kell példányosítani és macerás mindenhova odarakni a döntési logikát.
* Szintén hasznos a minta akkor, ha a létrehozás nem triviális folyamat (nem csak a konstruktort kell meghívni), mivel akkor a létrehozási folyamat ahelyett, hogy sok helyen előfordulna a forráskódban, bekerül a factory methodba. (Ez egy kicsit hasonlít a Builder mintához.)
* Ez a megoldás kapcsolódik a dependency injection koncepcióhoz is. Annak is az a lényege, hogy kívülről kapjuk azokat az objektumokat (jelen esetben a factoryt), amire később szükségünk lesz. (Ahelyett, hogy helyben be lenne drótozva.)
+ * Sokszor előfordul, hogy egy osztálynak sok konstruktora van, mert sokféle módon létre lehet hozni. És bizony nem mindig triviális, melyik konstruktor mire jó, mivel a nevük ugye egyforma... Ilyen esetekben igen hasznos lehet, ha az osztályt ellátjuk pár statikus factory methoddal, vagyis beszédes nevű metódusokkal, amik egy példányt hoznak létre az osztályból, megfelelően előkészítve. (Ha ilyen metódusokkal úgy érezzük, minden eshetőséget lefedtünk, a konstruktorokat akár privatetá is lehetjük, és akkor biztos, hogy mindenki a beszédes nevű factory methodok közül fog választani. Pl. `field = Field.CreateFieldWithMonster(10,10);`)
Szerzők, verziók: Csorba Kristóf
diff --git a/snippets/0217_DpVisitor/index.md b/snippets/0217_DpVisitor/index.md
index 33dda9b..35211e5 100644
--- a/snippets/0217_DpVisitor/index.md
+++ b/snippets/0217_DpVisitor/index.md
@@ -44,6 +44,6 @@ Ilyenkor lehet készíteni a meglátogatandó elemek tárolója számára egy ol
### További olvasnivaló
-A visitor tervezési mintára konkrét implementációs példa szerepel a [0216_VisitorObserverPelda](../0216_VisitorObserverPelda/0216_VisitorObserverPelda.html) snippetben.
+A visitor tervezési mintára konkrét implementációs példa szerepel a [0216_VisitorObserverPelda](../0216_VisitorObserverPelda/index.html) snippetben.
Szerzők, verziók: Csorba Kristóf
diff --git a/snippets/0218_GlcdTervezesiPelda/index.md b/snippets/0218_GlcdTervezesiPelda/index.md
index c0ed6d3..159ecf1 100644
--- a/snippets/0218_GlcdTervezesiPelda/index.md
+++ b/snippets/0218_GlcdTervezesiPelda/index.md
@@ -53,7 +53,7 @@ Bárki, akinek rendelkezésre áll egy GLCD példány, az tud írni rá. Ennek a
SPI& spi;
};
-Az SPI kommunikációt használó esetben érdemes az SPI kapcsolat részleteit egy másik, újrahasznosítható osztályba kiszervezni, hogy ott már csak át kelljen adni a kontruktorba (dependency injection módszer). Valószínűleg a main() függvény fog majd példányosítani egy SPI objektumot és amikor a grafikus LCD-hez ér, már csak átadja neki.
+Az SPI kommunikációt használó esetben érdemes az SPI kapcsolat részleteit egy másik, újrahasznosítható osztályba kiszervezni, hogy ott már csak át kelljen adni a konstruktorba (dependency injection módszer). Valószínűleg a main() függvény fog majd példányosítani egy SPI objektumot és amikor a grafikus LCD-hez ér, már csak átadja neki.
(Az SPI referenciát nem lenne szerencsés az ősosztályban tárolni, mivel csak néhány leszármazott használja. Az ilyen adatoknak nem ott van a helye, hanem lentebb az osztály hierarchiában. Ha több SPI-os leszármazott lenne, akkor azoknak lehet egy közös ősosztályuk, ami a GLCD-ből származik le és már tartalmazza az SPI-ra a referenciát.)
@@ -61,7 +61,7 @@ A GPIO egy kicsit problémásabb: hogyan is kellene elegánsan megmondani, hogy
Lássuk, hogy állunk a tervezési SOLID elvekkel:
- * Single Responsibility Principle: a GLCD interfésznek és leszármazottjainak csak GLCD kezelés a feladat, semmi más. Az SPI kommunikáció például nem ide tartozik, az ki van szervezve.
+ * Single Responsibility Principle: a GLCD interfésznek és leszármazottjainak csak GLCD kezelés a feladata, semmi más. Az SPI kommunikáció például nem ide tartozik, az ki van szervezve.
* Open-Close Principle: Ha új GLCD hardvert kell támogatni, csak egy új GLCD leszármazottat kell létrehozni és a main()-ben azt kell példányosítani. Vagyis máshol nem kell módosítani már meglévő forráskódon.
* Liskov Substitution Principle: minden GLCD leszármazott pontosan azt teszi az örökölt metódusaiban, amire azt az ősosztályban szántuk. Ez itt a példában nem látszik, de a Write metódusokban figyelünk rá, hogy más mellékhatás ne legyen.
* Interface Segregation Principle: itt most nem sok szétválasztható dolog volt, így ez az elv most nem jött elő.
@@ -105,16 +105,16 @@ Nyilván az új interfész bevezetésével most sajnos módosítani kell a GLCD
FontSource& fontSource;
};
-Érdemes megemlíteni, hogy a fontSource-ot érdemes az ősosztályban kezelni, a leszármazottaknak ezzel már ne legyen semmi dolga. (A láthatósága protected, különben nem tudnál a leszármazottak használni.) A GLCD leszármazottak szintén a konstruktorukban fogják megkapni a FontSource referenciát, amit továbbadnak majd a GLCD ősosztály kontruktorának. Például a GLCDSPI esetében:
+Érdemes megemlíteni, hogy a fontSource-ot érdemes az ősosztályban kezelni, a leszármazottaknak ezzel már ne legyen semmi dolga. (A láthatósága protected, különben nem tudnák a leszármazottak használni.) A GLCD leszármazottak szintén a konstruktorukban fogják megkapni a FontSource referenciát, amit továbbadnak majd a GLCD ősosztály konstruktorának. Például a GLCDSPI esetében:
- class GLCDSPI : public GLCD
- {
- public:
- GLCDSPI(SPI& spi, FontSource& fontSource) : GLCD(fontSource) { this->spi = spi; }
- virtual void Write(uchar row, uchar col, const char* text);
- private:
- SPI& spi;
- };
+ class GLCDSPI : public GLCD
+ {
+ public:
+ GLCDSPI(SPI& spi, FontSource& fontSource) : GLCD(fontSource) { this->spi = spi; }
+ virtual void Write(uchar row, uchar col, const char* text);
+ private:
+ SPI& spi;
+ };
A Write metódusok megfelelő módosításával sikeresen ki is szerveztük a FontSource támogatást. A FontSource egyes leszármazottai belül valószínűleg egy a "fontdata" megoldáshoz hasonló tömböt fognak használni. Ez már belső magánügyük. A lényeg, hogy kintről ezeket lehet cserélgetni és a GLCD mindig az aktuálisat használja.
@@ -163,6 +163,6 @@ Az egyes GLCD::Write-ok módosítása és FontSource::GetFontWidth metódusok me
### Egyéb megjegyzések
-Azt még érdemes megemlíteni, hogy a 2. körben a GLCD kontruktorokból kihagyhattuk volna a FontSource referenciákat, ha bevezetünk egy globális default fontot. Így akkor egyszerűsödik az interfész, viszont meg kell oldani, hogy a GLCD ősosztály hogyan találja meg a default FontSource-ot a konstruktorában. Erre fel lehet használni a singleton tervezési mintát, amivel készíthetünk egy mindenhonnan elérhető FontCollection-t, amiből el lehet kérni pl. név alapján a FontSource-okat, és biztosítjuk, hogy egy "default" nevű mindig lesz.
+Azt még érdemes megemlíteni, hogy a 2. körben a GLCD konstruktorokból kihagyhattuk volna a FontSource referenciákat, ha bevezetünk egy globális default fontot. Így akkor egyszerűsödik az interfész, viszont meg kell oldani, hogy a GLCD ősosztály hogyan találja meg a default FontSource-ot a konstruktorában. Erre fel lehet használni a singleton tervezési mintát, amivel készíthetünk egy mindenhonnan elérhető FontCollection-t, amiből el lehet kérni pl. név alapján a FontSource-okat, és biztosítjuk, hogy egy "default" nevű mindig lesz.
Szerzők, verziók: Csorba Kristóf
diff --git a/snippets/0221_LiskovModemPelda/index.md b/snippets/0221_LiskovModemPelda/index.md
new file mode 100644
index 0000000..e2eecc9
--- /dev/null
+++ b/snippets/0221_LiskovModemPelda/index.md
@@ -0,0 +1,55 @@
+---
+layout: default
+codename: LiskovModemPelda
+title: Modemes példa a Liskov Substitution Principlere
+tags: designpatterns alkfejl
+authors: Csorba Kristóf
+---
+
+# Amikor nem sikerült tartani a Liskov Substitution Principlet
+
+Az alábbi modemes példa alapgondolata Uncle Bobtól származik, a kapcsolódó protokollokat kicsit frissítettem aktuálisabb környezetre. A történet bemutatja, hogy az első hangzásra triviálisnak tűnő Liskov Substitution Principle megtartása nem is mindig olyan triviális dolog.
+
+A történet egy fiktív cég fiktív fejlesztőiről szól, akiknek volt egy FileMover alkalmazásuk, ami TCP/IP protokoll felett tudott fájlokat mozgatni. Volt nekik ezen kívül egy másik csapatuk, akik RS-232-höz használtak egy jól bevált, agyontesztelt függvénykönyvtárat, amit ők készítettek még vagy 15 évvel korábban.
+
+A cégvezetés megkérte a fejlesztőket, hogy mindenféle logfájlok kezelése miatt a FileMover működjön RS-232 felett is.
+
+## Az egységes ősosztály
+
+Mivel a fejlesztő csapat igyekezett szépen dolgozni, kiemelték a közös interfészt és létrehoztak egy Communication ősosztályt. Mivel a TCP/IP protokoll stackben 4 metódus volt (_open_, _close_, _send_ és _receive_), az egyeséges interfészbe is ezek kerültek bele. Bár az RS-232 esetében az első kettő hiányzott, de semmi gond, azok majd megörökölnek egy üres metódust és nem csinálnak vele semmit.
+
+(Az RS-232 csapat már ennek sem örült, mert bele kellett nyúlni az ő kódjukba is, de végülis két üres metódus ha nem is szép, de még elfogadható.)
+
+## Anomáliák a soros vonali küldéskor
+
+A FileMover egy ideig szépen ment, de aztán időnként érdekes hibák jöttek elő, amikor RS-232-n kellett volna dolgoznia. Kis debuggolás után kiderült, hogy a soros vonalon néha korábban is jönnek adatok (kritikus versenyhelyzet és társai...), mint hogy a FileMover megnyitotta volna a kapcsolatot. Márcsak azért sem, mert a túloldal eleve nem ismeri azt a fogalmat, hogy "megnyitjuk az RS-232 kapcsolatot". (A CTS és RTR vezetékek már régen hiányoznak abból a kábelből és az implementációból.) A FileMover viszont ezt eléggé nehezen viselte.
+
+## A megoldás: IsOpened
+
+- Semmi gond, nem kell mást tenni, mint módosítani az RS-232 kommunikációt...
+- Grrr...
+- ...szóval egy picit ki kellene egészíteni: mentsétek el egy bool változóba, hogy meg van-e nyitva a kapcsolat (IsOpened), ezt módosítsa az _open_ és a _close_ és ha nincs megnyitva, ne fogadjatok adatokat.
+- Grrr... és amiatt írjuk át a többi projektünkben is az RS-232 API hívásokat, hogy hívják meg az _open_-t? 10-15 éve nem kellett hozzányúlni azokhoz a részekhez!
+- Bocs... légyszi-légyszi! Fontos az egységes kódbázis! Nagyon jó lesz utána!
+- Na jó... legyen. Simán _open_?
+- Öööö... az _open_-nek van egy IP cím paramétere, mert a TCP/IP-ben kell címezni is.
+- Na és az egy RS-232 kapcsolat esetén mégis mi legyen??? Most komolyan mindenhol írjuk ki, hogy _open(0,0,0,0)_?
+- Bocs...
+
+Ez van... és így is lett.
+
+## Egy újabb fejlesztés
+
+Pár hónappal később felvetődött, hogy már nagyon ideje lenne haladni a korral és támogatni az IPv6-ot is. Ami annyiban rázós, hogy más a cím típusa, ami az _open_ paramétere. Mivel a címet nem egy sima stringként adták át neki, ami egyébként egy védhető és típus-biztosabb megközelítés, ez akkor azt is jelenti, hogy változik a közös interface! Izé, kedves soros port csapat... ki lehetne egészíteni úgy az implementációtokat, hogy az open-nek kicsit megválozott a paraméter listája?
+
+Na ekkor pöccent be a soros porti csapat másodjára. Most a közös interface miatt egy tőlük teljesen független változás náluk is módosítást követel. 15 évig nem kellett piszkálni azt a kódot és ment minden szépen. Erre most a nagy egységesítés nevében lassan havonta kell módosítani, ami egy csomó saját kis projektjükre is hatással van...
+
+## Mi lett volna a megoldás?
+
+No hát így lehet beleszaladni a Liskov Substitution Principle megsértésébe, vagyis abba, hogy az ősosztály alatt nem cserélgethetőek tetszőlegesen a leszármazottak. Az "_open_ és _close_ majd nem csinál semmit" megközelítés nem jött be, az RS-232 implementáció nem volt csereszabatos a TCP/IP-vel. Ellentmondásos elvárások ütköztek az egységes interfésznél és az nem tudott egyszerre mindkettőnek megfelelni.
+
+A megoldás lehetett volna például az Adapter tervezési mindta alkalmazása: a FileMover számára az egységes Communication létrejön, de az RS-232 kapcsolat ezt nem implementálja, mert neki nincsen _open_ és _close_. Helyette az adapter osztály a leszármazott, ami magán belül tartalmaz (beburkol) egy RS-232 hivatkozást és ő az, aki belül megoldja, hogy az örökölt _open_ meghívása előtt nem enged adatokat fogadni.
+
+Ebben a megoldásban sem a FileMover, sem az RS-232 API nem tudna róla, hogy közöttük van egy adapter (egyfajta átjátszó). Az adaptertől senkinek a többi munkája nem függ, így az RS-232 csapatot nem érintik a későbbi interface módosítások sem, csak az adaptert kell egy kicsit kiegészíteni.
+
+Szerzők, verziók: Csorba Kristóf
diff --git a/snippets/0222_SOLID/index.md b/snippets/0222_SOLID/index.md
new file mode 100644
index 0000000..9566d7c
--- /dev/null
+++ b/snippets/0222_SOLID/index.md
@@ -0,0 +1,53 @@
+---
+layout: default
+codename: SOLID
+title: SOLID elvek
+tags: designpatterns alkfejl
+authors: Csorba Kristóf
+---
+
+# SOLID elvek
+
+A SOLID elvek irányelvek, hogy OK, hogy objektum orientáltan programozunk, de azt is lehet jól is és rosszul is. Hogyan érdemes ezt csinálni úgy, hogy elkerüljük a kód rothadást (code rot) és a programunk karbantartható legyen.
+
+A SOLID itt egy betűszó:
+
+ * Single Responsibility Principle (SRP)
+ * Open-Close Principle (OCP)
+ * Liskov Substitution Principle (LSP)
+ * Interface Segregation Principle (ISP)
+ * Dependency Inversion Principle (DIP)
+
+## Single Responsibility Principle (SRP)
+
+Az SRP lényege, hogy egy valaminek (tipikusan osztály, metódus) egy felelőssége legyen és ne több. Ha több dolgot csinál valami, akkor azt már érdemes kettévágni. Ennek nem csak az átláthatóság az oka, hanem az is, hogy ha több dolgot csinál, akkor azok a dolgok egymástól független fejlődnek, változnak, és ezek összeakadhatnak: felesleges egymásra hatások jelennek meg, nem lehet őket függetlenül használni, tesztelni.
+
+Amikor egy osztály megsérti az SRP-t, akkor általában vagy két azonos szinten lévő feladatot tartalmaz (pl. kommunikál egy távolságérzékelővel és egy kamerável), vagy egy kiszervezhető részfeladatot is magába foglal, ami miatt már túl nagy (pl. ha egy webáruház rendszerben a `Person` osztály tartalazza a hitelkártya számának ellenőrzését is). Mindkét esetben érdemes darabolni, amint a darabok mérete már nem triviálisan kicsi. (Nyilván nem fogunk 3 sor kódot minden esetben kiszervezni egy külön osztályba.)
+
+## Open-Close Principle (OCP)
+
+AZ OCP keretében arra törekszünk, hogy amikor új funkciót kell hozzátenni a rendszerhez (új fejlesztés), akkor lehetőleg ne kelljen már meglévő forráskódot módosítani, hanem csak újat hozzátenni. A lényeg, hogy ne kelljen mások régi kódjába beletúrni csak azért, hogy berakjunk egy új funkciót. Az ok nagyon egyszerű: egyrészt jó eséllyel sértenénk a Single Responsibility Principlet, valamint amin nem módosítunk, azt kisebb eséllyel rontjuk el. Vagyis lényegesen kisebb a regressziós hibák bevitelének esélye. (Regresszió az, amikor valami korábban már működött, de most elromlott.)
+
+A gyakorlatban ezt az elvet teljesen tisztán nemigen tudjuk követni, mert például ha mindent egy új osztályba készítünk el, akkor is azt valahol az eddigi kódban kell példányosítani. De egy új eseménykezelő, egy új művelet regisztrálása csak pár sor, ott kicsi eséllyel viszünk be hibát.
+
+Például ha van egy beágyazott rendszerünk, ami szenzorokat használ, akkor érdemes kialakítani egy szenzor ősosztályt, hogy aztán amikor egy újat kell támogatni, akkor csak ennek egy új leszármazottját kelljen elkészíteni és beregisztrálni (felvenni egy listába). Az eddigi kódrészletek ezután már a többi szenzorhoz hasonlóan ezt is fogják inicializálni, pollozni, miközben nem is tudnak róla, hogy egy új eszközről van szó. (A programunk egy pontján ha valamiről nem tudunk, akkor jó eséllyel annak a változása sem befolyásol minket.)
+
+## Liskov Substitution Principle (LSP)
+
+Az LSP az osztályok származtatásánál jelenik meg fontos szempontként: ha egy osztályból több másik származik le, akkor elvileg az ősosztályt interfészként használva mindegy kell, hogy legyen, melyik konkrét leszármazott példányával is dolgozunk. Első hangzásra ez triviálisnak tűnhet, hiszen erről szól a származtatás, a gyakorlatban viszont egész könnyű beleszaladni olyan hibákba, amikor az egyik leszármazott nem teljesen úgy működik, mint a társai, és ez oda vezet, hogy mégsem lehet teljesen észrevétlenül kicserélni őket. (Ha pedig egy metódus azt vizsgálja if-ek sorában, hogy a kapott objektum tényleges típusa mi, akkor valószínűleg már baj van... ezt az esetet hívják type casingnek.)
+
+Egy hosszabb példa található erre a [Modemes példa a Liskov Substitution Principlere](../0221_LiskovModemPelda/index.html) snippetben.
+
+## Interface Segregation Principle (ISP)
+
+Az ISP az interfészek kialakításánál játszik szerepet. Lényege, hogy amikor egy interfészt (vagy absztrakt ősosztályt) készítünk, akkor az egy feladatkörre vonatkozzon. Vagyis ha egy osztályt 3 féle környezetből használhatnak és ezek kicsit más metódusokat hívnának, akkor ne mindent egy interfészbe rakjunk bele, hanem daraboljuk fel és a konkrét osztályunk majd származik mindháromból.
+
+Például ha van egy csomó szenzorunk és lehet őket pollozni és diagnosztizálni is (önteszt futtatása), akkor erre érdemes egy közös ISensor interfész helyett készíteni egy IPollable és IDiagnosable interfészt is. Egyrészt áttekinthetőbb (single responsibility principle), másrészt így nem kényszerítjük rá minden szenzorra, hogy diagnosztizálható is legyen. (Ha megtesszük, egy idő után tuti lesz egy csomó szenzorunk, amiben a diagnosztika egy `return true` lesz...)
+
+## Dependency Inversion Principle (DIP)
+
+A DIP lényege, hogy magas szintű kód ne függjön az alacsony szintű megvalósítástól. Vagyis például a menüvezérlő ne tudja, hogy ő most pontosan milyen grafikus LCD-re vagy monitorra rajzol. Objektum orientált környezetben ez azt jelenti, hogy a menüvezérlő csak egy interfészt lásson a kijelzőből, azt ne tudja, hogy pontosan milyen osztállyal kommunikál ezen keresztül.
+
+Egy UML osztály diagrammon ez nagyon jól látszik: az öröklés nyila mindig az ősosztály felé mutat, mivel az ősosztály ismerete kell az örökléshez. A hivatkozás sima nyila arra az osztályra mutat, aminek meg akarjuk hívni a metódusait, így tehát annak az ismerete is kell a programrészlet lefordításához. A nyíl mindig arra mutat, amitől függünk. A fenti menüvezérlőből mutatna egy nyíl pl. egy IDisplay interfészre vagy ősosztályra, de annak leszármazottjaiból (pl. grafikus LCD, HDMI, VGA port stb.) megint csak az IDisplay felé mutatnának nyilak. Vagyis a függőség iránya itt megforul és a menüvezérlő nem függ a tényleges, alacsonyabb szintű megvalósítástól.
+
+A DIP gyakran olyan irányelvként jelenik meg, hogy programozzunk interfészekre: az osztályainkat rejtsük interfészek mögé, mert akkor a hívó fél számára teljesen transzparensen lecserélhetjük az osztályunkat egy másikra, a hívó fél oldalán semmilyen módosításra nem lesz szükség.
diff --git a/snippets/0706_DockerBev/index.md b/snippets/0706_DockerBev/index.md
index be5a803..ca023d5 100644
--- a/snippets/0706_DockerBev/index.md
+++ b/snippets/0706_DockerBev/index.md
@@ -2,7 +2,7 @@
layout: default
codename: DockerBev
title: Docker bevezető
-tags: retelab docker
+tags: docker
authors: Osman Omar
---
diff --git a/snippets/0707_WindowsVM_Alkfejl/index.md b/snippets/0707_WindowsVM_Alkfejl/index.md
index 9020952..2c5339e 100644
--- a/snippets/0707_WindowsVM_Alkfejl/index.md
+++ b/snippets/0707_WindowsVM_Alkfejl/index.md
@@ -1,3 +1,11 @@
+---
+layout: default
+codename: WinVMQemu
+title: Windows VM készítése Qemu környezetben
+tags: alkfejl
+authors: Koloszár Gergely
+---
+
# Windows VM készítése Qemu környezetben
Az Alkalmazásfejlesztés tárgy keretein belül elkerülhetetlenül szükség van
diff --git a/snippets/0800_Luis/index.md b/snippets/0800_Luis/index.md
index 1d1a791..3539f08 100644
--- a/snippets/0800_Luis/index.md
+++ b/snippets/0800_Luis/index.md
@@ -2,7 +2,7 @@
layout: default
codename: Luis
title: Introduction to LUIS
-tags: ai luis nlp
+tags: ai nlp
authors: Dócs Zoltán
---
diff --git a/snippets/AlkFejlHfTanulsagok/32/index.md b/snippets/AlkFejlHfTanulsagok/32/index.md
index 64d0a1c..dfc5c07 100644
--- a/snippets/AlkFejlHfTanulsagok/32/index.md
+++ b/snippets/AlkFejlHfTanulsagok/32/index.md
@@ -2,7 +2,7 @@
layout: default
codename: AlkFejlHf32
title: Fantaziadus csapatnev tanulságai
-tags: alkamazasFejlesztes
+tags: alkfejl afhf skipfromindex
authors: Ádám Tibor, Fenyővári Boldizsár, Lakatos Dániel
---
diff --git a/snippets/AlkFejlHfTanulsagok/37/index.md b/snippets/AlkFejlHfTanulsagok/37/index.md
index 457ce19..2f206bc 100644
--- a/snippets/AlkFejlHfTanulsagok/37/index.md
+++ b/snippets/AlkFejlHfTanulsagok/37/index.md
@@ -2,7 +2,7 @@
layout: default
codename: AlkFejlHf37
title: MáDaBa csapat tanulságai
-tags: alkalmazasFejlesztes
+tags: alkfejl afhf skipfromindex
authors: Fortágh Dávid, Kullai Máté, Stráhl Balázs
---
diff --git a/snippets/AlkFejlHfTanulsagok/38/appokalipszis_csapat_tanulsagai.md b/snippets/AlkFejlHfTanulsagok/38/appokalipszis_csapat_tanulsagai.md
index 6a07880..605aeeb 100644
--- a/snippets/AlkFejlHfTanulsagok/38/appokalipszis_csapat_tanulsagai.md
+++ b/snippets/AlkFejlHfTanulsagok/38/appokalipszis_csapat_tanulsagai.md
@@ -2,7 +2,7 @@
layout: default
codename: AlkFejlHf38
title: Appokalipszis csapat tanulságai
-tags: snippets
+tags: alkfejl afhf skipfromindex
authors: Dori Zsófia, Tokaji András, Lovass Gábor
---
diff --git a/snippets/AlkFejlHfTanulsagok/39/index.md b/snippets/AlkFejlHfTanulsagok/39/index.md
index 2ac8ea6..6b38002 100644
--- a/snippets/AlkFejlHfTanulsagok/39/index.md
+++ b/snippets/AlkFejlHfTanulsagok/39/index.md
@@ -1,45 +1,45 @@
---
layout: default
codename: AlkFejlHf39
-title: Groot csapat tanuls�gai
-authors: Mih�lyi Gergely, Nemes Marcell, Ny�ry L�rinc
+title: Groot csapat tanulságai
+authors: Mihályi Gergely, Nemes Marcell, Nyáry Lőrinc
tags: alkfejl afhf skipfromindex
---
-# Alkalmaz�sfejleszt�s h�zi feladat tapasztalatok
+# Alkalmazásfejlesztés házi feladat tapasztalatok
-## Fejleszt�si Tapasztalatok
+## Fejlesztési Tapasztalatok
-### Verzi�kezel�sr�l
+### Verziókezelésről
-A verzi�kezel�s, �s a t�voli Git repository haszn�lata volt tal�n a legpozit�vabb tapasztalat a feladat megold�sa sor�n. Haszn�lat�val a k�z�s munka g�rd�l�keny tudott lenni, nem kellett k�dokat mozgatni �s �gyelni arra, hogy kin�l van �ppen a legfrissebb verzi�. A be�p�tett merge tool szint�n nagyon hasznosnak bizonyult, amikor egyszerre egy k�dr�szen t�bben dolgoztunk. A konfliktusok t�lnyom� r�sz�t aut�matikusan kezelni tudta, �s csak n�h�ny k�rd�ses esetben kellett k�zzel d�nt�st hozni. A dokument�ci� k�sz�t�se sor�n is nagy segits�g volt a v�ltoztat�sok visszak�vethet�s�ge.
-A feladat megold�sa sor�n a GitKraken-t haszn�ltuk, ami j�l �tl�that�an, �s azonnal jelzi a Qt Creator-ban megtett v�ltoztat�sokat. K�nny� �ttekint�st ada a Git-f�hoz, �s felhaszn�l�bar�t fel�letet a commit �zenetek meg�r�s�hoz.
+A verziókezelés, és a távoli Git repository használata volt talán a legpozitívabb tapasztalat a feladat megoldása során. Használatával a közös munka gördülékeny tudott lenni, nem kellett kódokat mozgatni és ügyelni arra, hogy kinél van éppen a legfrissebb verzió. A beépített merge tool szintén nagyon hasznosnak bizonyult, amikor egyszerre egy kódrészen többen dolgoztunk. A konfliktusok túlnyomó részét autómatikusan kezelni tudta, és csak néhány kérdéses esetben kellett kézzel döntést hozni. A dokumentáció készítése során is nagy segitség volt a változtatások visszakövethetősége.
+A feladat megoldása során a GitKraken-t használtuk, ami jól átláthatóan, és azonnal jelzi a Qt Creator-ban megtett változtatásokat. Könnyű áttekintést ada a Git-fához, és felhasználóbarát felületet a commit üzenetek megírásához.
-### A tervez�si megfontol�sok
+### A tervezési megfontolások
-Az alkalmaz�s elk�sz�t�se sor�n �gyelt�nk arra, hogy minden oszt�ly j�l meghat�rozhat� feladatot l�sson el. P�ld�ul egy k�l�n�ll� oszt�ly felel�s a �modell� -�rt, azaz a kezelt v�ltoz�k �sszefog�s��rt. Ez az oszt�ly nem foglalkozik kommunik�ci�val, vagy megjelen�t�ssel, ezekre k�l�n kommunik�ci�s, k�zvet�t� �s a QML k�z�tt kapcsolatot tart� oszt�lyok vannak. Ez a megk�zel�t�s k�nny� �tl�that�s�got, �s b�v�t�st tesz lehet�v�, hiszen ha lecser�ln�nk p�ld�ul a kommunik�ci�t egy m�sik protokolra, akkor az �zleti logik�t ez teljesen v�ltozatlanul hagyn�, nem k�ne azzal foglalkoznunk, ez mire lehet m�g hat�ssal a k�l�nb�z� k�dokban. Ugyan�gy a megjelen�t�st att�l teljesen f�ggetlen�l tudjuk kezelni, hogy �ppen a megjelen�tett adat, hogy j�n l�tre �s hogy ker�l tov�bb�t�sra.
+Az alkalmazás elkészítése során ügyeltünk arra, hogy minden osztály jól meghatározható feladatot lásson el. Például egy különálló osztály felelős a modell -ért, azaz a kezelt változók összefogásáért. Ez az osztály nem foglalkozik kommunikációval, vagy megjelenítéssel, ezekre külön kommunikációs, közvetítő és a QML között kapcsolatot tartó osztályok vannak. Ez a megközelítés könnyű átláthatóságot, és bővítést tesz lehetővé, hiszen ha lecserélnénk például a kommunikációt egy másik protokolra, akkor az üzleti logikát ez teljesen változatlanul hagyná, nem kéne azzal foglalkoznunk, ez mire lehet még hatással a különböző kódokban. Ugyanígy a megjelenítést attól teljesen függetlenül tudjuk kezelni, hogy éppen a megjelenített adat, hogy jön létre és hogy kerül továbbításra.
-### Megjelen�t�s �s UI
+### Megjelenítés és UI
-Mindenkinek tan�csolni tudjuk a QML k�sz�t�s�n�l, hogy import�lj�k a legfrissebb QtQuick objektumokat, mert ezek drasztikusan befoly�solj�k a vez�rl� elemek alap�rtelmezett kin�zet�t, �s eszt�tikusabb, modernebb k�ls�t adnak az alkalmaz�snak. Szint�n fontos tapasztalat volt, hogy b�r nem lebecs�lve a csapat eszt�tikai �rz�k�t, az internet sz�mos el�re elk�sz�tett design-t tartalmaz, melyeket �rdemes megfontolni, �gy az �sszk�p kellemesebb lesz.
+Mindenkinek tanácsolni tudjuk a QML készítésénél, hogy importálják a legfrissebb QtQuick objektumokat, mert ezek drasztikusan befolyásolják a vezérlő elemek alapértelmezett kinézetét, és esztétikusabb, modernebb külsőt adnak az alkalmazásnak. Szintén fontos tapasztalat volt, hogy bár nem lebecsülve a csapat esztétikai érzékét, az internet számos előre elkészített design-t tartalmaz, melyeket érdemes megfontolni, így az összkép kellemesebb lesz.
-
+
### Qt signals and slots
-A fenti mechanizmussal a h�zi feladat keretei k�z�tt tal�lkoztunk el�sz�r, �s meglep�en g�rd�l�kenyen �s k�nnyen haszn�lhat� megold�s a program r�szei k�zti asszinkron kommunik�ci�ra. Egy k�vetkez� C++ projekt k�sz�t�s�n�l, biztosan alkalmazni fogjuk az itt megtanult patterneket, hogy �tl�that�bb �s hat�konyabb k�dot tudjunk �rni.
+A fenti mechanizmussal a házi feladat keretei között találkoztunk először, és meglepően gördülékenyen és könnyen használható megoldás a program részei közti asszinkron kommunikációra. Egy következő C++ projekt készítésénél, biztosan alkalmazni fogjuk az itt megtanult patterneket, hogy átláthatóbb és hatékonyabb kódot tudjunk írni.
-## Tesztek �s dokument�ci�
-### Felhaszn�l�i tesztek
+## Tesztek és dokumentáció
+### Felhasználói tesztek
-Mint ahogy a legt�bb GUI k�sz�t�s�n�l, most is hasznosnak bizonyult a v�gs� teszteket egy �laikussal� elv�geztetni. B�r erre a csapat t�bb tagja is alkalmasnak �rezte mag�t, egy nem szak�rt� csal�dtag bevon�sa r�vil�g�tott, hogy a k�sz�t� tudja hova kell kattintatni, �gy sok hib�t nem vesz �szre. Tipikusan ilyen volt a gombok enged�lyez�s�nek szab�lyoz�sa.
+Mint ahogy a legtöbb GUI készítésénél, most is hasznosnak bizonyult a végső teszteket egy laikussal elvégeztetni. Bár erre a csapat több tagja is alkalmasnak érezte magát, egy nem szakértő családtag bevonása rávilágított, hogy a készítő tudja hova kell kattintatni, így sok hibát nem vesz észre. Tipikusan ilyen volt a gombok engedélyezésének szabályozása.
-### Dokument�ci� k�sz�t�s
+### Dokumentáció készítés
-Sz�mos f�lrevezet� inform�ci�t tal�lni interneten arr�l, hogy mi a c�lszer� m�dja a dokument�ci� elk�sz�t�s�nek. K�l�n�sen igaz ez, ha a k�l�nb�z� diagrammok k�sz�t�s�t n�zz�k. V�g�l ezekhez a Visual Paradigm programot haszn�ltuk, �s a kommentezett k�d felhaszn�l�s�val tudtunk szint�n sok energi�t sp�rolni a Doxygen miatt. Tanuls�g a j�v�re n�zve, hogy �rdemes azonnal kommentezni, ahogy egy �j sor k�d megsz�letik, �gy a le�rt inform�ci� r�szletesebb, �s ut�lag sokkal kellemetlenebb munka a k�dot visszafejteni.
+Számos félrevezető információt találni interneten arról, hogy mi a célszerű módja a dokumentáció elkészítésének. Különösen igaz ez, ha a különböző diagrammok készítését nézzük. Végül ezekhez a Visual Paradigm programot használtuk, és a kommentezett kód felhasználásával tudtunk szintén sok energiát spórolni a Doxygen miatt. Tanulság a jövőre nézve, hogy érdemes azonnal kommentezni, ahogy egy új sor kód megszületik, így a leírt információ részletesebb, és utólag sokkal kellemetlenebb munka a kódot visszafejteni.
-## �sszefoglal�s
+## Összefoglalás
-�sszess�g�ben az h�zi feladat elk�sz�t�se sok �j �s hasznos tud�st adott, ami az egyetemi keretekb�l kil�pve is meg�rzi �rt�k�t �s hasznoss�g�t. Ez egyr�szt igaz a felhaszn�lt technol�gi�ra, valamint azokra a fejleszt�si eszk�z�kre, melyek haszn�lat�t a projekt sor�n elsaj�t�tottuk.
+Összességében az házi feladat elkészítése sok új és hasznos tudást adott, ami az egyetemi keretekből kilépve is megőrzi értékét és hasznosságát. Ez egyrészt igaz a felhasznált technológiára, valamint azokra a fejlesztési eszközökre, melyek használatát a projekt során elsajátítottuk.
-Szerz�k: Mih�lyi Gergely, Nemes Marcell, Ny�ry L�rinc
\ No newline at end of file
+Szerzők: Mihályi Gergely, Nemes Marcell, Nyáry Lőrinc
\ No newline at end of file
diff --git a/stylesheets/stylesheet.scss b/stylesheets/stylesheet.scss
index 519f193..6d0bcef 100644
--- a/stylesheets/stylesheet.scss
+++ b/stylesheets/stylesheet.scss
@@ -4,13 +4,14 @@
$ColorDarkNormal: #000000;
$ColorDarkEmph: #573923;
$ColorDarkUnimportant: #555555;
-$ColorLightNormal: #FFFFDD;
+$ColorLightNormal: #FFFFEE;
$ColorHeaderBackground: #CCCCBB;
$ColorButtonBorder: #555555;
$ColorLightEmph: #990000;
$ColorCodeForeground: #440000;
-$ColorCodeBackground: #F2F2DD;
+$ColorCodeBackground: #FFFFFF;
$ColorLink: #0000FF;
+$ColorBlockquote: #573923;
* {
box-sizing: border-box; }
@@ -76,8 +77,7 @@ a {
.page-header {
color: $ColorDarkNormal;
text-align: center;
- background-color: #159957;
- background-image: linear-gradient(120deg, #CCCCBB, #DDDDCC); }
+ background-image: linear-gradient(120deg,$ColorLightNormal, $ColorHeaderBackground); }
@media screen and (min-width: 64em) {
.page-header {
@@ -191,8 +191,8 @@ a {
.main-content blockquote {
padding: 0 1rem;
margin-left: 0;
- color: $ColorCodeBackground;
- border-left: 0.3rem solid $ColorCodeBackground; }
+ color: $ColorBlockquote;
+ border-left: 0.3rem solid $ColorBlockquote; }
.main-content blockquote > :first-child {
margin-top: 0; }
.main-content blockquote > :last-child {
@@ -328,4 +328,4 @@ a {
.highlight .vc { color: #008080 } /* Name.Variable.Class */
.highlight .vg { color: #008080 } /* Name.Variable.Global */
.highlight .vi { color: #008080 } /* Name.Variable.Instance */
-.highlight .il { color: #009999 } /* Literal.Number.Integer.Long */
+.highlight .il { color: #009999 } /* Literal.Number.Integer.Long */
\ No newline at end of file