The chirickello from ddrv

Hello world!

I am PHP developer from Kaliningrad (Russian Federation). Here I publish my pet projects.

Sometimes I publish articles on habr.com. The source code for these articles can be found here.

chirickello's People

Contributors

Watchers

chirickello's Issues

week0 homework

Смириться с абсурдом топ-менеджмента UberPopug Inc. Прочитать требования. Если что-то непонятно — пишите на почту [email protected].
Создать репозиторий в гитхабе, пригласить туда f213 и davydovanton. Ссылку на созданный репозиторий приcлать на [email protected] или в чатик на сайте (синий кружок с сердечком в правом нижнем углу). Не забудьте указать емейл, на который покупали курс, чтобы мы поняли, кто вы такой.
Создайте черновой проект системы так, как вы видите её сейчас, до старта обучения. Не заморачивайтесь с проработкой, не бойтесь ошибиться — мы это делаем, чтобы вы в конце обучения сравнили «было» и «стало».
Подойдёт любой инструмент для рисования квадратиков, к примеру LucidChart или Miro + текст о том, как это потенциально работает. Писать код не нужно. Минимальные требования к проекту:
Выбрать сервисы, минимально должно быть 2+ сервисов — мы всё-таки асинхронную архитектуру делаем. Желательно обосновать почему были выбраны именно такие сервисы. И чем каждый должен заниматься.
Описать коммуникации между сервисами — вид (синхронный\асинхронный) и данные которые будут передаваться в коммуникациях (хватит основных полей, детали в духе id, created_at и прочие технические поля можно опустить).
Описать как решать проблемы, которые могут возникнуть с данными. Что делать, если упадет сеть, база данных и так далее.
Описать спорные места и (или) места, которые вам кажутся критичными на данный момент.

homework week 3

Мы отдали часть системы из авторизации и таск трекера бизнесу. Спустя 15 минут бизнес попросил внести необходимые доработки после фидбэка.
- Во время работы с таск трекером, мы поняли, что попуги часто в title задачи пишут конструкцию [jira-id] - Title (Пример: "UBERPOP-42 — Поменять оттенок зелёного на кнопке"). В результате чего поэтому нам необходимо разделить title на два поля: title (string) + jira_id (string). При этом, для всех новых событий, необходимо убедиться что jira-id не присутствует в title. Для этого достаточно сделать валидацию на наличие квадратных скобок (] или [)
  - Поправить события на отправку задач в событиях и поменять код в сервисах
  - Расписать процесс миграции на новую логику
  - Выбрать формат серелизации данных и схемы. На выбор: avro, protobuf или json/xml schema.
  - Выбрать реализацию schema registry и эволюции данных. Можно взять готовое решение (http://github.com/davydovanton/event_schema_registry), а можно написать свое.
  - Имплементация системы аккаунтинга/биллинга + всех событий необходимых для работы системы
  - Имплементация системы аналитики (можно без UI показывать все) + всех событий необходимых для работы системы
  - Создать место со всеми схемами и перевести все существующие схемы в типизированный формат с нужной версией
Так как начальники боятся потерять денег, они попросили гарантировать, что ни один $$$ не потеряется в системе.
- Выбрать стратегию обработки ошибок в событиях связанных с системой аккаунтинга, что бы быть уверенным, что все события превратятся в деньги и расписать как именно должна выглядеть эти стратегии.

week2 homework

Выбрать логику аунтификации в системе. Можно использовать любой из способов аутентификации, Антон советует попробовать oAuth, а Федя — JWT HTTP API интерфейс.
Выбрать message broker и развернуть его локально
Написать сервис авторизации. Можно написать его с нуля самому, а можно взять готовый из гитхаб-репозитория с примером inventory-системы.
Реализовать логику таск-трекера
Связать сервис авторизации и логику таск трекера, а так же реализовать все события которые должны быть отправлены и прочитаны в каждом из двух сервисов
Отправить первое событие в систему и прочитать его в другом сервисе

week1 homework

Положить все, что вы сделали к нулевому уроку в отдельную папку или отдельный файл. Нам важно сохранить все так как есть сейчас, что бы вернуться к этому проектированию в конце курса для сравнения как было в начале и как получилось в конце. Сейчас мы спроектируем ту же систему по новой, используя подходы из курса. А в следующих неделях реализуем то, что будем сейчас проектировать.
Разобрать каждое требование на составляющие (актор, команда, событие, query). Определить, как все бизнес цепочки будут выглядеть и на какие шаги они будут разбиваться.
Построить модель данных для системы и модель доменов. Рисовать можно в любом удобном инструменте (включая обычную бумагу), главное, чтобы это было не только у вас в голове, но и где-то вовне. Благодаря этому вы сможете сфокусироваться на отдельной части системы, не думая о других. А также показать свое решение одногрупникам/коллегам.
Определить, какие общие данные нужны для разных доменов и как связаны данные между разными доменами.
Разобраться, какие сервисы, кроме тудушника, будут в нашей системе и какие между ними могут быть связи (как синхронные, так и асинхронные).
Определить все бизнес события, необходимые для работы системы. Отобразить кто из сервисов является продьюсером, а кто консьюмером бизнес событий.
Выписать все CUD события и какие данные нужны для этих событий, которые необходимы для работы системы. Отобразить кто из сервисов является продьюсером, а кто консьюмером CUD событий.

Recommend Projects