Translation

README.md

@@ -1,15 +1,29 @@
-# Q&A sessions
+# Sesja pytań i odpowiedzi
 
 <a href="https://coders.school">
     <img width="500" data-src="coders_school_logo.png" src="coders_school_logo.png" alt="Coders School" class="plain">
 </a>
 
-## [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)

module1/01_scrum.en.md

@@ -0,0 +1,19 @@
+<!-- .slide: data-background="#111111" -->
+
+# 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
+
+* <!-- .element: class="fragment fade-in" --> Daily meetings - organized to synchronize workflow, see how the work is going and in particular who needs a helping hand because he stuck.
+* <!-- .element: class="fragment fade-in" --> 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.
+* <!-- .element: class="fragment fade-in" --> 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.

module1/02_konkurs.en.md

@@ -0,0 +1,35 @@
+<!-- .slide: data-background="#111111" -->
+
+# STL contest
+
+___
+
+## STL contest
+
+Thank you very much for participating in the competition 🙂 The award for all participants is the 'STL Star' achievement.
+
+___
+
+## Podium
+
+* <!-- .element: class="fragment fade-in" --> 1st place (30 XP)
+  * <!-- .element: class="fragment fade-in" --> Konkurs-coders-squad-9
+  * <!-- .element: class="fragment fade-in" --> My tu tylko po punkty
+* <!-- .element: class="fragment fade-in" --> 2nd place (20 XP)
+  * <!-- .element: class="fragment fade-in" --> Diggers team
+  * <!-- .element: class="fragment fade-in" --> Squad – 2
+* <!-- .element: class="fragment fade-in" --> 3rd place (10 XP)
+  * <!-- .element: class="fragment fade-in" --> StowarzyszenieTechnicznychLemingow
+  * <!-- .element: class="fragment fade-in" --> very smart pointers
+
+___
+
+## Make your repositories public and post them on the `#contest` channel 🙂
+
+___
+
+## Conclusions after the contest
+
+* <!-- .element: class="fragment fade-in" --> 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. <a href="https://www.youtube.com/watch?v=Ct-lOOUqmyY">I highly recommend this video</a>
+* <!-- .element: class="fragment fade-in" --> As many coaches, as many opinions about the requirements
+* <!-- .element: class="fragment fade-in" --> As many coaches as many opinions about coding styles

module1/03_code-review.en.md

@@ -0,0 +1,237 @@
+<!-- .slide: data-background="#111111" -->
+
+# Examples from Code Review
+
+___
+<!-- .slide: style="font-size: 0.9em" -->
+
+Example:
+
+```cpp
+bool doesPasswordsMatch(const std::string& password, const std::string& repeatedPassword) {
+    if (password == repeatedPassword) {
+        return true;
+    }
+    return false;
+}
+```
+
+Better:
+<!-- .element: class="fragment fade-in" -->
+
+```cpp
+bool doesPasswordsMatch(const std::string& password, const std::string& repeatedPassword) {
+    return password == repeatedPassword;
+}
+```
+<!-- .element: class="fragment fade-in" -->
+
+___
+<!-- .slide: style="font-size: 0.9em" -->
+
+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:
+<!-- .element: class="fragment fade-in" -->
+
+```cpp
+if(doesPasswordsMatch(first_pass, second_pass)) {
+    return checkPasswordRules(first_pass);
+}
+return ErrorCode::PasswordsDoesNotMatch;
+```
+<!-- .element: class="fragment fade-in" -->
+
+___
+
+```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 :)
+
+___
+<!-- .slide: style="font-size: 0.75em" -->
+
+> A: You can specify a size of vector in constructor :)
+
+```cpp
+std::vector<std::shared_ptr<int>> resultVector(count);
+```
+
+> B: Yes, but what about situation, when count is negative value? I do not think such value should be used in the vector constructor, that's why I do such check first.
+<!-- .element: class="fragment fade-in" -->
+
+```cpp
+std::vector<std::shared_ptr<int>> resultVector{};
+if (count < 0) {
+    return resultVector;
+}
+resultVector.reserve(count);
+```
+<!-- .element: class="fragment fade-in" -->
+
+> A: you are right :) , my fault :)
+<!-- .element: class="fragment fade-in" -->
+
+> B: No problem, thanks for review :)
+<!-- .element: class="fragment fade-in" -->
+
+https://github.com/coders-school/kurs_cpp_podstawowy/pull/254/files
+<!-- .element: class="fragment fade-in" -->
+
+___
+<!-- .slide: style="font-size: 0.85em" -->
+
+Max line length - 120. How to format?
+
+Typically lines are long when the function takes multiple parameters:
+<!-- .element: class="fragment fade-in" -->
+
+```cpp
+int superFunction(std::vector<std::shared_ptr<int>> vectorOfSharedPointers, std::map<std::string, int> miniMap, std::unordered_set<int> hashes, std::function<void(int, int)> compareFunction) {
+    // do sth
+}
+
+// usage
+auto result = superFunction(mySuperVector, myMiniMap, myGreatHashTable, [](const auto & lhs, const auto & rhs) { return lhs >= rhs;})
+```
+<!-- .element: class="fragment fade-in" -->
+
+Better formatting:
+<!-- .element: class="fragment fade-in" -->
+
+```cpp
+int superFunction(std::vector<std::shared_ptr<int>> vectorOfSharedPointers,
+                  std::map<std::string, int> miniMap,
+                  std::unordered_set<int> hashes,
+                  std::function<void(int, int)> compareFunction) {
+    // do sth
+}
+
+// usage
+auto result = superFunction(mySuperVector,
+                            myMiniMap,
+                            myGreatHashTable,
+                            [](const auto & lhs, const auto & rhs) { return lhs >= rhs;});
+```
+<!-- .element: class="fragment fade-in" -->
+
+___
+
+Or for longer lambdas / too long first parameter which exceeds line limit:
+
+```cpp
+int superFunction(
+        std::vector<std::shared_ptr<int>> vectorOfSharedPointers,
+        std::map<std::string, int> miniMap,
+        std::unordered_set<int> hashes,
+        std::function<void(int, int)> compareFunction) {
+        // two levels of indentation above to avoid confusion.
+        // The function body below will be indented with one level
+    // do sth
+}
+
+// usage
+auto result = superFunction(mySuperVector,
+                            myMiniMap,
+                            myGreatHashTable,
+                            [](const auto & lhs, const auto & rhs) {
+                                return lhs >= rhs;
+                            });
+```
+<!-- .element: class="fragment fade-in" -->
+
+___
+
+* <!-- .element: class="fragment fade-in" --> <a href="https://github.com/coders-school/kurs_cpp_podstawowy/pull/252/files">Nice usage of <code>std::map</code> instead of ifs' ladder</a>
+* <!-- .element: class="fragment fade-in" --> Pay attention to the line breaks at the end of the document.
+* <!-- .element: class="fragment fade-in" --> <code>enum</code> or <code>enum class</code> are integer values ​​underneath (some kind of int). It's not worth passing them over <code>const&</code> for optimization.
+* <!-- .element: class="fragment fade-in" -->  Max 2 blank lines. Usually one is enough. 2 empty lines cannot appear inside any blocks (ranges) like functions, classes, enums.
+* <!-- .element: class="fragment fade-in" -->  Good practice - allocate vector capacity when known in advance.
+* <!-- .element: class="fragment fade-in" -->  When do we use the conventions?
+  * <!-- .element: class="fragment fade-in" -->  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)
+  * <!-- .element: class="fragment fade-in" -->  Individual work - you can use your own preferences, it is important that it is uniform.
+  * <!-- .element: class="fragment fade-in" --> 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. 
+
+___
+
+* <!-- .element: class="fragment fade-in" --> <code>#include</code> - I (Łukasz) am not too Nazi commenting to you that:
+  * <!-- .element: class="fragment fade-in" --> it is unsorted
+  * <!-- .element: class="fragment fade-in" --> there is no new line
+  * <!-- .element: class="fragment fade-in" --> to move it to cpp instead of sticking to hpp
+  * <!-- .element: class="fragment fade-in" --> 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.
+  <!-- .element: class="fragment fade-in" -->
+
+* <!-- .element: class="fragment fade-in" --> 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 ;)