diff --git a/README.md b/README.md
index cc20f9e..165abd5 100644
--- a/README.md
+++ b/README.md
@@ -1,17 +1,33 @@
-# Dobre praktyki
-
-## [Moduł 1](module1/)
+# Dobre praktyki
+
+## [Moduł 1](module1/index.pl.html)
+
+### [Współpraca grupowa](module1/01_teamwork.pl.md)
+
+### [Konwencje](module1/02_conventions.pl.md)
+
+### [Praktyki programistyczne](module1/03_principles.pl.md)
+
+### [Dobre praktyki](module1/04_practices.pl.md)
+
+### [Praca domowa](module1/05_homework.pl.md)
+
+___
+
+# Good practices
+
+## [Module 1](module1/index.en.html)
-### [Współpraca grupowa](module1/presentation_teamwork.md)
+### [Teamwork](module1/01_teamwork.en.md)
-### [Konwencje](module1/presentation_conventions.md)
+### [Conventions](module1/02_conventions.en.md)
-### [Praktyki programistyczne](module1/presentation_principles.md)
+### [Programming principles](module1/03_principles.en.md)
-### [Dobre praktyki](module1/presentation_practices.md)
+### [Good practices](module1/04_practices.en.md)
-### [Praca domowa](module1/presentation_homework.md)
+### [Homework](module1/05_homework.en.md)
diff --git a/module1/01_teamwork.en.md b/module1/01_teamwork.en.md
new file mode 100644
index 0000000..20c985b
--- /dev/null
+++ b/module1/01_teamwork.en.md
@@ -0,0 +1,125 @@
+
+
+# Teamwork
+
+
+
+
+
+___
+
+## Philosophical questions
+
+### a.k.a. retrospective
+
+* How did you feel while working together?
+* Were there problems that you did not foresee at the beginning?
+* Was the estimated time of the tasks consistent with reality?
+* What went wrong?
+* What worked fine and you could suggest implementing this to other groups?
+
+___
+
+## Unexpected problems
+
+The fact that we threw you a little into this project and forced you to self-organize was on purpose.
+
+
+We wanted to show you how many things are not taken into account at the beginning before starting the project.
+
+
+And even with several years of experience in project management, some things cannot be avoided.
+
+
+* sickness of team members
+* unexpected departures
+* additional, unplanned tasks
+* wrongly estimated task time
+* technical problems (computer restarting itself, git - conflicts, bad internet connection)
+* changing requirements or their interpretations
+
+___
+
+## Task estimation
+
+The theory suggests that a cool way to better estimate tasks is to multiply the initial estimate by PI 😄
+
+
+Other sources indicate that an order of magnitude should be increased (e.g. from 5 hours to 5 days, from 3 days to 3 weeks, etc.) 😄
+
+
+In practice, poker is used for estimation
+
+
+## 🃏
+
+___
+
+## Scrum poker
+
+### Rules
+
+* We do not estimate tasks in units of time.
+* We choose one task for the whole team that is the easiest of all. We give it the value of 1.
+* We only use the values from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ♾,? - I have no idea, ☕️). Thanks to this, we focus more on orders of magnitude than on the units themselves, because there is no big difference between 9 and 10.
+* The unit is Story Points (SP). This is a completely abstract measure. You can think of it as any other abstract. For example, this task is valued for 5 chestnuts. This information is completely useless, but it allows you to compare tasks. Since the other one is worth 8, it is more valuable (more difficult).
+* For one person, 1 SP may mean 1 hour of work, and for another - 1 day.
+
+___
+
+### The course of the estimation
+
+* We discuss one selected task with the whole team to make sure that everyone understands it in the same way.
+* When everyone is ready they simultaneously draw the card with their estimate so nobody is influenced by others
+* If the divergence is large, it means that team members have a different understanding of the task and still need to be discussed. It is worth asking people with the lowest and highest estimate why they give so much.
+* If the divergences are small, you can average them or agree to some value (usually higher)
+
+Look for online Scrum Poker tools and use them to estimate tasks in Planning.
+
+
+___
+
+## Collective responsibility
+
+It's hard to blame someone for getting sick. But you can blame him for committing to something and then him not letting you know that it won't work. So daily is important to get in the habit of updating your status at least daily. Of course you can do it more often.
+
+
+As soon as you find out that someone from the crew isn't keeping up, you should think immediately what to do about it. If the works were started, what has been done so far should be communicated. This is another reason why small and frequent commits are a good practice. Everyone has access to the current version of the code and it's easy to pass work.
+
+
+For us, outside observers, we can never judge how much each team has done. For us it is the team that has done something. If you feel that you are doing too much/too little and something is unfair, you can write us about your problems and change the team if necessary.
+
+
+___
+
+## Good practices for team cooperation
+
+* Pair programming
+* Mob programming
+* Peer code review
+* Deliver jobs as quickly as possible. It is better to deliver 4 out of 8 tasks with 2 people working on each other than 0/8 having all started at the same time.
+* No top-down assignments of people to tasks. The person who just has time takes the first task in advance (or one of the first, if not blocked)
+* 1 person can only be assigned 1 task at a time. Only after completing the previous quest can you take another one.
+
+___
+
+## [Agile manifesto](https://agilemanifesto.org)
+
+> We are uncovering better ways of developing
+software by doing it and helping others do it.
+Through this work we have come to value:
+>
+> **Individuals and interactions** over processes and tools
+>
+> **Working software** over comprehensive documentation
+>
+> **Customer collaboration** over contract negotiation
+>
+> **Responding to change** over following a plan
+>
+> That is, while there is value in the items on
+the right, we value the items on the left more.
+
+___
+
+## Q&A
diff --git a/module1/presentation_teamwork.md b/module1/01_teamwork.pl.md
similarity index 98%
rename from module1/presentation_teamwork.md
rename to module1/01_teamwork.pl.md
index d838758..e569a3a 100644
--- a/module1/presentation_teamwork.md
+++ b/module1/01_teamwork.pl.md
@@ -70,7 +70,7 @@ ___
### Przebieg estymacji
* Całym zespołem omawiamy sobie jedno wybrane zadanie, aby mieć pewność, że wszyscy rozumieją je tak samo.
-* Gdy wszyscy są gotowi _jednocześnie_ wyciągają kartę ze swoją estymatą, aby nie sugerować się innymi
+* Gdy wszyscy są gotowi jednocześnie wyciągają kartę ze swoją estymatą, aby nie sugerować się innymi
* Jeśli rozbieżności są duże, to znaczy, że członkowie zespołu mają różne zrozumienie zadania i trzeba jeszcze o nim podyskutować. Warto zapytać osoby z najmniejszą i największą estymatą dlaczego tyle dają.
* Jeśli rozbieżności są małe to można je uśrednić lub wspólnie zgodzić się na którąś wartość (zazwyczaj wyższą)
diff --git a/module1/02_conventions.en.md b/module1/02_conventions.en.md
new file mode 100644
index 0000000..d4b7abf
--- /dev/null
+++ b/module1/02_conventions.en.md
@@ -0,0 +1,398 @@
+
+
+# Conventions
+
+
+
+
+
+___
+
+## Line length
+
+Max 120 characters
+
+
+## Length of the function
+
+Up to 10 lines (+/- 5).
+
+
+If there is more then you need to separate the functionalities into smaller functions.
+
+
+___
+
+
+## Each block (scope) = indent
+
+Any scope that begins with parentheses `{` - even if it is not present, e.g. for one-line ones `if`, `for` - must have an additional level of indentation.
+
+```cpp
+int addEven(const std::vector& numbers)
+{
+ int sum{};
+ for (const auto& el: numbers)
+ {
+ if(el % 2 == 0)
+ sum = sum + el; // bad, no additional indentation
+ }
+ return sum;
+ }
+ ```
+
+ ```cpp
+int addEven(const std::vector& numbers)
+{
+ int sum{};
+ for (const auto& el: numbers)
+ {
+ if(el % 2 == 0)
+ {
+ sum = sum + el; // indentation ok, braces added
+ }
+ }
+ return sum;
+ }
+ ```
+
+___
+
+### Exceptions - `switch/case`
+
+Often with instructions `switch/case` you will see that `case` is on the same level as `switch`. We do not consider this a mistake.
+
+```cpp
+switch (value) {
+case 1: doSth();
+ break;
+default: doSthElse();
+}
+```
+
+___
+
+### Exceptions cont.
+
+* `namespace`
+* access modifiers `public`, `protected`, `private`
+
+```cpp
+namespace shm {
+
+class Ship {
+public:
+ Ship() = default;
+ // ...
+
+private:
+ size_t maxCrew;
+ // ...
+}
+
+} // namespace shm
+```
+
+___
+
+## Types of naming conventions
+
+* lowerCamelCase
+* UpperCamelCase (PascalCase)
+* snake_case (Python convention)
+* kebab-case (rare in C++, often in the front-end)
+
+___
+
+## Hungarian notation - bad practice
+
+In Hungarian notation, type information is contained in the variable name. [Read on the Wiki and never use it](https://pl.wikipedia.org/wiki/Notacja_węgierska)
+
+* ~~`iNumber`~~
+* ~~`szName`~~
+* ~~`lpcszText`~~
+
+___
+
+## Conventions for class members
+
+* postfix _underscore_ `_` behind the name
+* prefix `m_` before the name
+
+Prefixes cannot be used `_`. Any name starting with _underscore_ is reserved for the compiler.
+
+[stackoverflow.com](https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier)
+
+___
+
+## Variable names with prefixes - rather bad practice
+
+* local variable l_variable
+* function parameter p_variable
+* class field m_variable
+* global variables g_variable
+* static variables s_variable
+
+This may seem cool, but it unnecessarily adds 2 characters to the variable name. Instead, it's better to use what's on the next slide.
+
+
+___
+
+## Avoiding prefixes
+
+Note, these are my opinions based on my experience.
+
+* local variable: variable
+ * Functions/code blocks should be small (up to 10 lines). Then we easily find local variables a few lines higher
+* function parameter: variable
+ * For small functions, the parameters are also found a few lines higher without scrolling
+* class member: variable_
+ * The class variables sit in the header file and we would have to switch to a different file to make sure it's a class field. The convention here is postfix `_`
+* global variables: VARIABLE
+ * Uppercase variables/constants are global. There are arguments for not doing this either, but I don't remember them.
+* static variables: s_variable
+ * Prefix here `s_` can stay, because other ways are already taken :)
+
+___
+
+## How to name what?
+
+All this is a matter of convention and may differ from project to project. The most important thing is that it is uniform throughout the project.
+We make the following assumptions.
+
+___
+
+### Classes and structures
+
+* UpperCamelCase
+* noun + adjectives (optional)
+
+```cpp
+class SuperWarrior {}; // ok
+class listenMusic {}; // bad, verb instead of noun. Maybe MusicPlayer?
+```
+
+___
+
+### Variables
+
+* lowerCamelCase
+* noun(s) + adjectives (optional)
+
+```cpp
+SuperWarrior mightyBarbarian; // ok
+int clickCounter; // ok
+```
+
+___
+
+### Functions
+
+* lowerCamelCase
+* verb + adverbs or nouns (optional)
+
+```cpp
+void generateStructure(); // ok
+int calculateCommonSum(); // ok
+```
+
+___
+
+### Class members
+
+* as normal variables
+* additionally _underscore_ `_` after the name
+
+```cpp
+class SuperWarrior
+{
+ int level_ = 1;
+ int strength_ = 50;
+ int dexterity_ = 10;
+ int mana_ = 0;
+};
+```
+
+___
+
+### Filenames
+
+* file name = class name
+* UpperCamelCase / lowerCamelCase / snake_case / kebab-case
+
+`class SuperWarrior` -> SuperWarrior.hpp / SuperWarrior.cpp
+
+___
+
+## Descriptive variable names
+
+Don't name variables like this:
+
+```cpp
+int a = 0; // what is a?
+bool b = false; // what is b?
+
+bool compare(int a, int b); // what does a and b represent?
+```
+
+If you look at this code after a month, you won't know what it does either. This is much better:
+
+
+```cpp
+int counter = 0;
+bool isValid = false;
+
+bool compare(int lhs, int rhs);
+```
+
+___
+
+### Allowed short names
+
+* `i`, `j` - as indexes in loops
+* `it` - as an abbreviation of `iterator`
+* `el`, `elem` - as an abbreviation of `element` in loops over collection
+* `lhs`, `rhs` - as an abbreviation of `leftHandSide` and `rightHandSide` in comparing functions
+
+___
+
+## Types of parentheses
+
+### Egyptian (K&R, Stroustrup)
+
+
+```cpp
+while (x == y) {
+ // do sth;
+}
+```
+
+
+### Allman
+
+
+```cpp
+while (x == y)
+{
+ // do sth;
+}
+```
+
+
+[See others on the wiki and never apply](https://en.wikipedia.org/wiki/Indentation_style)
+
+
+___
+
+### My favorite formatting
+
+Note that this is an opinion! For functions - Allman. For loops and ifs - Egyptian. For classes - whatever. Reason:
+
+```cpp
+class SuperWarrior
+{
+public:
+ SuperWarrior(int level, int strength, int dexterity)
+ : level_(level)
+ , strength_(strength)
+ , dexterity(dexterity)
+ {
+ if (level_ >= 10) {
+ mana_ = 50;
+ }
+ }
+
+private:
+ int level_ = 1;
+ int strength_ = 50;
+ int dexterity_ = 10;
+ int mana_ = 0;
+};
+```
+
+___
+
+Constructor initialization lists or too long names and types of function parameters spoil the readability of the code blocks a little.
+
+For contrast:
+
+```cpp
+class SuperWarrior {
+public:
+ SuperWarrior(int level, int strength, int dexterity)
+ : level_(level)
+ , strength_(strength)
+ , dexterity(dexterity) {
+ if (level_ >= 10) {
+ mana_ = 50;
+ }
+ }
+
+private:
+ int level_ = 1;
+ int strength_ = 50;
+ int dexterity_ = 10;
+ int mana_ = 0;
+};
+```
+
+___
+
+## Sticking `&` and `*`
+
+* left int& ref
+ * okay :)
+* center int & ref
+ * I personally like it
+* right int &ref
+ * avoid
+
+___
+
+## The ternary operator `?:`
+
+One line notation is usually unreadable
+
+
+```cpp
+lhs.size() == rhs.size() ? lhs < rhs : lhs.size() < rhs.size()
+```
+
+
+It is better to write it in two lines.
+
+
+```cpp
+lhs.size() == rhs.size() ? lhs < rhs
+ : lhs.size() < rhs.size()
+```
+
+
+And sometimes even 3 if the condition is long.
+
+
+```cpp
+lhs.name == rhs.name && lhs.amount == rhs.amount && lhs.price == rhs.price
+ ? lhs.value < rhs.value
+ : lhs.price < rhs.price
+```
+
+
+Although IMO its better to use the usual one in the last `if` case.
+
+
+___
+
+## AutoFormat
+
+### `clang-format`
+
+The project should include a file `.clang-format` which will ensure that anyone can apply the formatting it describes automatically
+
+```bash
+clang-format -style=.clang-format -i *.cpp *.hpp
+```
+
+___
+
+## Q&A
diff --git a/module1/presentation_conventions.md b/module1/02_conventions.pl.md
similarity index 100%
rename from module1/presentation_conventions.md
rename to module1/02_conventions.pl.md
diff --git a/module1/03_principles.en.md b/module1/03_principles.en.md
new file mode 100644
index 0000000..92588ab
--- /dev/null
+++ b/module1/03_principles.en.md
@@ -0,0 +1,286 @@
+
+
+# Programming principles
+
+
+
+
+
+___
+
+## Known and liked principles
+
+* Fail-fast
+* Scout rule
+* DRY
+* DRTW
+* KISS
+* YAGNI
+* RTFM
+* No Tests - Don't Touch
+* CQRS
+* 90-90 rule
+* Zen of Python
+
+[More on Wikipedia](https://en.wikipedia.org/wiki/Category:Programming_principles)
+
+
+___
+
+### We will cover this in Best Practice #2
+
+* SOLID
+* GRASP
+* STUPID
+
+___
+
+
+## Fail-fast
+
+Stop the program as soon as possible in case of problems. It's better than it running and crashing due to Undefined Behavior later. Good luck finding the cause in that case.
+
+
+### Allowed things
+
+
+* unhandled exceptions
+* assertions (assert, static_assert)
+* in functions, checking necessary conditions at the beginning
+
+```cpp
+void process(std::shared_ptr value) {
+ if (!value) {
+ return;
+ }
+ // process normally
+}
+```
+
+
+### Pros
+
+
+* minimizing UB (Undefined Behavior)
+* easier debugging and finding the causes of problems
+
+___
+
+## Scout rule
+
+> Always leave the campsite in the same state as you found it.
+
+
+Same with the code as with the camping. If you do mess in the code - you have to clean it up. Cleaning up after others is also very welcome.
+
+
+If you touch someone's code, e.g. by just adding one line - try to improve it.
+
+
+Cleaning should be in a separate commit.
+
+
+### Pros
+
+
+* the code can only get more readable
+* we are not making a technical debt that we will have to pay someday
+
+___
+
+## DRY
+
+### Don't Repeat Yourself
+
+
+Often, duplications are caused by a simple copy-paste operation.
+
+
+Code that is the same or similar in more than 1 place should be extracted into a function and call that function in this place
+
+
+### Pros
+
+
+* easier refactoring - change only in one place
+* less room for mistakes. There is no risk that we will forget some occurrences once we discover a bug
+
+___
+
+## DRTW
+
+### Don't Reinvent The Wheel
+
+
+Do not reinvent the wheel and use already made libraries that provide given functionality.
+
+
+### Pros
+
+
+* usually you are using already tested code
+* less room for incorrect implementations - you may not come up with all test cases
+* saving time
+
+___
+
+
+## KISS
+
+### Keep It Simple, Stupid
+
+
+When writing the code, we do not force the tricks and novelties that may make it more universal and easy for future development, but will reduce its readability.
+
+
+Many seniors have a problem with this and complicate the code unnecessarily. They know from experience that this will make the code easier to modify in the future. What if it will never be modified afterwards, but still read many times?
+
+
+We introduce each "improvement" only when there is such a need. We don't write anything "in advance". See - YAGNI.
+
+
+### Pros
+
+
+* easier to understand code, especially for juniors
+
+___
+
+## YAGNI
+
+### You Aren't Gonna Need It
+
+
+You won't need this. We don't write code in advance, thinking it will come in handy soon. In this way, we generate dead code that is never and probably will not be used.
+
+
+If in the future when a given functionality will be needed, another person will probably implement it (even you will forget that you have already written something after a month and will write it again).
+
+
+### Pros
+
+
+The less code the better:
+
+
+* shorter compilation time
+* less complicated dependencies
+* less to analyze
+* less to remember (that something was made in advance)
+* faster tool use (grep or Ctrl+F have less to scan)
+
+___
+
+## RTFM
+
+### Read The F*cking Manual 😉
+
+
+Before you start spamming people with questions about a given functionality/tool, read the manual.
+
+
+In Linux, for the tool `tool` use `tool --help` and `man tool`.
+
+
+If, after reading the documentation, you still don't know what to do, then ask others (team members, stackoverflow, other forum, Discord Coders School 😉)
+
+
+### Pros
+
+
+* More experienced people often have a tight calendar, so they will be grateful if you find a solution on your own or shortly explain problem 😉
+
+___
+
+## No Tests - Don't Touch
+
+If you want to fix a piece of code but it's not tested, write some tests first.
+
+
+If you "improve" or "correct" code that has not been tested, how do you prove that its behavior has not changed after your changes?
+
+
+Never change the implementation and tests for it at the same time. If the tests stop passing, you won't know whether it's because of a broken implementation or broken tests. Tests test the implementation, and the implementation tests the tests.
+
+
+### Pros
+
+
+* saving yourself potential problems and time
+* writing tests and refactoring will take less time than refactoring without tests (seriously)
+
+___
+
+## CQRS
+
+### Command Query Responsibility Segregation
+
+
+Separate writing from reading.
+
+
+* Query - getting (reading) data - getters
+* Command - working on data (write)
+
+We should avoid methods that do both because:
+
+
+> Asking a question should not change the answer
+>
+> -- * Bertrand Meyer *
+
+
+___
+
+## Rule 90-90
+
+You will complete 90% of the tasks within 90% of the time allocated to them.
+
+
+The remaining 10% of the tasks will be completed in the remaining 90% of the time.
+
+
+Useful when assessing the progress of work.
+
+
+At first the work goes quite easy (the general outline of the task), but then edge cases get discovered which were unthought of before, due to which task will take longer time than expected.
+
+
+___
+
+
+## Zen of Python
+
+```python
+import this
+```
+
+
+```text
+The Zen of Python, by Tim Peters
+
+Beautiful is better than ugly.
+Explicit is better than implicit.
+Simple is better than complex.
+Complex is better than complicated.
+Flat is better than nested.
+Sparse is better than dense.
+Readability counts.
+Special cases aren't special enough to break the rules.
+Although practicality beats purity.
+Errors should never pass silently.
+Unless explicitly silenced.
+In the face of ambiguity, refuse the temptation to guess.
+There should be one-- and preferably only one --obvious way to do it.
+Although that way may not be obvious at first unless you're Dutch.
+Now is better than never.
+Although never is often better than *right* now.
+If the implementation is hard to explain, it's a bad idea.
+If the implementation is easy to explain, it may be a good idea.
+Namespaces are one honking great idea -- let's do more of those!
+```
+
+
+___
+
+## Q&A
diff --git a/module1/presentation_principles.md b/module1/03_principles.pl.md
similarity index 99%
rename from module1/presentation_principles.md
rename to module1/03_principles.pl.md
index 92d17ad..b12f76d 100644
--- a/module1/presentation_principles.md
+++ b/module1/03_principles.pl.md
@@ -84,7 +84,7 @@ Sprzątanie ma być w osobnym commicie.
* kod może być tylko coraz czytelniejszy
-* nie robimy długu technicznego, który kiedyś trzeba będzie spałcić
+* nie robimy długu technicznego, który kiedyś trzeba będzie spłacić
___
diff --git a/module1/04_practices.en.md b/module1/04_practices.en.md
new file mode 100644
index 0000000..9f2e801
--- /dev/null
+++ b/module1/04_practices.en.md
@@ -0,0 +1,268 @@
+
+
+# Good practices
+
+
+
+
+
+___
+
+## Riddle
+
+Tom got 3 apples, but he ate 2. How many apples does Tom have?
+
+
+### The answer
+
+
+We don't know, because we don't know how many he had before he got 3 apples.
+
+
+### Conclusion
+
+
+Always initialize variables.
+
+
+```cpp
+int a;
+a += 3;
+a -= 2;
+std::cout << a << '\n';
+```
+
+
+___
+
+## Always initialize variables
+
+```cpp
+int index = 0; // ok
+bool completed; // bad
+bool finished = false; // ok
+
+if (completed) { // very bad
+ // ...
+}
+
+struct Node {
+ Node* next = nullptr; // ok
+ int value = 0;
+}
+```
+
+___
+
+## Define your own types
+
+Code full of domain names (own types) is easier to read. Also people who do not deal with programming on a daily basis can deduce a lot from it.
+
+
+Check out these 2 functions:
+
+
+```cpp
+std::vector> compressGrayscale(std::array, height>&);
+std::array, height> decompressGrayscale(std::vector>&);
+```
+
+
+And compare to this:
+
+
+```cpp
+CompressedImage compressGrayscale(const Image& bitmap);
+Image decompressGrayscale(const CompressedImage& compression);
+```
+
+
+To achieve this, you just have to give different names to the types like this:
+
+
+```cpp
+using Image = std::array, height>;
+using CompressedImage = std::vector>;
+```
+
+
+___
+
+## Forward declarations
+
+Use forward declarations where possible instead of `#include`.
+
+
+In order to use an object, the compiler needs information about its size.
+
+
+```cpp
+#include "Fruit.hpp"
+
+int main() {
+ Fruit apple;
+ // ...
+}
+```
+
+
+So in order to be able to create a local variable, it needs to know its size. So it must have a proper header where this class is defined to know the size of such a variable on the stack.
+
+
+___
+
+### Riddle
+
+* What size is the pointer on int?
+* What size is the pointer on Fruit?
+
+### Answer
+
+
+The size of the pointer does not depend on the type it points to. Usually it is 4 or 8 bytes long (for 32 and 64 bit processors respectively).
+
+
+___
+
+### Unknown object size
+
+Each pointer and reference have the same size. As long as we use them and do not refer to any methods or fields of the class, we do not need information about its size or content.
+
+
+```cpp
+class Fruit; // class forward declaration
+
+void pass(Fruit* fruit) {
+ if (!fruit) {
+ return;
+ }
+ // do sth;
+}
+```
+
+
+In that case, we just need to tell the compiler that the pointer type is our class by means of a forward declaration. You do not need to apply `#include` and we speed up compilation.
+
+
+___
+
+However, if we refer to a field or method of this object, the compiler tells us that it has incomplete information.
+
+```cpp
+class Fruit;
+
+unsigned getFruitPrice(Fruit* fruit) {
+ if (!fruit) {
+ return 0u;
+ }
+ return fruit->getPrice(); // compilation error
+}
+```
+
+
+In this case, the correct heading must be attached.
+
+
+___
+
+## We avoid implicit conversions
+
+```cpp
+class Apple {
+ int weight_;
+public:
+ Apple(int weight); // possible conversion from int to Apple
+};
+
+void takeApple(Apple a);
+
+int main() {
+ takeApple(150); // int converted implicitly into Apple
+}
+```
+
+
+___
+
+### Avoiding Implicit Conversions
+
+Keyword `explicit` prohibits implicit conversions. They are used with constructors that may accidentally convert from the type of argument they take.
+
+
+```cpp
+class Apple {
+ int weight_;
+public:
+ explicit Apple(int weight);
+};
+
+void takeApple(Apple a);
+
+int main() {
+ takeApple(150); // compilation error, expected Apple, got int
+}
+```
+
+
+___
+
+## `explicit`
+
+Keyword `explicit` is used for:
+
+* unary constructors
+ * `explicit Apple(int weight);`
+* multi-argument constructors, with one non-default argument
+ * `explicit Apple(int weight, int size = 1);`
+* conversion operators
+ * `explicit operator int() const { return weight_; }`
+
+___
+
+## Reading and application [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md)
+
+___
+
+## F: Functions
+
+* F.1: "Package" meaningful operations as carefully named functions
+* F.2: A function should perform a single logical operation
+* F.3: Keep functions short and simple
+* F.4: If a function may have to be evaluated at compile time, declare it `constexpr`
+* F.5: If a function is very small and time-critical, declare it `inline`
+* F.6: If your function may not throw, declare it `noexcept`
+* F.9: Unused parameters should be unnamed
+* F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to const
+* F.17: For "in-out" parameters, pass by reference to non-const
+* F.20: For "out" output values, prefer return values to output parameters
+* F.21: To return multiple "out" values, prefer returning a struct or tuple
+* F.60: Prefer `T*` over `T&` when "no argument" is a valid option
+* F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed
+* F.27: Use a `shared_ptr` to share ownership
+
+___
+
+## C: Classes and class hierarchies
+
+* C.1: Organize related data into structures (structs or classes)
+* C.2: Use class if the class has an invariant; use struct if the data members can vary independently
+* C.7: Don't define a class or enum and declare a variable of its type in the same statement
+* C.8: Use class rather than struct if any member is non-public
+* C.9: Minimize exposure of members
+
+___
+
+## Enum: Enumerations
+
+* Enum.1: Prefer enumerations over macros
+* Enum.2: Use enumerations to represent sets of related named constants
+* Enum.3: Prefer enum classes over "plain" enums
+* Enum.4: Define operations on enumerations for safe and simple use
+* Enum.5: Don't use ALL_CAPS for enumerators
+* Enum.6: Avoid unnamed enumerations
+* Enum.7: Specify the underlying type of an enumeration only when necessary
+* Enum.8: Specify enumerator values only when necessary
+
+___
+
+## Q&A
diff --git a/module1/presentation_practices.md b/module1/04_practices.pl.md
similarity index 96%
rename from module1/presentation_practices.md
rename to module1/04_practices.pl.md
index 2dc8d88..24a77f2 100644
--- a/module1/presentation_practices.md
+++ b/module1/04_practices.pl.md
@@ -189,7 +189,6 @@ ___
Słowo kluczowe `explicit` zabrania niejawnych konwersji. Stosuje się je przy konstruktorach, które mogą przypadkiem spowodować konwersję z typu argumentu który przyjmują.
-
```cpp
class Apple {
int weight_;
@@ -229,17 +228,17 @@ ___
* F.1: "Package" meaningful operations as carefully named functions
* F.2: A function should perform a single logical operation
* F.3: Keep functions short and simple
-* F.4: If a function may have to be evaluated at compile time, declare it constexpr
-* F.5: If a function is very small and time-critical, declare it inline
-* F.6: If your function may not throw, declare it noexcept
+* F.4: If a function may have to be evaluated at compile time, declare it `constexpr`
+* F.5: If a function is very small and time-critical, declare it `inline`
+* F.6: If your function may not throw, declare it `noexcept`
* F.9: Unused parameters should be unnamed
* F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to const
* F.17: For "in-out" parameters, pass by reference to non-const
* F.20: For "out" output values, prefer return values to output parameters
* F.21: To return multiple "out" values, prefer returning a struct or tuple
-* F.60: Prefer T* over T& when "no argument" is a valid option
-* F.26: Use a unique_ptr to transfer ownership where a pointer is needed
-* F.27: Use a shared_ptr to share ownership
+* F.60: Prefer `T*` over `T&` when "no argument" is a valid option
+* F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed
+* F.27: Use a `shared_ptr` to share ownership
___
diff --git a/module1/05_homework.en.md b/module1/05_homework.en.md
new file mode 100644
index 0000000..def1a38
--- /dev/null
+++ b/module1/05_homework.en.md
@@ -0,0 +1,41 @@
+
+
+# C++ basics
+
+## Summary
+
+
+
+
+
+___
+
+## What do you remember from today?
+
+### Write as many keywords as possible in the chat
+
+
+1. Teamwork
+2. Conventions
+3. Cpp Core Guidelines
+4. Good practices
+
+___
+
+## Homework
+
+### Pre-work
+
+* Recall how to build a project in Debug mode
+* Watch [this video about debugging](https://www.youtube.com/watch?v=gFCQ37jVN3g)
+* Make sure you have installed `gdb` debugger
+* Play around with `gdb` or [onlinegdb.com](http://onlinegdb.com)
+
+___
+
+### Post-work
+
+* Apply what you've learned in all your previous projects and homeworks. You don't need to re-submit PR, but ask other people for a review if you have any doubts.
+* From now on, when doing reviews to other people, pay attention to the best practices presented 🙂
+* From boredom, return to tasks on [Firecode.io](https://www.firecode.io) 🙂
+* Review the headings from [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), and in your spare time read as much as you can 🙂
diff --git a/module1/presentation_homework.md b/module1/05_homework.pl.md
similarity index 89%
rename from module1/presentation_homework.md
rename to module1/05_homework.pl.md
index 9bc986c..37e91f4 100644
--- a/module1/presentation_homework.md
+++ b/module1/05_homework.pl.md
@@ -29,13 +29,13 @@ ___
* Przypomnij sobie jak zbudować projekt w trybie Debug
* Obejrzyj [to wideo o debugowaniu](https://www.youtube.com/watch?v=gFCQ37jVN3g)
* Upewnij się, że masz zainstalowany debugger `gdb`
-* Pobaw się debuggerem gdb lub [onlinegdb.com](http://onlinegdb.com)
+* Pobaw się debuggerem `gdb` lub [onlinegdb.com](http://onlinegdb.com)
___
### Post-work
* Zastosuj poznaną wiedzę we wszystkich dotychczasowych projektach i pracach domowych. Nie musisz zgłaszać ponownie PR, ale poproś inne osoby o review, jeśli masz jakieś wątpliwości.
-* Od teraz robiąc review innym osobom zwracaj uwagę na przedstawione dobre praktyki :)
-* Z nudów powróć do zadań na [Firecode.io](https://www.firecode.io) :)
-* Przejrzyj nagłówki z [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), a w wolnych chwilach czytaj ile się da :)
+* Od teraz robiąc review innym osobom zwracaj uwagę na przedstawione dobre praktyki 🙂
+* Z nudów powróć do zadań na [Firecode.io](https://www.firecode.io) 🙂
+* Przejrzyj nagłówki z [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), a w wolnych chwilach czytaj ile się da 🙂
diff --git a/module1/index.en.html b/module1/index.en.html
new file mode 100644
index 0000000..8345dca
--- /dev/null
+++ b/module1/index.en.html
@@ -0,0 +1,121 @@
+
+
+
+
+
+
+ Good practices - Coders School
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+