From 6885bf6876e4d325621bbf820d4097ae551af577 Mon Sep 17 00:00:00 2001 From: Penthurion Date: Wed, 2 Sep 2020 09:47:11 +0200 Subject: [PATCH 1/9] preparation files to translation from pl to en --- module1/{scrum.md => 01_scrum.en.md} | 0 module1/01_scrum.pl.md | 19 ++ module1/{konkurs.md => 02_konkurs.en.md} | 0 module1/02_konkurs.pl.md | 35 +++ .../{code-review.md => 03_code-review.en.md} | 0 module1/03_code-review.pl.md | 237 ++++++++++++++++++ .../{repetition.md => 04_repetition.en.md} | 0 module1/04_repetition.pl.md | 71 ++++++ module1/{index.html => index.en.html} | 0 module1/index.pl.html | 114 +++++++++ 10 files changed, 476 insertions(+) rename module1/{scrum.md => 01_scrum.en.md} (100%) create mode 100644 module1/01_scrum.pl.md rename module1/{konkurs.md => 02_konkurs.en.md} (100%) create mode 100644 module1/02_konkurs.pl.md rename module1/{code-review.md => 03_code-review.en.md} (100%) create mode 100644 module1/03_code-review.pl.md rename module1/{repetition.md => 04_repetition.en.md} (100%) create mode 100644 module1/04_repetition.pl.md rename module1/{index.html => index.en.html} (100%) create mode 100644 module1/index.pl.html diff --git a/module1/scrum.md b/module1/01_scrum.en.md similarity index 100% rename from module1/scrum.md rename to module1/01_scrum.en.md diff --git a/module1/01_scrum.pl.md b/module1/01_scrum.pl.md new file mode 100644 index 0000000..caad632 --- /dev/null +++ b/module1/01_scrum.pl.md @@ -0,0 +1,19 @@ + + +# Współpraca grupowa - Scrum + +___ + +## Współpraca grupowa - Scrum + +* [Spotkania Scrumowe](https://github.com/coders-school/qa-sessions/raw/master/module1/ScrumFramework.pdf) + +* [Ściąga ze Scruma](https://github.com/coders-school/qa-sessions/raw/master/module1/sciaga_scrum.pdf) + +___ + +## Scrum - dobre praktyki + +* Daily meetings - codzienne spotkania w celu zsynchronizowania się, zobaczenia jak idzie robota i w szczególności, komu trzeba pomóc, bo utknął. +* Podejście iteracyjne - dostarczamy małe kawałki funkcjonalności. Ważne żeby jak najszybciej dostarczyć cokolwiek, co powoduje, że choćby tylko jeden test przechodzi. Potem każdy może nad tym nadbudowywać kolejne funkcjonalności. +* Retrospektywy - wg mnie najważniejsze spotkanie. Odbywa się po zakończonej iteracji (sprincie) i zespół klepie się po pleckach jak to było wspaniale, jak dużo się udało zrobić i jak to można jeszcze polepszyć. Poza tym zespół wrzuca sobie najgorsze epitety odnośnie nieumiejętności współpracy, wyrobienia się na czas i poprawnego zaplanowania swojej pracy. Po tym spotkaniu muszą być sformułowane wnioski co można poprawić, aby lepiej się współpracowało oraz akcje do zrobienia dla każdej osoby. diff --git a/module1/konkurs.md b/module1/02_konkurs.en.md similarity index 100% rename from module1/konkurs.md rename to module1/02_konkurs.en.md diff --git a/module1/02_konkurs.pl.md b/module1/02_konkurs.pl.md new file mode 100644 index 0000000..316bc55 --- /dev/null +++ b/module1/02_konkurs.pl.md @@ -0,0 +1,35 @@ + + +# Konkurs STL + +___ + +## Konkurs STL + +Bardzo dziękujemy za udział w konkursie 🙂 Nagroda dla wszystkich uczestników to osiągnięcie 'Gwiazda STLa' + +___ + +## Podium + +* 1 Miejsce (30 XP) + * Konkurs-coders-squad-9 + * My tu tylko po punkty +* 2 Miejsce (20 XP) + * Diggers team + * Squad – 2 +* 3 Miejsce (10 XP) + * StowarzyszenieTechnicznychLemingow + * very smart pointers + +___ + +## Zróbcie wasze repozytoria publiczne i wrzućcie je na kanał `#konkurs` 🙂 + +___ + +## Wnioski po konkursie + +* Formułowanie zadań / wymagań to sztuka. Jakby dokładnie tego nie zrobić to zawsze będzie wiele osób, które będzie potrafiło inaczej zinterpretować wymagania niż zakładał autor. Polecam mocno to wideo +* Ilu trenerów tyle opinii na temat wymagań +* Ilu trenerów tyle opinii na temat styli kodowania diff --git a/module1/code-review.md b/module1/03_code-review.en.md similarity index 100% rename from module1/code-review.md rename to module1/03_code-review.en.md diff --git a/module1/03_code-review.pl.md b/module1/03_code-review.pl.md new file mode 100644 index 0000000..7b0ef3c --- /dev/null +++ b/module1/03_code-review.pl.md @@ -0,0 +1,237 @@ + + +# Przykłady z 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::vector> 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. + + +```cpp +std::vector> resultVector{}; +if (count < 0) { + return resultVector; +} +resultVector.reserve(count); +``` + + +> A: you are right :) , my fault :) + + +> B: No problem, thanks for review :) + + +https://github.com/coders-school/kurs_cpp_podstawowy/pull/254/files + + +___ + + +Max długość linii - 120. Jak formatować? + +Zazwyczaj linie są długie gdy funkcja przyjmuje wiele parametrów: + + +```cpp +int superFunction(std::vector> vectorOfSharedPointers, std::map miniMap, std::unordered_set hashes, std::function compareFunction) { + // do sth +} + +// usage +auto result = superFunction(mySuperVector, myMiniMap, myGreatHashTable, [](const auto & lhs, const auto & rhs) { return lhs >= rhs;}) +``` + + +Better formatting: + + +```cpp +int superFunction(std::vector> vectorOfSharedPointers, + std::map miniMap, + std::unordered_set hashes, + std::function compareFunction) { + // do sth +} + +// usage +auto result = superFunction(mySuperVector, + myMiniMap, + myGreatHashTable, + [](const auto & lhs, const auto & rhs) { return lhs >= rhs;}); +``` + + +___ + +Or for longer lambdas / too long first parameter which exceeds line limit: + +```cpp +int superFunction( + std::vector> vectorOfSharedPointers, + std::map miniMap, + std::unordered_set hashes, + std::function 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; + }); +``` + + +___ + +* Nice usage of std::map instead of ifs' ladder +* 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. +* 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? + * Współpraca grupowa - obowiązkowo. Nie ma nic gorszego niż niejednolite formatowanie w projekcie. Narzucamy wam styl zmodyfikowany styl Chromium, aby nie było przepychanek. Możecie go egzekwować do woli, w szczególności w Internal Code Review (czyli wewnątrz grupy, zanim zgłosicie nam Pull Request do sprawdzenia) + * Praca indywidualna - można stosować własne upodobania, ważne żeby było jednolicie. + * Nie bądźcie "code style nazi" i nie wymuszajcie na innych osobach waszego stylu formatowania, jeśli komentujecie indywidualne PR. Oczywiście fajnie gdyby wszystko było tak samo wszędzie, ale tak naprawdę co firma/projekt to spotkacie się z innym formatowaniem. Warto przywyknąć, że nie zawsze wam pasuje to co sprawdzacie. Głównie odnosi się to do nowych linii i nawiasów {}. + +___ + +* #include - ja (Łukasz) nie jestem zbyt nazistowski z komentowaniem wam że: + * jest nieposortowane + * nie ma nowej linii + * żeby to przenosić do cpp zamiast trzymać w hpp + * usunąć, bo nieużywane. + + Tylko jak mi się rzuci w oczy to daję taki komentarz. Ale wiedzcie, że to są dobre praktyki i warto je stosować. + + +* Też nie bądźcie nazistami i nie róbcie całego code review tylko po to, żeby komuś wytknąć nieposortowane headery lub brakujące {} w jednym miejscu. Podczas projektów grupowych takie rzeczy sobie nawytykacie wewnątrz grup i tak się najszybciej nauczycie :) Na zewnątrz do sprawdzenia ma wychodzić kod przejrzany przez pozostałe osoby z grupy. Nie ma zwalania winy, że to pisał X i on nie dopilnował. Cała grupa obrywa równo ;) diff --git a/module1/repetition.md b/module1/04_repetition.en.md similarity index 100% rename from module1/repetition.md rename to module1/04_repetition.en.md diff --git a/module1/04_repetition.pl.md b/module1/04_repetition.pl.md new file mode 100644 index 0000000..1591f74 --- /dev/null +++ b/module1/04_repetition.pl.md @@ -0,0 +1,71 @@ + + +# Pytania z kanału #powtórka + +___ + +@edmundoPL +> Pytanie ode mnie na powtórkę. O co chodzi z tym zapewnianiem odpowiednio długiego życia zmiennej, na która wskazuje pointer lub referencja? +> Pojawiło się to już kilka razy, a ja nadal jakoś tego nie czuje. Niby trochę rozumiem ale nie do końca. Może jakiś ciekawy przykład się znajdzie do czwartku? + +___ + + +Prześledźmy stos w tym kawałku kodu + +```cpp +#include + +int doNothing() { +/* G */ int b = 50; + int c = 100; +/* H */ return b; +} + +int* getObject() { +/* C */ int a = 10; + int* ptr = &a; +/* D */ return ptr; +} + +int main() { +/* A */ int number = 5; +/* B */ int* pointer = getObject(); +/* E */ *pointer = 20; +/* F */ number = doNothing(); +/* I */ std::cout << *pointer << '\n'; +} +``` + +Stos graficznie. Prawo -> kolejne linie kodu + +
+ +| FRAME | A | B | C | D | E | F | G | H | I | +| :---: | :-------------- | :------------- | :---------- | :----------- | :------------------- | :----------- | :-------------- | :----------- | :-------------- | +| 1 | | | **ptr = ?** | **ptr = &a** | | | **c = ?** | **c = 100** | | +| 1 | | | **a = ?** | **a = 10** | | **??? = 20** | **b = ? (20?)** | **b = 50** | | +| 0 | **pointer = ?** | pointer = ? | pointer = ? | pointer = ? | **pointer = &a** !!! | pointer = &a | pointer = &a | pointer = &a | pointer = &a | +| 0 | **number = ?** | **number = 5** | number = 5 | number = 5 | number = 5 | number = 5 | number = 5 | number = 5 | **number = 50** | + +
+ +___ + +@Jakub J +> Generyczne lambdy, jaki jest w takim razie sens stosowania zwykłych lambd(w których przekazujemy konkretny typ)? + +Ograniczony. Tylko gdy chcemy, aby lambda zadziałała dla określonego typu i np. nie skompilowała się dla innego. +Normalnie zalecam stosowanie generycznych. W kodzie można się natknąć na takie i takie. Generyczne weszły w C++14 i jeszcze się dobrze nie upowszechniły. Ale mocno do nich zachęcam. + +___ + + +@lisie_sprawy +> Przeklejam z innego kanału, żeby nie uciekło :) czemu w niektórych zadaniach związanych z wywaleniem samogłosek pojawia się np. "constexpr int", zamiast "const int"? + +`constexpr` w kontekście zmiennej to taki silniejszy const. Oprócz tego, że jest to stała i nie zmienimy jej wartości to kompilator może dodatkowo optymalizować wszelkie obliczenia wykonywane z jej użyciem i po prostu już podczas kompilacji obliczyć wynik i wstawić go w odpowiednie miejsca jako stałe programu. Jak to robić to się nauczymy na nowoczesnym C++, gdzie bardziej fascynujący będzie temat funkcji `constexpr`, a nie zmiennych (stałych). + +W każdym bądź razie jest to optymalizacja i warto mieć odruch pisania constexpr od razu. Jeśli gdzieś kompilator zaprotestuje, to znaczy że się nie da i zostawiamy sam const. Od C++20 `constexpr` wejdzie w użycie jeszcze powszechniej, bo dużo ograniczeń funkcji `constexpr` zostanie zniesionych. + +Do zapamiętania na teraz: staraj się domyślnie używać `constexpr` przy definiowaniu stałych zamiast const. diff --git a/module1/index.html b/module1/index.en.html similarity index 100% rename from module1/index.html rename to module1/index.en.html diff --git a/module1/index.pl.html b/module1/index.pl.html new file mode 100644 index 0000000..378732c --- /dev/null +++ b/module1/index.pl.html @@ -0,0 +1,114 @@ + + + + + + + Q&A sessions - Coders School + + + + + + + + + + + + + + + +
+
+
+
+ +

Q&A sessions

+ + + Coders School + + +

Łukasz Ziobroń

+ +
+
+ +
+
+ +
+
+
+
+
+
+
+
+
+ +

Coders School

+ Coders School + +
+
+
+ + + + + + \ No newline at end of file From 0b8f9b2a78180f21a881bb6790ff4e37dd92b321 Mon Sep 17 00:00:00 2001 From: Penthurion Date: Wed, 2 Sep 2020 10:39:46 +0200 Subject: [PATCH 2/9] 01_scrum translated to english --- module1/01_scrum.en.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/module1/01_scrum.en.md b/module1/01_scrum.en.md index caad632..335364b 100644 --- a/module1/01_scrum.en.md +++ b/module1/01_scrum.en.md @@ -1,19 +1,19 @@ -# Współpraca grupowa - Scrum +# Teamwork - Scrum ___ -## Współpraca grupowa - Scrum +## Teamwork - Scrum -* [Spotkania Scrumowe](https://github.com/coders-school/qa-sessions/raw/master/module1/ScrumFramework.pdf) +* [Scrum meetings](https://github.com/coders-school/qa-sessions/raw/master/module1/ScrumFramework.pdf) -* [Ściąga ze Scruma](https://github.com/coders-school/qa-sessions/raw/master/module1/sciaga_scrum.pdf) +* [Scrum cheat sheet](https://github.com/coders-school/qa-sessions/raw/master/module1/sciaga_scrum.pdf) ___ -## Scrum - dobre praktyki +## Scrum - good practices -* Daily meetings - codzienne spotkania w celu zsynchronizowania się, zobaczenia jak idzie robota i w szczególności, komu trzeba pomóc, bo utknął. -* Podejście iteracyjne - dostarczamy małe kawałki funkcjonalności. Ważne żeby jak najszybciej dostarczyć cokolwiek, co powoduje, że choćby tylko jeden test przechodzi. Potem każdy może nad tym nadbudowywać kolejne funkcjonalności. -* Retrospektywy - wg mnie najważniejsze spotkanie. Odbywa się po zakończonej iteracji (sprincie) i zespół klepie się po pleckach jak to było wspaniale, jak dużo się udało zrobić i jak to można jeszcze polepszyć. Poza tym zespół wrzuca sobie najgorsze epitety odnośnie nieumiejętności współpracy, wyrobienia się na czas i poprawnego zaplanowania swojej pracy. Po tym spotkaniu muszą być sformułowane wnioski co można poprawić, aby lepiej się współpracowało oraz akcje do zrobienia dla każdej osoby. +* Daily meetings - organized to synchronize workflow, see how the work is going and in particular who needs a helping hand because he 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. From 195b83ede0b7538c1019732e647269c12c55e6e5 Mon Sep 17 00:00:00 2001 From: Penthurion Date: Wed, 2 Sep 2020 10:48:35 +0200 Subject: [PATCH 3/9] konkurs translated to english --- module1/02_konkurs.en.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/module1/02_konkurs.en.md b/module1/02_konkurs.en.md index 316bc55..403c627 100644 --- a/module1/02_konkurs.en.md +++ b/module1/02_konkurs.en.md @@ -1,35 +1,35 @@ -# Konkurs STL +# STL contest ___ -## Konkurs STL +## STL contest -Bardzo dziękujemy za udział w konkursie 🙂 Nagroda dla wszystkich uczestników to osiągnięcie 'Gwiazda STLa' +Thank you very much for participating in the competition 🙂 The award for all participants is the 'STL Star' achievement. ___ ## Podium -* 1 Miejsce (30 XP) +* 1st place (30 XP) * Konkurs-coders-squad-9 * My tu tylko po punkty -* 2 Miejsce (20 XP) +* 2nd place (20 XP) * Diggers team * Squad – 2 -* 3 Miejsce (10 XP) +* 3rd place (10 XP) * StowarzyszenieTechnicznychLemingow * very smart pointers ___ -## Zróbcie wasze repozytoria publiczne i wrzućcie je na kanał `#konkurs` 🙂 +## Make your repositories public and post them on the `#contest` channel 🙂 ___ -## Wnioski po konkursie +## Conclusions after the contest -* Formułowanie zadań / wymagań to sztuka. Jakby dokładnie tego nie zrobić to zawsze będzie wiele osób, które będzie potrafiło inaczej zinterpretować wymagania niż zakładał autor. Polecam mocno to wideo -* Ilu trenerów tyle opinii na temat wymagań -* Ilu trenerów tyle opinii na temat styli kodowania +* 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 From 12b58f3c5368d2fcc3d999fd5f7eb389564355f0 Mon Sep 17 00:00:00 2001 From: Penthurion Date: Wed, 2 Sep 2020 11:17:56 +0200 Subject: [PATCH 4/9] repetition translated to english --- module1/04_repetition.en.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/module1/04_repetition.en.md b/module1/04_repetition.en.md index 1591f74..a5378ff 100644 --- a/module1/04_repetition.en.md +++ b/module1/04_repetition.en.md @@ -1,17 +1,17 @@ -# Pytania z kanału #powtórka +# Questions from #powtórka channel ___ @edmundoPL -> Pytanie ode mnie na powtórkę. O co chodzi z tym zapewnianiem odpowiednio długiego życia zmiennej, na która wskazuje pointer lub referencja? -> Pojawiło się to już kilka razy, a ja nadal jakoś tego nie czuje. Niby trochę rozumiem ale nie do końca. Może jakiś ciekawy przykład się znajdzie do czwartku? +> 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? ___ -Prześledźmy stos w tym kawałku kodu +Let's trace the stack in this piece of code ```cpp #include @@ -37,7 +37,7 @@ int main() { } ``` -Stos graficznie. Prawo -> kolejne linie kodu +Stack graphically. Right -> next lines of code
@@ -53,19 +53,18 @@ Stos graficznie. Prawo -> kolejne linie kodu ___ @Jakub J -> Generyczne lambdy, jaki jest w takim razie sens stosowania zwykłych lambd(w których przekazujemy konkretny typ)? - -Ograniczony. Tylko gdy chcemy, aby lambda zadziałała dla określonego typu i np. nie skompilowała się dla innego. -Normalnie zalecam stosowanie generycznych. W kodzie można się natknąć na takie i takie. Generyczne weszły w C++14 i jeszcze się dobrze nie upowszechniły. Ale mocno do nich zachęcam. +> Generic lambdas, what's the point of using regular lambdas (in which we pass a specific type)? +Limited. Only when we want lambda to work for a certain type and e.g. not compile for another. +I normally recommend using generics. You can come across such and such in the code. Generics are in C++14, and are yet to become well-established. But I strongly encourage you to use them. ___ @lisie_sprawy -> Przeklejam z innego kanału, żeby nie uciekło :) czemu w niektórych zadaniach związanych z wywaleniem samogłosek pojawia się np. "constexpr int", zamiast "const int"? +> Repasting it from other channel, so it will not lost itself :) why in some tasks about deleting vowels you can see "constexpr int" instead "const int"? -`constexpr` w kontekście zmiennej to taki silniejszy const. Oprócz tego, że jest to stała i nie zmienimy jej wartości to kompilator może dodatkowo optymalizować wszelkie obliczenia wykonywane z jej użyciem i po prostu już podczas kompilacji obliczyć wynik i wstawić go w odpowiednie miejsca jako stałe programu. Jak to robić to się nauczymy na nowoczesnym C++, gdzie bardziej fascynujący będzie temat funkcji `constexpr`, a nie zmiennych (stałych). +`constexpr` in the context of a variable is a stronger const. In addition to the fact that it is a constant and we will not change its value, the compiler can further optimize all calculations made with its use and simply calculate the result during compilation and put it in the appropriate places as program constants. We will learn how to do it in modern C ++, where more fascinating will be topic of `constexpr` functions, not a variables (constants). -W każdym bądź razie jest to optymalizacja i warto mieć odruch pisania constexpr od razu. Jeśli gdzieś kompilator zaprotestuje, to znaczy że się nie da i zostawiamy sam const. Od C++20 `constexpr` wejdzie w użycie jeszcze powszechniej, bo dużo ograniczeń funkcji `constexpr` zostanie zniesionych. +Anyway, this is an optimization and you should have the habit to write `constexpr` right away. If the compiler protests somewhere, it means you can't use it there and should leave just `const`. From C++20, `constexpr` will become even more common, because many of the limitations of `constexpr` will be lifted. -Do zapamiętania na teraz: staraj się domyślnie używać `constexpr` przy definiowaniu stałych zamiast const. +To remember for now: try to use `constexpr` by default when defining constants instead of `const`. From 0eac3f8cf92dfb84d0aed84a2d766e3751d5bb60 Mon Sep 17 00:00:00 2001 From: Penthurion Date: Wed, 2 Sep 2020 11:42:19 +0200 Subject: [PATCH 5/9] code-reviev.pl.md corrected to be in polish not ponglish :D --- module1/03_code-review.pl.md | 61 +++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 29 deletions(-) diff --git a/module1/03_code-review.pl.md b/module1/03_code-review.pl.md index 7b0ef3c..920ee7f 100644 --- a/module1/03_code-review.pl.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::vector> 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. +> B: Tak, ale co z sytuacją, gdy licznik ma wartość ujemną? Nie sądzę, aby taka wartość była używana w konstruktorze wektora, dlatego najpierw wykonuję takie sprawdzenie. ```cpp @@ -140,10 +143,10 @@ resultVector.reserve(count); ``` -> A: you are right :) , my fault :) +> A: masz racje :) , mój błąd :) -> B: No problem, thanks for review :) +> B: Nie ma problemu, dziękuję za recenzję :) https://github.com/coders-school/kurs_cpp_podstawowy/pull/254/files @@ -152,22 +155,22 @@ https://github.com/coders-school/kurs_cpp_podstawowy/pull/254/files ___ -Max długość linii - 120. Jak formatować? +Max line length - 120. How to format? -Zazwyczaj linie są długie gdy funkcja przyjmuje wiele parametrów: +Typically lines are long when the function takes multiple parameters: ```cpp int superFunction(std::vector> vectorOfSharedPointers, std::map miniMap, std::unordered_set hashes, std::function compareFunction) { - // do sth + // rób coś } -// usage +// użycie auto result = superFunction(mySuperVector, myMiniMap, myGreatHashTable, [](const auto & lhs, const auto & rhs) { return lhs >= rhs;}) ``` -Better formatting: +Lepsze formatowanie: ```cpp @@ -175,10 +178,10 @@ int superFunction(std::vector> vectorOfSharedPointers, std::map miniMap, std::unordered_set hashes, std::function compareFunction) { - // do sth + // rób coś } -// usage +// użycie auto result = superFunction(mySuperVector, myMiniMap, myGreatHashTable, @@ -188,7 +191,7 @@ auto result = superFunction(mySuperVector, ___ -Or for longer lambdas / too long first parameter which exceeds line limit: +Albo dla dłuższych lambd / zbyt długich parametrów, które przekraczają limit linii: ```cpp int superFunction( @@ -196,12 +199,12 @@ int superFunction( std::map miniMap, std::unordered_set hashes, std::function compareFunction) { - // two levels of indentation above to avoid confusion. - // The function body below will be indented with one level - // do sth + // dwa poziomy wcięcia powyżej, aby uniknąć nieporozumień. + // Ciało funkcji poniżej będzie wcięte o jeden poziom + // rób coś } -// usage +// użycie auto result = superFunction(mySuperVector, myMiniMap, myGreatHashTable, @@ -213,9 +216,9 @@ auto result = superFunction(mySuperVector, ___ -* Nice usage of std::map instead of ifs' ladder +* Dobre użycie std::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? From fe045f980ea36a9c4486f34ba9b584a9b9ca86b7 Mon Sep 17 00:00:00 2001 From: Penthurion Date: Wed, 2 Sep 2020 12:22:10 +0200 Subject: [PATCH 6/9] code-review.pl.md minor fix and english translation completed. --- module1/03_code-review.en.md | 38 ++++++++++++++++++------------------ module1/03_code-review.pl.md | 4 ++-- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/module1/03_code-review.en.md b/module1/03_code-review.en.md index 7b0ef3c..0089152 100644 --- a/module1/03_code-review.en.md +++ b/module1/03_code-review.en.md @@ -1,6 +1,6 @@ -# Przykłady z Code Review +# Examples from Code Review ___ @@ -152,9 +152,9 @@ https://github.com/coders-school/kurs_cpp_podstawowy/pull/254/files ___ -Max długość linii - 120. Jak formatować? +Max line length - 120. How to format? -Zazwyczaj linie są długie gdy funkcja przyjmuje wiele parametrów: +Typically lines are long when the function takes multiple parameters: ```cpp @@ -213,25 +213,25 @@ auto result = superFunction(mySuperVector, ___ -* Nice usage of std::map instead of ifs' ladder -* 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. -* 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? - * Współpraca grupowa - obowiązkowo. Nie ma nic gorszego niż niejednolite formatowanie w projekcie. Narzucamy wam styl zmodyfikowany styl Chromium, aby nie było przepychanek. Możecie go egzekwować do woli, w szczególności w Internal Code Review (czyli wewnątrz grupy, zanim zgłosicie nam Pull Request do sprawdzenia) - * Praca indywidualna - można stosować własne upodobania, ważne żeby było jednolicie. - * Nie bądźcie "code style nazi" i nie wymuszajcie na innych osobach waszego stylu formatowania, jeśli komentujecie indywidualne PR. Oczywiście fajnie gdyby wszystko było tak samo wszędzie, ale tak naprawdę co firma/projekt to spotkacie się z innym formatowaniem. Warto przywyknąć, że nie zawsze wam pasuje to co sprawdzacie. Głównie odnosi się to do nowych linii i nawiasów {}. +* Nice usage of std::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 - ja (Łukasz) nie jestem zbyt nazistowski z komentowaniem wam że: - * jest nieposortowane - * nie ma nowej linii - * żeby to przenosić do cpp zamiast trzymać w hpp - * usunąć, bo nieużywane. +* #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. - Tylko jak mi się rzuci w oczy to daję taki komentarz. Ale wiedzcie, że to są dobre praktyki i warto je stosować. + Only when it catches my eye I give such a comment. But know that these are good practices and it is worth applying them. -* Też nie bądźcie nazistami i nie róbcie całego code review tylko po to, żeby komuś wytknąć nieposortowane headery lub brakujące {} w jednym miejscu. Podczas projektów grupowych takie rzeczy sobie nawytykacie wewnątrz grup i tak się najszybciej nauczycie :) Na zewnątrz do sprawdzenia ma wychodzić kod przejrzany przez pozostałe osoby z grupy. Nie ma zwalania winy, że to pisał X i on nie dopilnował. Cała grupa obrywa równo ;) +* 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/03_code-review.pl.md b/module1/03_code-review.pl.md index 920ee7f..3319d38 100644 --- a/module1/03_code-review.pl.md +++ b/module1/03_code-review.pl.md @@ -155,9 +155,9 @@ https://github.com/coders-school/kurs_cpp_podstawowy/pull/254/files ___ -Max line length - 120. How to format? +Max długość linii - 120. Jak formatować? -Typically lines are long when the function takes multiple parameters: +Zazwyczaj linie są długie gdy funkcja przyjmuje wiele parametrów: ```cpp From 6e68d9907fb3a3346608966cf814451cb3e3b7e3 Mon Sep 17 00:00:00 2001 From: Penthurion Date: Wed, 2 Sep 2020 12:32:23 +0200 Subject: [PATCH 7/9] index.html translated adequately to according language. README.md updated --- README.md | 26 ++++++++++++++++++++------ module1/04_repetition.en.md | 2 +- module1/index.en.html | 14 +++++++------- module1/index.pl.html | 12 ++++++------ 4 files changed, 34 insertions(+), 20 deletions(-) diff --git a/README.md b/README.md index 818ef3c..9035250 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,29 @@ -# Q&A sessions +# Sesja pytań i odpowiedzi Coders School -## [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/04_repetition.en.md b/module1/04_repetition.en.md index a5378ff..d4c81a7 100644 --- a/module1/04_repetition.en.md +++ b/module1/04_repetition.en.md @@ -1,7 +1,7 @@ # Questions from #powtórka channel - + ___ @edmundoPL diff --git a/module1/index.en.html b/module1/index.en.html index 378732c..308c161 100644 --- a/module1/index.en.html +++ b/module1/index.en.html @@ -46,9 +46,9 @@

Łukasz Ziobroń

## Agenda 1. Scrum - 2. Konkurs - 3. Code review - przykłady - 4. Pytania z kanału #Powtórka + 2. Contest + 3. Code review - examples + 4. Questions from #Powtórka channel @@ -64,19 +64,19 @@

Łukasz Ziobroń

Open http://localhost:8000 to view your presentation You can change the port by using npm start -- --port=8001. --> -
-
-
-
diff --git a/module1/index.pl.html b/module1/index.pl.html index 378732c..71044dc 100644 --- a/module1/index.pl.html +++ b/module1/index.pl.html @@ -4,7 +4,7 @@ - Q&A sessions - Coders School + Sesja pytań i odpowiedzi - Coders School @@ -31,7 +31,7 @@
-

Q&A sessions

+

Sesja pytań i odpowiedzi

Coders School @@ -64,19 +64,19 @@

Łukasz Ziobroń

Open http://localhost:8000 to view your presentation You can change the port by using npm start -- --port=8001. --> -
-
-
-
From 42271ec0a348a09b7fe2f92cb075586177e9cc8d Mon Sep 17 00:00:00 2001 From: Penthurion <68010070+Penthurion@users.noreply.github.com> Date: Wed, 2 Sep 2020 15:58:59 +0200 Subject: [PATCH 8/9] Update module1/01_scrum.en.md Co-authored-by: MrMijagi <45121219+MrMijagi@users.noreply.github.com> --- module1/01_scrum.en.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/module1/01_scrum.en.md b/module1/01_scrum.en.md index 335364b..0fd5e27 100644 --- a/module1/01_scrum.en.md +++ b/module1/01_scrum.en.md @@ -14,6 +14,6 @@ ___ ## 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 stuck. +* 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. From 53712bca8523541d5fb5fbe491491b62d5692de7 Mon Sep 17 00:00:00 2001 From: Penthurion <68010070+Penthurion@users.noreply.github.com> Date: Wed, 2 Sep 2020 15:59:14 +0200 Subject: [PATCH 9/9] Update module1/04_repetition.en.md Co-authored-by: MrMijagi <45121219+MrMijagi@users.noreply.github.com> --- module1/04_repetition.en.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/module1/04_repetition.en.md b/module1/04_repetition.en.md index d4c81a7..d3535c3 100644 --- a/module1/04_repetition.en.md +++ b/module1/04_repetition.en.md @@ -63,7 +63,7 @@ ___ @lisie_sprawy > Repasting it from other channel, so it will not lost itself :) why in some tasks about deleting vowels you can see "constexpr int" instead "const int"? -`constexpr` in the context of a variable is a stronger const. In addition to the fact that it is a constant and we will not change its value, the compiler can further optimize all calculations made with its use and simply calculate the result during compilation and put it in the appropriate places as program constants. We will learn how to do it in modern C ++, where more fascinating will be topic of `constexpr` functions, not a variables (constants). +`constexpr` in the context of a variable is a stronger const. In addition to the fact that it is a constant and we will not change its value, the compiler can further optimize all calculations made with its use and simply calculate the result during compilation and put it in the appropriate places as program constants. We will learn how to do it in modern C++, where more fascinating will be topic of `constexpr` functions, not variables (constants). Anyway, this is an optimization and you should have the habit to write `constexpr` right away. If the compiler protests somewhere, it means you can't use it there and should leave just `const`. From C++20, `constexpr` will become even more common, because many of the limitations of `constexpr` will be lifted.