-## [Moduł 1](module1/)
+## [Moduł 1](module1/index.pl.html)
-### [Współpraca grupowa - Scrum](module1/scrum.md)
+### [Współpraca grupowa - Scrum](module1/01_scrum.pl.md)
-### [Konkurs STL](module1/konkurs.md)
+### [Konkurs STL](module1/02_konkurs.pl.md)
-### [Przykłady z Code Review](module1/code-review.md)
+### [Przykłady z Code Review](module1/03_code-review.pl.md)
-### [Pytania z kanału #powtórka](module1/repetition.md)
+### [Pytania z kanału #powtórka](module1/04_repetition.pl.md)
+
+___
+
+# Q&A Session
+
+## [Module 1](module1/index.en.html)
+
+### [Teamwork - Scrum](module1/01_scrum.en.md)
+
+### [STL contest](module1/02_konkurs.en.md)
+
+### [Examples from Code Review](module1/03_code-review.en.md)
+
+### [Questions from #powtórka channel](module1/04_repetition.en.md)
\ No newline at end of file
diff --git a/module1/01_scrum.en.md b/module1/01_scrum.en.md
new file mode 100644
index 0000000..0fd5e27
--- /dev/null
+++ b/module1/01_scrum.en.md
@@ -0,0 +1,19 @@
+
+
+# Teamwork - Scrum
+
+___
+
+## Teamwork - Scrum
+
+* [Scrum meetings](https://github.com/coders-school/qa-sessions/raw/master/module1/ScrumFramework.pdf)
+
+* [Scrum cheat sheet](https://github.com/coders-school/qa-sessions/raw/master/module1/sciaga_scrum.pdf)
+
+___
+
+## Scrum - good practices
+
+* Daily meetings - organized to synchronize workflow, see how the work is going and in particular who needs a helping hand because he is stuck.
+* Iterative approach - we deliver small bits of functionality. It is important to provide anything as soon as possible that causes even only one test to pass. Then everyone can build new functionalities on it.
+* Retrospectives - the most important meeting in my opinion. It takes place after the iteration (sprint) is completed and the team pats their backs about how great it was, how much has been done and how it can be improved. In addition, the team throws in the worst epithets about the inability to cooperate, not making it on time and not planing its work correctly. After this meeting, conclusions must be formulated, what can be improved for better cooperation and actions to be done for each person.
diff --git a/module1/scrum.md b/module1/01_scrum.pl.md
similarity index 100%
rename from module1/scrum.md
rename to module1/01_scrum.pl.md
diff --git a/module1/02_konkurs.en.md b/module1/02_konkurs.en.md
new file mode 100644
index 0000000..403c627
--- /dev/null
+++ b/module1/02_konkurs.en.md
@@ -0,0 +1,35 @@
+
+
+# STL contest
+
+___
+
+## STL contest
+
+Thank you very much for participating in the competition 🙂 The award for all participants is the 'STL Star' achievement.
+
+___
+
+## Podium
+
+* 1st place (30 XP)
+ * Konkurs-coders-squad-9
+ * My tu tylko po punkty
+* 2nd place (20 XP)
+ * Diggers team
+ * Squad – 2
+* 3rd place (10 XP)
+ * StowarzyszenieTechnicznychLemingow
+ * very smart pointers
+
+___
+
+## Make your repositories public and post them on the `#contest` channel 🙂
+
+___
+
+## Conclusions after the contest
+
+* Formulating tasks/requirements is an art. After all, there will always be many people who will be able to interpret the requirements differently than assumed by the author. I highly recommend this video
+* As many coaches, as many opinions about the requirements
+* As many coaches as many opinions about coding styles
diff --git a/module1/konkurs.md b/module1/02_konkurs.pl.md
similarity index 100%
rename from module1/konkurs.md
rename to module1/02_konkurs.pl.md
diff --git a/module1/03_code-review.en.md b/module1/03_code-review.en.md
new file mode 100644
index 0000000..0089152
--- /dev/null
+++ b/module1/03_code-review.en.md
@@ -0,0 +1,237 @@
+
+
+# Examples from Code Review
+
+___
+
+
+Example:
+
+```cpp
+bool doesPasswordsMatch(const std::string& password, const std::string& repeatedPassword) {
+ if (password == repeatedPassword) {
+ return true;
+ }
+ return false;
+}
+```
+
+Better:
+
+
+```cpp
+bool doesPasswordsMatch(const std::string& password, const std::string& repeatedPassword) {
+ return password == repeatedPassword;
+}
+```
+
+
+___
+
+
+Example:
+
+```cpp
+std::string getErrorMessage(ErrorCode Error) {
+ switch (Error) {
+ case ErrorCode::Ok:
+ return "OK";
+ break;
+ case ErrorCode::PasswordNeedsAtLeastNineCharacters:
+ return "Password Needs At Least Nine Characters";
+ break;
+ case ErrorCode::PasswordNeedsAtLeastOneNumber:
+ return "Password Needs At Least One Number";
+ break;
+ case ErrorCode::PasswordNeedsAtLeastOneSpecialCharacter:
+ return "Password Needs At Least One Special Character";
+ break;
+ case ErrorCode::PasswordNeedsAtLeastOneUppercaseLetter:
+ return "Password Needs A Least One Uppercase Letter";
+ break;
+ case ErrorCode::PasswordsDoesNotMatch:
+ return "Passwords Does Not Match";
+ break;
+ default:
+ return "UNDEFINED ERROR";
+ }
+ }
+ // What do you think about removing case ErrorCode::Ok: and putting it in default?
+ // Braces are not needed even for multiline cases. It's only matter of convention if you should apply them or not. They don't provide additional safety.
+ // We usually don't indent case and code inside namespace
+```
+
+___
+
+Better?:
+
+```cpp
+std::string getErrorMessage(ErrorCode error) {
+ switch (error) {
+ case ErrorCode::PasswordNeedsAtLeastNineCharacters:
+ return "Password Needs At Least Nine Characters";
+ case ErrorCode::PasswordNeedsAtLeastOneNumber:
+ return "Password Needs At Least One Number";
+ case ErrorCode::PasswordNeedsAtLeastOneSpecialCharacter:
+ return "Password Needs At Least One Special Character";
+ case ErrorCode::PasswordNeedsAtLeastOneUppercaseLetter:
+ return "Password Needs A Least One Uppercase Letter";
+ case ErrorCode::PasswordsDoesNotMatch:
+ return "Passwords Does Not Match";
+ default:
+ return "OK";
+ }
+ }
+```
+
+___
+
+Example:
+
+```cpp
+if(doesPasswordsMatch(first_pass, second_pass)) {
+ return checkPasswordRules(first_pass);
+} else {
+ return ErrorCode::PasswordsDoesNotMatch;
+}
+```
+
+Better:
+
+
+```cpp
+if(doesPasswordsMatch(first_pass, second_pass)) {
+ return checkPasswordRules(first_pass);
+}
+return ErrorCode::PasswordsDoesNotMatch;
+```
+
+
+___
+
+```cpp
+enum class ErrorCode {
+ PasswordNeedsAtLeastNineCharacters,
+ PasswordNeedsAtLeastOneUppercaseLetter,
+ PasswordNeedsAtLeastOneSpecialCharacters, // trailing comma
+}
+```
+
+> I do not know really, it's maybe my habit taken from python, to have commas also in the last element of enum/collection, because if I add new element in the future, i didn't have to worry about some errors in regards to missing comma :)
+
+___
+
+
+> A: You can specify a size of vector in constructor :)
+
+```cpp
+std::vectorstd::map instead of ifs' ladder
+* Pay attention to the line breaks at the end of the document.
+* enum or enum class are integer values underneath (some kind of int). It's not worth passing them over const& for optimization.
+* Max 2 blank lines. Usually one is enough. 2 empty lines cannot appear inside any blocks (ranges) like functions, classes, enums.
+* Good practice - allocate vector capacity when known in advance.
+* When do we use the conventions?
+ * Group cooperation - obligatory. There is nothing worse than patchy formatting in your project. We are imposing on you the Chromium Modified Style so that there is no scuffle. You can enforce it at will, in particular in the Internal Code Review (i.e. inside the group, before sending us a Pull Request for review)
+ * Individual work - you can use your own preferences, it is important that it is uniform.
+ * Don't be "code style nazi" and don't force your formatting style on other people if you comment on individual PR. Of course, it would be nice if everything has same formatting everywhere, but in fact, every company/project will use a different formatting. It is worth to get used to the fact that what you check does not always suit you. This mainly applies to new lines and {} brackets.
+
+___
+
+* #include - I (Łukasz) am not too Nazi commenting to you that:
+ * it is unsorted
+ * there is no new line
+ * to move it to cpp instead of sticking to hpp
+ * remove, because not used.
+
+ Only when it catches my eye I give such a comment. But know that these are good practices and it is worth applying them.
+
+
+* Also, don't be Nazis and don't do the whole code review just to point out to someone unsorted headers or missing {} in one place. During group projects you'll give yourself a needles about such things inside the groups and this is how you learn the fastest :) To outside review should goes only the code checked by other group members. There is no blaming X that wrote that and he did not take care of it. The whole group gets a beating evenly ;)
diff --git a/module1/code-review.md b/module1/03_code-review.pl.md
similarity index 82%
rename from module1/code-review.md
rename to module1/03_code-review.pl.md
index 7b0ef3c..3319d38 100644
--- a/module1/code-review.md
+++ b/module1/03_code-review.pl.md
@@ -5,7 +5,7 @@
___
-Example:
+Przykład:
```cpp
bool doesPasswordsMatch(const std::string& password, const std::string& repeatedPassword) {
@@ -16,7 +16,7 @@ bool doesPasswordsMatch(const std::string& password, const std::string& repeated
}
```
-Better:
+Lepiej:
```cpp
@@ -29,7 +29,7 @@ bool doesPasswordsMatch(const std::string& password, const std::string& repeated
___
-Example:
+Przykład:
```cpp
std::string getErrorMessage(ErrorCode Error) {
@@ -56,14 +56,17 @@ std::string getErrorMessage(ErrorCode Error) {
return "UNDEFINED ERROR";
}
}
- // What do you think about removing case ErrorCode::Ok: and putting it in default?
- // Braces are not needed even for multiline cases. It's only matter of convention if you should apply them or not. They don't provide additional safety.
- // We usually don't indent case and code inside namespace
+ //
+ //
+ //
+ // Co myślisz o usunięciu przypadku ErrorCode::Ok: i ustawieniu go jako domyślnego?
+ // Nawiasy klamrowe nie są potrzebne nawet w przypadkach wielowierszowych. To tylko kwestia konwencji, czy powinieneś je stosować, czy nie. Nie zapewniają dodatkowego bezpieczeństwa.
+ // Zazwyczaj nie dokonujemy wcięć przy caseach i kodzie w namespaceach
```
___
-Better?:
+Lepiej?:
```cpp
std::string getErrorMessage(ErrorCode error) {
@@ -86,7 +89,7 @@ std::string getErrorMessage(ErrorCode error) {
___
-Example:
+Przykład:
```cpp
if(doesPasswordsMatch(first_pass, second_pass)) {
@@ -96,7 +99,7 @@ if(doesPasswordsMatch(first_pass, second_pass)) {
}
```
-Better:
+Lepiej:
```cpp
@@ -113,22 +116,22 @@ ___
enum class ErrorCode {
PasswordNeedsAtLeastNineCharacters,
PasswordNeedsAtLeastOneUppercaseLetter,
- PasswordNeedsAtLeastOneSpecialCharacters, // trailing comma
+ PasswordNeedsAtLeastOneSpecialCharacters, // końcowy przecinek
}
```
-> I do not know really, it's maybe my habit taken from python, to have commas also in the last element of enum/collection, because if I add new element in the future, i didn't have to worry about some errors in regards to missing comma :)
+> Naprawdę nie wiem, może to mój nawyk zaczerpnięty z Pythona, aby mieć przecinki również po ostatnim elemencie wyliczenia/kolekcji, bo jeśli w przyszłości dodam nowy element, nie będę się musiał martwić o błędy w odniesieniu do brakującego przecinka :)
___
-> A: You can specify a size of vector in constructor :)
+> A: Możesz określić rozmiar wektora w konstruktorze :)
```cpp
std::vectorstd::map zamiast drabiny ifów
* Zwracajcie uwagę na znaki końca linii na końcu dokumentu.
-* enum lub enum class są pod spodem wartościami całkowitymi (jakiś rodzaj inta). Nie warto przekazywać ich przez const& w celu optymalizacji.
+* enum lub enum class są pod spodem wartościami całkowitymi (jakiś rodzaj inta). Nie warto przekazywać ich przez const& w celu optymalizacji.
* Max 2 puste linie. Zazwyczaj wystarcza jedna. 2 puste linie nie mogą wystąpić wewnątrz żadnych bloków (zakresów), jak funkcje, klasy, enumy.
* Dobra praktyka - alokowanie pojemności wektora, gdy jest z góry znana.
* Kiedy stosujemy konwencje?
diff --git a/module1/04_repetition.en.md b/module1/04_repetition.en.md
new file mode 100644
index 0000000..d3535c3
--- /dev/null
+++ b/module1/04_repetition.en.md
@@ -0,0 +1,70 @@
+
+
+# Questions from #powtórka channel
+
+___
+
+@edmundoPL
+> Question from me to for the recap. What is the point of ensuring a long enough life for the variable which the pointer or reference points to?
+> It happened a couple of times now, and I still don't feel it. I kind of understand but not quite. Maybe an interesting example will be found by Thursday?
+
+___
+
+
+Let's trace the stack in this piece of code
+
+```cpp
+#include 
+ 
+
+