Initial commit

2 files changed, 270 insertions, 0 deletions

diff --git a/blog/git.md b/blog/git.md
new file mode 100644
index 0000000..20f1b73
--- /dev/null
+++ b/blog/git.md
@@ -0,0 +1,113 @@
+# Гайд по работе с Git
+
+## Основные команды
+- - -
+
+### Клонирование репозитория
+
+`git clone git@github.com:<твой-никнейм>/<репозиторий>.git`
+
+После выполнения clone будет автоматически создан remote с названием origin с
+указанным url Для обновления форка необходимо добавить remote с апстримом.
+
+### Добавление главного репозитория для обновления master ветки
+
+`git remote add upstream https://github.com/<имя>/<репозиторий>.git`
+
+### Коммит последних изменений
+
+```
+git status  # Посмотреть все текущие staged и unstaged изменения
+git add .   # Сделать все unstaged изменения staged
+git commit  # Сделать коммит с развёрнутым сообщением. При вызове из терминала
+            # откроется какой-нибудь текстовый редактор, в котором можно
+            # написать полное сообщение. При выходе из редактора коммит
+            # делается с последним сохранённым сообщением.
+git commit -m "<сообщение>" # Добавить коммит с кратким сообщением
+```
+
+### Сохранение текущих изменений
+
+Это необходимо для избежания лишних конфликтов во время merge/pull
+
+```
+git stash        # Сохранить изменения в stash
+git stash list   # Вывести все сохранённые изменения
+git stash pop    # Достать последние изменения
+git stash pop 0  # Применить изменения под номером 0
+git stash drop   # Удалить изменения из стека
+```
+
+### Обновление ветки из апстрима
+
+```
+git pull upstream master
+git pull upstream develop
+```
+
+### Создание ветки под новое изменение
+
+`git checkout -b <тип фичи>/<краткое описание изменения>`
+
+### Переключение на существующую ветку
+
+`git checkout <название ветки>`
+
+### Объединение веток
+
+Внесение изменений из `<название ветки>` в текущую:
+`git merge <название ветки>`
+
+Если при создании пулл-реквеста появились конфликты, то следует
+сначала обновить master из апстрима, после чего внести полученные изменения
+в текущую ветку.
+
+```
+git stash  # Сохранить текущие незакоммиченные изменения на этой ветке
+git checkout master
+git pull upstream master
+git checkout <branch>
+git merge master
+git stash pop  # Заново применить изменения, сохранённые с помощью
+               # команды git stash
+```
+
+### Загрузка своих изменений на сервер
+
+```
+git push -u origin <название ветки>  # При первой загрузке этой ветки
+git push  # Во все последующие разы
+```
+
+### Что нужно выяснить самому
+
+- Как выглядят конфликты и как их решать.
+- Как создать пулл реквест.
+
+## Процесс работы с репозиторием
+- - -
+
+Для разработки своей фичи следует сделать форк главного репозитория и
+после этого работать только со своей версией. После этого клонируешь свой
+форк и работаешь с ним. Также в склонированный репозиторий нужно добавить
+дополнительный remote под названием upstream (на самом деле название может
+быть любым), чтобы синхронизироваться с... апстримом.
+
+При начале работы над новой фичей создаётся новая ветка (именованная по
+указанным в основном документе правилам). **Новая ветка создаётся на основе
+develop, а не master**. В неё делаются какие-то коммиты. Когда работа над фичей
+завершена, необходимо перейти на develop ветку **форка** и синхронизировать её
+с апстримом: `git pull upstream develop`. После этого нужно выполнить слияние
+ветки с фичей и master и решить все возникшие конфликты.
+
+Только после этого делается Pull Request в главный репозиторий. Ветка источник
+--- ветка с фичей, ветка приёмник --- develop ветка в главном репозитории. 
+В случае, если снова возникли конфликты --- переходим к предыдущему параграфу.
+
+Если же всё хорошо и есть возможность автоматического слияния, то нужно указать
+Reviewers чтобы кто-то мог разобрать по частям тобою написанное.
+
+Когда пулл реквест принят и слит в develop, переходишь к своему локальному
+репозиторию и снова синхронизируешься с апстримом. После этого можно приступать
+к разработке новой фичи.
+
diff --git a/blog/yuydev.md b/blog/yuydev.md
new file mode 100644
index 0000000..c7584fc
--- /dev/null
+++ b/blog/yuydev.md
@@ -0,0 +1,157 @@
+# Вступительное слово
+
+## Что делать
+- - -
+
+Найти в глобальном поиске groups.google.com нашу группу yuydev@googlegroups.com
+и подать в неё заявку на вступление. После этого в гугл диске появится
+директория Yuydev в которой можно создавать и сохранять основные
+документы/ассеты связанные с игрой.
+
+## Про архитектуру движка
+- - -
+
+Очень настоятельно рекомендую почитать что-то про 
+[ECS](https://en.wikipedia.org/wiki/Entity_component_system).
+Если вкратце --- основные термины:
+
+- Entity (Объект): по факту является уникальным идентификатором объекта, а 
+  именно --- целым числом, которое является индексом в списке всех объектов;
+- Component (Компонент): структура с некоторыми данными в которых содержится
+  состояние объекта. Например, в компоненте `Transform` могут содержаться
+  координаты объекта, а в компоненте `Collider` --- размеры коллайдера;
+- System (Система): какая-то функция, которая изменяет состояние объекта с 
+  определёнными компонентами. Например, система `movePlayer` может обновлять
+  состояние объектов, у которых есть компоненты `Transform` и `Player`, а
+  система `moveEnemy` --- `Transform` и `Enemy`.
+
+## Стек технологий
+- - -
+
+Игра и движок будут писаться на C++, а проект собираться с помощью make
+(**не cmake!!!**). В качестве IDE для разработки стоит выбрать Jetbrains CLion,
+а про Visual Studio забыть. Студенческую лицензию для CLion можно получить на
+сайте [Jetbrains](https://www.jetbrains.com/shop/eform/students). Если
+активирована почта на домене sgu.ru, то можно использовать её и получить
+лицензию за несколько минут. Иначе, можно использовать студак во вкладке
+Official Document, но тогда придётся подождать несколько дней.
+
+Для работы с графикой, со звуком и остальными мультимедийными вещами будет
+использоваться библиотека [SFML](https://www.sfml-dev.org/). Для её изучения
+можно почитать [туториалы](https://www.sfml-dev.org/tutorials/2.5/) на
+официальном сайте. Они на английском языке, но к этому придётся привыкать.
+
+В целом, в данном проекте я рассчитываю на то, что мы будем использовать
+минимальное количество внешних библиотек. В идеале --- ограничиться только
+SFML. Другие библиотеки стоит добавлять только в самом-самом крайнем случае,
+если проблема требует действительно очень большого количества кода и каких-то
+продвинутых знаний. На данный момент, единственный кандидат в качестве
+дополнительной внешней библиотеки --- это парсер какого-нибудь языка разметки
+(например, json).
+
+Для сборки проекта на винде нужно будет установить 
+[mingw-w64](http://mingw-w64.org/doku.php) и 
+[GNU make](https://www.gnu.org/software/make/). И после этого каким-то образом
+это настроить так, чтобы проект действительно собирался. Пока что этим никто
+не занимался, поэтому именно ты --- читатель --- можешь стать первым!
+
+## Оформление в различных частях проекта
+- - -
+
+### Оформление кода (будет дополняться)
+```
+void
+someFunctionName(int param1, int param2)
+{
+    int someArray = { 1, 2, 3 };
+    const std::type_index anotherArray = 
+    { TYPE(EnemyController)
+    , TYPE(Transform)
+    , TYPE(PlayerController
+    };
+
+    if (true || false)
+    {
+        callOtherFunction(12345);
+    }
+    for (int i = 0; i < 20; ++i)
+    {
+        // TODO(andrew): Добавить большее количество обработчиков.
+        switch (param1)
+        {
+            case 1: 
+            {
+                std::string name = "World"
+                std::cout << "Hello, " << name << std::endl;
+            } break;
+            case 2: 
+            {
+                // NOTE(andrew): Приветствую только себя потому что могу!
+                std::string name = "Andrew"
+                std::cout << "Hi, " << name << std::endl;
+            } break;
+            default: 
+            {
+                std::cout << "Greeting is undefined" << std::endl;
+            } break;
+        }
+    }
+}
+```
+
+Моменты, на которые необходимо обратить внимание:
+
+- В названиях используется [CamelCase](https://ru.wikipedia.org/wiki/CamelCase);
+- Все фигурные скобки находятся на отдельной строке;
+- Тип возвращаемого значения функции находится на отдельной строке;
+- Блоки кода обозначаются **везде**, даже в ифе с одной командой;
+- Немного необычное оформление кейсов в свитче;
+- **Забудьте про using namespace std**;
+- Длина строки не превышает 80 символов (в некоторых случаях можно позволить
+  120 символов, но эти случаи рассматриваются отдельно в каждом случае);
+- Оформление литералов массивов в случае, если элементы умещаются в одну
+  строку и в случае, когда не умещаются (аналогичное оформление применяется к
+  параметрам функций);
+- Комментарии на русском языке.
+
+Также можно заметить, что в комментариях есть конструкции `TODO(имя)` и
+`NOTE(имя)`. Комментарии такого вида обычно распознаются в IDE и, например,
+по TODO-комментария можно искать части проекта, в которых следовало бы
+добавить какие-то вещи, которые могут быть не обязательны для сборки и работы
+проекта в данный момент, но могут привести к неожиданным ошибкам. Например,
+обработку ошибок/исключений можно отложить на потом, но чтобы не забыть о
+том, что такая необходимость существует, надо добавить комментарий `TODO(имя)`
+и через двоеточие указать чего именно не хватает.
+
+### Работа с git
+
+При начале работы над новой фичей следует создать новую ветку. У названия
+ветки будет какой-то префикс, соответствующий типу того, что в этой ветке
+разрабатывается, а после него указывается *очень короткое* описание самой
+фичи (два -- три слова). Название ветки полностью нижним регистром, а слова
+разделяются тире (!!!). Примеры:
+
+- feature/new-interface;
+- feature/player-controller-update;
+- fix/physics-system-bug.
+
+Во время разработки фичи можете создавать сколько угодно коммитов, так как
+при слиянии с основной веткой будет использоваться squash. Не нужно создавать 
+огромное количество коммитов на каждый чих, но и не нужно делать один огромный
+коммит в котором находятся абсолютно все изменения. Git --- это ваш друг,
+который поможет откатиться до предыдущего рабочего коммита, если что-то
+непоправимо сломалось (или просто получилось какое-то говно, которое лучше
+выкинуть, забыть и начать с начала).
+
+Не рекомендуется работа в одной ветке сразу двух людей, так как это 
+**неизбежно** приведёт к бесконечным конфликтам при автоматическом слиянии.
+
+В тексте squash-коммита следует указывать что именно было изменено. Первая
+строка коммита является чем-то вроде заголовка, а весь остальной текст
+следует оформлять в виде Markdown с подробным описанием новых фич.
+
+Текст коммита пишется на русском языке.
+
+Основные команды и процесс работы с нашим репозиторием можно прочитать
+[тут](git.html).
+