"`, Output: `div`
87 | * Input: `"
abc
test test test
"`, Output: `i`
88 |
89 | 1. **K Unique Characters**: Have the function `KUniqueCharacters(str)` take the `str` parameter being passed and find the longest substring that contains `k` unique characters, where `k` will be the first character from the string. The substring will start from the second position in the string because the first character will be the integer `k`.
90 |
91 | For example: if `str` is `"2aabbacbaa"` there are several substrings that all contain 2 unique characters, namely: `["aabba", "ac", "cb", "ba"]`, but your program should return `"aabba"` because it is the longest substring. If there are multiple longest substrings, then return the first substring encountered with the longest length. `k` will range from 1 to 6.
92 |
93 | Examples:
94 |
95 | * Input: `"3aabacbebebe"`, Output: `"cbebebe"`
96 | * Input: `"2aabbcbbbadef"`, Output: `"bbcbbb"`
97 |
98 | 1. **Сумма квадратов**: Программа должна вернуть строку `'true'`, если заданное число является суммой квадратов и `'false'`, если не является.
99 |
100 | Например:
101 |
102 | * 25 должно вернуть `'true'`, потому что `25 = 3² + 4²`
103 | * 1601 должно вернуть `'true'`, потому что `1601 = 40² + 1²`
104 |
105 | 1. **Сравнение массивов**: Даны два массива массивов. Сравнить массивы и вернуть `true`, если массивы массивов одинаковы. Элементы в массиве могут быть переставлены местами, и значения внутри этих массивов могут тоже быть переставлены.
106 |
107 | Например:
108 | * ```# func([[5, 0], [5, 0], [5, 0]], [[5, 0], [5, 0], [0, 5]]) #=> true```
109 | * ```# func([[2, 3], [5, 0]], [[5, 0], [3,2]]) #=> true```
110 |
111 | 1. **Покупка/продажа зерна**: Дан массив с ценами на зерно по дням. Цена покупки и продажи одинакова в этот день. Найти **индексы дня** покупки и последующей продажи для получения максимальной выгоды.
112 |
113 | Вернуть массив из 2х элементов: индекс дня покупки и индекс дня продажи или пустой массив.
114 |
115 | Например:
116 | * ``` profit([13, 6, 3, 4, 10, 2, 3]) #=> [2, 4] ```
117 | * ``` profit([13, 6, 3, 1]) #=> [] ```
118 |
119 | 1. **Сумма цифр**: Написать функцию, которая принимает на вход число, суммирует цифры в нём, потом, если получилось число из 2 и более цифр, суммирует цифры в нём и так далее, пока не получится однозначное число, которе функция возвращает. Такое число называется «цифровым корнем» исходного числа.
120 |
--------------------------------------------------------------------------------
/interview/webdev.md:
--------------------------------------------------------------------------------
1 | # Вопросы по веб-разработке с собеседований
2 |
3 | 1. Что происходит после того, как вы вводите название сайта в браузер и нажимаете Enter? Подробно объяснить.
4 |
5 | Ответ
6 |
7 | #### *1. Парсинг URL - можно отнести к условно первому этапу (не считая самого процесса ввода символов в поисковом поле браузера), во время которого*:
8 | - Браузер проверяет список предзагруженных HSTS (HTTP Strict Transport Security). Это список сайтов, которые требуют, чтобы к ним обращались только по HTTPS. Если нужный сайт есть в этом списке, то браузер отправляет ему запрос через HTTPS вместо HTTP. В противном случае, начальный запрос посылается по HTTP.
9 | - Конвертируются не-ASCII Unicode символы в название хоста.
10 |
11 | #### *2. Следующий этап - Определение DNS*
12 | - Браузер проверяет наличие домена в своём кэше. Если домена там нет, то браузер вызывает библиотечную функцию *gethostbyname* (отличается в разных ОС) для поиска нужного адреса в файле *hosts*.
13 | - Если домен нигде не закэширован и отсутствует в файле hosts, gethostbyname отправляет запрос к сетевому DNS-серверу.
14 | - Запрос к сетевому DNS-серверу называется ARP-запросом.
15 | - Для того, чтобы отправить ARP-запрос браузеру необходимо отыскать целевой IP-адрес, а также знать MAC-адрес интерфейса, который будет использоваться для отправки ARP-запроса.
16 |
17 | #### *3. Открытие сокета и сборка TCP-сегмента/пакета*
18 | - Когда браузер получает IP-адрес конечного сервера, то он берёт эту информацию и данные об используемом порте из URL (80 порт для HTTP, 443 для HTTPS), осуществляет вызов функции socket системной библиотеки и запрашивает поток TCP сокета.
19 | - Этот запрос сначала проходит через транспортный уровень, где собирается TCP-сегмент. Получившийся сегмент отправляется на сетевой уровень, на котором добавляется дополнительный IP-заголовок, IP-адрес сервера назначения и адрес текущей машины — теперь сегмент сформирован.
20 |
21 | #### *4. TLS handshake — для передачи пакетов данных между клиентом (компьютером) и сервером важно установить TCP-соединение. Это соединение устанавливается с помощью процесса, называемого трехсторонним рукопожатием TCP / IP, реализованного следующим образом*:
22 |
23 | - Клиентская машина отправляет SYN-пакет на сервер, спрашивая, открыт ли он для новых подключений.
24 | - Если на сервере есть открытые порты, которые могут принимать и инициировать новые соединения, он ответит, используя пакет SYN / ACK.
25 | - Клиент получит пакет SYN / ACK от сервера и подтвердит его, отправив пакет ACK.
26 |
27 | #### *5. Обработка HTTP-запросов на сервере*
28 | - Одним из инструментов обработки запросов/ответов на стороне сервера является HTTPD. Наиболее популярные HTTPD-серверы это Apache или Nginx для Linux и IIS для Windows.
29 | - Сервер разбирает запрос по следующим параметрам: метод HTTP-запроса (наиболее распространенные — GET/POST), домен, запрашиваемые пути.
30 | - Сервер находит контент, который соответствует запросу и парсит файл с помощью обработчика.
31 |
32 | #### *6. Парсинг HTML и интерпретация CSS*
33 | - Главной задачей HTML-парсера является разбор разметки в специальное дерево — «parse tree» — это дерево DOM-элементов.
34 | - Во время разбора браузер парсит CSS-файлы, каждый из которых разбирается в объект StyleSheet.
35 |
36 | #### *7. Рендеринг страниц и пост-рендеринговое исполнение*
37 | - Путём перебора DOM-узлов и вычисления для каждого узла значений CSS-стилей создаётся «Дерево рендера» (Render Tree или Frame Tree).
38 | - Вычисляются координаты каждого узла. Вычисляются финальные позиции слоёв и через Direct3D/OpenGL отдаются композитные команды.
39 | - После завершения рендеринга, браузер исполняет JavaScript-код в результате срабатывания часового механизма или в результате действий пользователя.
40 |
41 | #### *Для более детального ознакомления:*
42 | - https://habr.com/ru/company/htmlacademy/blog/254825/
43 | - https://github.com/alex/what-happens-when
44 | - https://medium.com/@maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a
45 |
46 |
47 | 1. Что такое сессия? Для чего используется?
48 | 1. Что такое процессы? Как с ними работать?
49 | 1. Что такое DNS?
50 | 1. Настройка http-серверов.
51 | 1. Сравните сервер аппликейшены и сервис апликейшены (Nginx, Apache, Puma, Webrick).
52 | 1. Nginx, его отличие от apache?
53 |
54 |
55 | Ответ
56 | Два самых широко распространенных веб-сервера. Если рассматривать жизненные примеры, то основные различия между Apache и Nginx в том как они обрабатывают запросы к статическому и динамическому контенту.
57 |
58 |
59 | 1. Почему используют не Puma, а Nginx?
60 | 1. Балансировка нагрузки на сервера приложений (haproxy).
61 | 1. Чем отличается HTTP от HTTPS?
62 |
63 |
64 | Ответ
65 |
66 | * HyperText Transfer Protocol
67 |
68 | * HyperText Transfer Protocol Secure — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности.
69 |
70 |
71 | 1. Из чего состоит HTTP запрос?
72 | 1. Что такое HTTP OPTIONS?
73 |
74 |
75 | Ответ
76 |
77 | Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса.
78 | В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов.
79 | Также в заголовке ответа может включаться информация о поддерживаемых расширениях.
80 |
81 |
82 | https://developer.mozilla.org/ru/docs/Web/HTTP/Methods/OPTIONS
83 | https://ru.wikipedia.org/wiki/HTTP#OPTIONS
84 | https://habr.com/ru/post/342432/
85 | 1. Какое шифрование имеет HTTPS?
86 |
87 |
88 | Ответ
89 |
90 | Защиту данных в HTTPS обеспечивает криптографический протокол SSL/TLS,
91 | который шифрует передаваемую информацию. По сути этот протокол является обёрткой для HTTP.
92 | Он обеспечивает шифрование данных и делает их недоступными для просмотра посторонними.
93 | Протокол SSL/TLS хорош тем, что позволяет двум незнакомым
94 | между собой участникам сети установить защищённое соединение через незащищённый канал.
95 |
96 | https://yandex.ru/blog/company/77455
97 | https://habr.com/ru/post/188042/
98 | https://firstssl.ru/faq/general-questions/chto-takoe-https
99 |
100 |
101 | 1. Что такое сессии? Для чего нужны?
102 | 1. Какое максимальное количествол кб, может весить 1 кука в сессии RoR?
103 |
104 |
105 | Ответ
106 | 4 kb
107 |
108 |
109 | 1. Что такое crontab и для чего используются?
110 | 1. Как устроен HTTP, какие есть заголовки, как работают cookies, как работает HTTPS?
111 |
112 | 1. Реализация протокола AMQP
113 |
114 |
115 | Ответ
116 | AMQP протокол используется для передачи данных между компонентами системы. Основная идея состоит в том, что отдельные подсистемы (или независимые приложения) могут обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений.
117 |
118 | Брокеры: RabbitMQ (гем `bunny`), ActiveMQ, Apache Kafka.
119 |
120 | https://ru.wikipedia.org/wiki/AMQP
121 | https://kt.team/hr/blog/rabbitmq
122 | https://www.bigdataschool.ru/blog/kafka-vs-rabbitmq-big-data.html#:~:text=%D0%A7%D0%B5%D0%BC%20%D0%9A%D0%B0%D1%84%D0%BA%D0%B0%20%D0%BE%D1%82%D0%BB%D0%B8%D1%87%D0%B0%D0%B5%D1%82%D1%81%D1%8F%20%D0%BE%D1%82%20%D0%9A%D1%80%D0%BE%D0%BB%D0%B8%D0%BA%D0%B0,(topic)%20%D0%BD%D1%83%D0%B6%D0%BD%D1%8B%D0%B5%20%D0%B8%D0%BC%20%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D1%8F.
123 | https://habr.com/ru/company/itsumma/blog/416629/
124 |
125 |
126 | 1. Что такое OSI-модель? Сколько уровней она имеет, опишите их.
127 |
128 |
129 | Ответ
130 | Модель Open Systems Interconnection (OSI) – это скелет, фундамент и база всех сетевых сущностей. Модель определяет сетевые протоколы, распределяя их на 7 логических уровней. Важно отметить, что в любом процессе, управление сетевой передачей переходит от уровня к уровню, последовательно подключая протоколы на каждом из уровней.
131 |
132 | https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI
133 | https://wiki.merionet.ru/seti/18/model-osi-eto-prosto/
134 |
135 |
136 | 1. Назовите отличия протокола TCP и UDP.
137 |
138 |
139 | Ответ
140 | Протокол TCP (Transmission Control Protocol) – это сетевой протокол, который «заточен» под соединение. Иными словами, прежде, чем начать обмен данными, данному протоколу требуется установить соединение между двумя хостами. Данный протокол имеет высокую надежность, поскольку позволяет не терять данные при передаче, запрашивает подтверждения о получении от принимающей стороны и в случае необходимости отправляет данные повторно. При этом отправляемые пакеты данных сохраняют порядок отправки, то есть можно сказать, что передача данных упорядочена. Минусом данного протокола является относительно низкая скорость передачи данных, за счет того что выполнение надежной и упорядоченной передачи занимает больше времени, чем в альтернативном протоколе UDP.
141 |
142 | Протокол UDP (User Datagram Protocol), в свою очередь, более прост. Для передачи данных ему не обязательно устанавливать соединение между отправителем и получателем. Информация передается без предварительной проверки готовности принимающей стороны. Это делает протокол менее надежным – при передаче некоторые фрагменты данных могут теряться. Кроме того, упорядоченность данных не соблюдается – возможен непоследовательный прием данных получателем. Зато скорость передачи данных по данному транспортному протоколу будет более высокой.
143 |
144 | https://wiki.merionet.ru/seti/23/tcp-i-udp-v-chem-raznica/
145 | http://pyatilistnik.org/chem-otlichaetsya-protokol-tcp-ot-udp/
146 | https://yandex.ru/q/question/computers/chem_otlichaetsia_tcp_ot_udp_66a93f75/
147 | https://habr.com/ru/company/oleg-bunin/blog/461829/
148 |
149 |
150 | 1. Что такое RPC?
151 |
152 |
153 | Ответ
154 | RPC (от англ. Remote Procedure Call, RPC) Удалённый вызов процедур, реже Вызов удалённых процедур — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (на удалённых компьютерах, либо в независимой сторонней системе на том же устройстве). Обычно реализация RPC-технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC).
155 |
156 | https://ru.wikipedia.org/wiki/%D0%A3%D0%B4%D0%B0%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B2%D1%8B%D0%B7%D0%BE%D0%B2_%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%B4%D1%83%D1%80
157 |
158 |
--------------------------------------------------------------------------------
/test_assignments/README.md:
--------------------------------------------------------------------------------
1 | # Список тестовых заданий на позицию Ruby on Rails разработчика
2 |
3 | Ссылка на этот список: https://git.io/JvQHV
4 |
5 | [SQL: запрос к БД](SQL_find_max_score.md)
6 |
7 | [SQL: написать запросы к базе данных](SQL_query_for_users.md)
8 |
9 | [Non-rails framework: text web-app with self-destructing messages](app_with_self_destructing_text_messages.md)
10 |
11 | [RoR + Selenium: автоматизированный сбор списка активных юзеров](automated_collection_of_active_forum_users.md)
12 |
13 | [RoR + Selenium: автоматизированный поиск тем по ключевым словам на форуме](automated_keyword_search.md)
14 |
15 | [RoR + Selenium: автоматизированная проверка новых личных сообщений на форуме](automated_unread_messages_checking.md)
16 |
17 | [RoR + Selenium: автоматизированный сбор данных юзеров](automated_user_data_collection.md)
18 |
19 | [RoR: бот-калькулятор для Telegram](calculating_bot_for_telegram.md)
20 |
21 | [Ruby + JSON RESTful API: приложение с объявлениями о работе](job_advertisement_site.md)
22 |
23 | [Ruby + JSON API: сервис без использования Ruby on Rails](json_api_service_without_rails.md)
24 |
25 | [RoR: JSON API с экшенами для блога](json_api_for_blog.md)
26 |
27 | [RoR: API для обменника валют](currency_exchange_rails_api.md)
28 |
29 | [JSON API: прототип для системы бронирования авто](prototype_for_car_hiring_system.md)
30 |
31 | [JSON API: учет посещенных ссылок](ror_api_reference_counting.md)
32 |
33 | [RoR: meals delivery service](meals_delivery_service.md)
34 |
35 | [RoR: выгрузка тестового прайс-листа и создание карточек для онлайн-магазина](price_list_export_algorithms_for_marketplace.md)
36 |
37 | [RoR + Ember: API для сайта продажи/аренды недвижимости](rails_api_for_real_estate_site.md)
38 |
39 | [RoR + Ember: простой трекер задач](simple_to_do_list.md)
40 |
41 | [RoR: таск-менеджер с функцией аутентификации](task_manager_with_authentication.md)
42 |
43 | [RoR: панель администратора магазина](shop_dashboard.md)
44 |
45 | [Ruby: функция Checkout для магазина](shop_with_checkout.md)
46 |
47 | [Ruby: тотализатор](totalizator.md)
48 |
49 | [Ruby: конвертер из CSV в ASCII таблицу](csv_ascii_converter.md)
50 |
51 | [Ruby: сервис статистики видеопросмотров](video_view_statistics_service.md)
52 |
53 | [Ruby: сервис проверки кредитных карт](credit_card_checker.md)
54 |
55 | [TelegramBot: конвертация стикеров в PNG-файлы](telegram_bot_sticker_png.md)
56 |
57 | [RoR + Front end: RESTful JSON API для управления пользователями сайта](web_panel_for_users_control.md)
58 |
59 | [RoR + PostgreSQL: приложение, которое импортирует коммиты GitHub в БД](import_commits_from_github.md)
60 |
61 | [RoR: консольное приложение для проверки статистики футбольных матчей](player_statistics.md)
62 |
63 | [RoR: JSON API для новостного сайта](news_site_API.md)
64 |
65 | [RoR: simple appointments management system](appointments_management_system.md)
66 |
67 | [RoR: приложение для ведения списка персон](app_for_managing_people_list.md)
68 |
69 | [RoR: импорт коммитов из репозитория GitHub](import_commits_app.md)
70 |
71 | [RoR: billing system](billing_system.md)
72 |
73 | [RoR: структура БД для хранения данных о товарах и магазинах](database_structure_for_shops.md)
74 |
75 | [RoR: система решения математических уравнений](solving_mathematical_equations_app.md)
76 |
77 | [RoR: подсчет различных видов html-тегов по вводимым url](count_html_tags_by_url.md)
78 |
79 | [RoR: генерация pdf-файлов (дипломов) по гитхабу](pdf_diploma_generator.md)
80 |
81 | [RoR: REST API для блога](rest_api_for_blog.md)
82 |
83 | [RoR: система бронирования столов в ресторанах (только модели)](restaurants_with_tables.md)
84 |
85 | [RoR: API для управления списками задач](oblako_group_test_app.md)
86 |
87 | [RoR: Приложение для заказа обеда](lunch_ordering_saas.md)
88 |
89 | [RoR: Приложение для управления поликлиникой](clinic_management_system.md)
90 |
91 | [RoR: Приложение для построения небольшого сайта с иерархией страниц](app_with_page_hierarchy.md)
92 |
93 | [RoR: Приложение для сокращения ссылок](url_shortener_app.md)
94 |
95 | [Grape + Ruby\/RoR: Приложения для импорта маркетов валют](grape_markets_list_app.md)
96 |
97 | [ROR6 + Grape: API для статистики по погоде](weather_statistics_api.md)
98 |
--------------------------------------------------------------------------------
/test_assignments/SQL_find_max_score.md:
--------------------------------------------------------------------------------
1 | ## SQL: запрос к БД
2 |
3 | Есть таблица `users` [ id (int), email (str), score (int), company_id(int) ]
со связью «один ко многим» с таблицей `companies` [ id(int), name(str) ]
4 |
5 | **Задание**
6 |
7 | Получить выборку [ id, email, score, company_id ] с максимальным `score` по каждой компании.
8 |
9 | `Users`
10 |
11 | |ID|email|score|company_id|
12 | |---|---|---|---|
13 | |1|user1@test.home|8|1|
14 | |2|user2@test.home|8|2|
15 | |3|user3@test.home|4|1|
16 | |4|user4@test.home|1|2|
17 | |5|user5@test.home|2|1|
18 | |6|user6@test.home|3|2|
19 | |7|user7@test.home|0|1|
20 | |8|user8@test.home|6|2|
21 | |9|user9@test.home|9|1|
22 |
23 | Result
24 |
25 | |ID|email|score|company_id|
26 | |---|---|---|---|
27 | |9|user9@test.home|9|1|
28 | |2|user2@test.home|8|2|
--------------------------------------------------------------------------------
/test_assignments/SQL_query_for_users.md:
--------------------------------------------------------------------------------
1 | ## SQL: написать запросы к базе данных
2 |
3 | **Условия**
4 |
5 | Дана таблица `users` с полями `id`, `group_id`.
6 |
7 | ```sql
8 | CREATE TEMP TABLE users(id bigserial, group_id bigint);
9 | INSERT INTO users(group_id) VALUES (1), (1), (1), (2), (1), (3);
10 | ```
11 |
12 | В этой таблице, упорядоченной по `id` необходимо:
13 |
14 | - выделить непрерывные группы по `group_id` с учётом указанного порядка записей (их 4);
15 |
16 | - подсчитать количество записей в каждой группе;
17 |
18 | - вычислить минимальный `id` записи в группе.
19 |
20 | Для таблицы:
21 |
22 | | id | group_id |
23 | | ------- | -------- |
24 | | 1 | 1 |
25 | | 2 | 1 |
26 | | 3 | 1 |
27 | | 4 | 2 |
28 | | 5 | 1 |
29 | | 6 | 3 |
30 |
31 | Непрерывными группами можно считать:
32 |
33 | | group_id |
34 | | -------- |
35 | | 1 |
36 | | 2 |
37 | | 1 |
38 | | 3 |
39 |
40 | Запрос должен выводить:
41 |
42 | | min_id | group_id | count |
43 | | ------ | -------- | ------ |
44 | | 1 | 1 | 3 |
45 | | 4 | 2 | 1 |
46 | | 5 | 1 | 1 |
47 | | 6 | 3 | 1 |
--------------------------------------------------------------------------------
/test_assignments/app_for_managing_people_list.md:
--------------------------------------------------------------------------------
1 | ## RoR: приложение для ведения списка персон
2 |
3 | **Задание**
4 |
5 | Создать приложение для ведения списка персон и склонений их ФИО.
6 |
7 | **Требования**
8 |
9 | _В системе есть персоны (People):_
10 |
11 | * first_name — обязательное поле;
12 | * last_name — необязательное поле;
13 | * middle_name — необязательное поле;
14 | * sex (пол) — необязательное поле;
15 | * full_name — обязательное поле.
16 |
17 | `full_name` пишется в БД автоматически исходя из предоставленных `first_name`, `last_name`, `middle_name`.
18 |
19 | `sex` может быть только 2-х типов — «Мужской» и «Женский».
20 |
21 | Необходимо реализовать автоматическую запись в БД склонений `first_name`, `last_name`, `middle_name`, `full_name` для каждой персоны при их создании и изменении. Склонения ФИО должны быть записаны НЕ в таблицу `peoples`.
22 |
23 | _Падежи:_
24 |
25 | * родительный
26 | * дательный
27 | * творительный
28 | * винительный
29 | * предложный
30 |
31 | _Страницы_
32 |
33 | 1. Страница «Список Персон»
34 |
35 | Отображается таблица всех персон.
36 | Колонки таблицы: Имя, Фамилия, Отчество, ФИО в родительном падеже, Пол, Действия.
37 |
38 | В колонке «Действия» 3 кнопки:
39 |
40 | * переход на страницу редактирования персоны;
41 | * удаление персоны.
42 |
43 | На странице кнопка есть «создать персону».
44 |
45 | 2. Страница «Персона»
46 |
47 | * таблица со всеми данными персоны (включая все склонения имени, фамилии, отчества, ФИО);
48 | * кнопка «Назад в список персон»;
49 | * кнопка «Редактирование персоны».
50 |
51 | 3. Форма персоны
52 |
53 | * поля — имя, фамилия, отчество, пол;
54 | * кнопка «Назад на страницу персоны».
55 |
56 | **Особенности, требования к реализации**
57 |
58 | * Rails;
59 | * имена русские / жителей СНГ;
60 | * нужно покрыть тестами;
61 | * в системе нет ролей, аутентификации или авторизации;
62 | * требований к оформлению нет;
63 | * можно использовать любые гемы.
64 |
65 | Ответ к заданию — проект на GitHub/GitLab/Bitbucket.
--------------------------------------------------------------------------------
/test_assignments/app_with_page_hierarchy.md:
--------------------------------------------------------------------------------
1 | ## RoR: приложение для построения небольшого сайта с иерархией страниц
2 |
3 | **Задание**
4 |
5 | Необходимо продемонстрировать умение программировать на Ruby с помощью Rails. Будет круто если вы выложите задачу на `github`, и покроете ее тестами на `rspec`.
6 |
7 | Создать небольшой сайт, который состоит из текстовых страниц, организованных в иерархию. То есть, одна страница может быть под-страницей другой страницы.
8 |
9 | **Функционал**
10 |
11 | На главной странице расположено дерево страниц сайта.
12 |
13 | ```
14 | страница
15 | подстраница
16 | подстраница
17 | подподстраница
18 | страница
19 | ```
20 |
21 | Каждая страница описывается следующими полями:
22 | - `имя страницы` - строка, удовлетворяет условию `[a-zA-Z0-9_]`, ДОПУСТИМЫ РУССКИЕ
23 | СИМВОЛЫ
24 | - `заголовок страницы` - произвольная строка
25 | - `текст страницы` - произвольный текст, в котором может присутствовать html-разметка.
26 |
27 | Адресная схема мини-сайта:
28 |
29 | `[site]name1/name2/name3` - открывается страница с именем `name3`, которая является под-страницей страницы `name2`, которая является под-страницей страницы `name1`.
30 | На странице виден её текст и заголовок, а также поддерево всех её подстраниц.
31 |
32 | `[site]name1/name2/name3/edit` - страница открывается в режиме редактирования - можно редактировать заголовок и текст.
33 | После сохранения нужно делать редирект на адрес `[site]name1/name2/name3`.
34 |
35 | `[site]name1/name2/name3/add` - форма добавления подстраницы к текущей странице, можно задать имя, заголовок и текст.
36 | После добавления нужно делать редирект на адрес `[site]name1/name2/name3/[новое имя]`.
37 |
38 | `[site]add` - форма добавления корневой страницы.
39 |
40 | При сохранении или добавлении текст страниц должен подвергаться следующим преобразованиям:
41 |
42 | - `**[строка]**` => `
[строка]` (выделение жирным)
43 | - `\\[строка]\\` => `
[строка]` (выделение курсивом)
44 | - `((name1/name2/name3 [строка]))` преобразовывать в ссылку на страницу `[site]name1/name2/name3`
45 | Однако, при редактировании страницы пользователь должен править неформатированный текст.
46 |
47 | **Требования**
48 |
49 | Реализовать это всё нужно на `Rails >= 4.0`, `Ruby >= 2.2`.
50 | Время отдачи любой из страниц вида `[site]name1/name2/` не должно превышать 100 ms для теста утилитой `ab` c параметрами `-с 100 -n 10000`.
51 |
52 | Обращать внимание на:
53 | - архитектуру приложения
54 | - читаемость кода
55 | - комментирование кода
56 | - безопасность кода
57 | - дизайн не важен
58 |
--------------------------------------------------------------------------------
/test_assignments/app_with_self_destructing_text_messages.md:
--------------------------------------------------------------------------------
1 | ## Non-rails framework: text web-app with self-destructing messages
2 |
3 | Build a web application, which creates text self-destructing
4 | messages.
5 |
6 | **Requirements**
7 |
8 | A user opens the website and creates a message. The application generates a safe link to this saved message (such as: http://yourapp.com/message/ftr45e32fgv56d2 ).
9 |
10 | The user should be able to choose a destruction option:
11 |
12 | - destroy message after the first link visit
13 |
14 | - destroy after 1 hour
15 |
16 | All the messages stored on the server side should be encrypted using the AES algorithm (you can use any library for text encryption).
17 |
18 | Cover your application with the unit and integration tests using
19 | rspec.
20 |
21 | **Technologies**
22 |
23 | Use any non-rails framework (sinatra, hanami or any other) for ruby backend. Also please deploy your application to Heroku.
24 |
25 | **Bonus points for implementing**
26 |
27 | - message should be encrypted on the frontend side, using a password and should be sent to backend in an encrypted format (to view the message, the user should enter a correct password)
28 |
29 | - self-destruction of messages after a given number of link visits or after a given number of hours
--------------------------------------------------------------------------------
/test_assignments/appointments_management_system.md:
--------------------------------------------------------------------------------
1 | ## RoR: simple appointments management system
2 |
3 | **Requirements**
4 |
5 | This is a simple appointments management system. It should have a web interface for customers and ability to integrate it through the REST JSON API with the 3rd party applications.
6 |
7 | Here is a short list of specs we would like to be implemented. Everything what isn’t outlined here is up to you. Feel free to add anything necessary by your opinion.
8 |
9 | * As a user I can register in the system (please put a few lines why you have chosen this implementation approach).
10 |
11 | * As a user I can see a list of my upcoming and past appointments.
12 |
13 | * As a user I can create new appointment and with as many reminders as I need.
14 |
15 | * As a user in the web interface I can see a list of submitted appointments through the API and confirm or cancel them.
16 |
17 | _Key specs for objects(remember, everything else is up to you)_
18 |
19 | * Appointment has several statuses (pending/confirmed/canceled).
20 |
21 | * Let’s assume that appointment has a one hour length and can’t be overlapped by another one.
22 |
23 | * Reminder has status (reminded or not), time to raise remind before appointment.
24 |
25 | * Please add any other restrictions you think are fitable to system objects and don’t forget to describe a reason.
26 |
27 | _API_
28 |
29 | * As a guest, if I know user API key, I can post request to create appointment on a specific date with defined reminder.
30 |
31 | * As a quest, if I know user API key, I can receive the list of user appointments and filter it by date (let’s keep it simple, can specify only one day in params and receive appointments exactly during this day).
32 |
33 | * As a system I should be able to monitor API usage and store general statistics per each user. Please store type of request and its time.
34 |
35 | * As a system I should be able to send reminders for appointments in the specified time.
36 |
37 | **Technical notes**
38 |
39 | * For each chosen technology like DB, Scheduling, Stats Collector, API responses builder try to describe what options are in general and why the option you have chosen is the best one here.
40 |
41 | * The code quality should we perfect as well as timing of delivering this task.
42 |
43 | * The code should be covered with unit, functional and integration tests (please use RSpec+Capybara).
44 |
45 | * Front-end can be pretty very simple. The source code of application should be uploaded on GitHub in the end.
--------------------------------------------------------------------------------
/test_assignments/automated_collection_of_active_forum_users.md:
--------------------------------------------------------------------------------
1 | ## RoR + Selenium: автоматизированный сбор списка активных юзеров
2 |
3 | Необходимо продемонстрировать умение не только решать поставленную задачу, но и качественно оформлять код:
4 |
5 | - выбирать содержательные названия для классов, методов и переменных;
6 |
7 | - писать разумные комментарии к каждому классу и методу, указывать тип и описание для каждого параметра;
8 |
9 | - создавать методы и классы разумного размера (по количеству строк);
10 |
11 | - использовать константы с понятными названиями вместо «магических чисел».
12 |
13 | Необходимо обдумать не только «позитивный» случай, но и возможные ошибки в процессе обработки (на практике они более чем возможны). В том числе случай, когда меняется структура страниц и алгоритм перестаёт функционировать корректно. Все такие ошибки должны правильно и, по возможности, унифицированно обрабатываться.
14 |
15 | **Задание**
16 |
17 | Реализуйте автоматизированный сбор списка самых активных участников вашего любимого форума (или любого форума, где есть список пользователей, отсортированный по числу сообщений).
18 |
19 | **Предполагаемый алгоритм решения задачи**
20 |
21 | - залогиниться на форуме, используя предоставленные логин и пароль аккаунта, если это требуется для получения списка пользователей;
22 |
23 | - получить список пользователей, отсортированный по числу сообщений;
24 |
25 | - собрать все `username` аккаунтов (и число их сообщений), у которых больше N сообщений, пролистывая страницы списка;
26 |
27 | - занести информацию в таблицу `forum_users` базы данных с полями `{ VARCHAR username, INT messages_count, DATE scraped_date }`, где `username` + `scraped_date` (дата сбора данных) имеют ограничение на уникальность (unique constraint). В случае наличия записи — не обновлять данные.
28 |
29 | **Технологии**
30 |
31 | Задание нужно реализовать на Ruby On Rails в виде периодической задачи Resque + Resque Scheduler, где логин и пароль аккаунта, а также расписание выполнения хранятся в конфигурационном файле.
32 |
33 | Рекомендуем продумать архитектуру решения: желательно выделить «низкий уровень» элементарных запросов и «высокий уровень» управления навигацией и обработки ошибок навигации. Обязательно использовать принцип «тонких контроллеров» для resque jobs.
--------------------------------------------------------------------------------
/test_assignments/automated_keyword_search.md:
--------------------------------------------------------------------------------
1 | ## RoR + Selenium: автоматизированный поиск тем по ключевым словам на форуме
2 |
3 | Необходимо продемонстрировать умение не только решать поставленную задачу, но и качественно оформлять код:
4 |
5 | - выбирать содержательные названия для классов, методов и переменных;
6 |
7 | - писать разумные комментарии к каждому классу и методу, указывать тип и описание для каждого параметра;
8 |
9 | - создавать методы и классы разумного размера (по количеству строк);
10 |
11 | - использовать константы с понятными названиями вместо «магических чисел».
12 |
13 | Необходимо обдумать не только «позитивный» случай, но и возможные ошибки в процессе обработки (на практике они более чем возможны). В том числе случай, когда меняется структура страниц и алгоритм перестаёт функционировать корректно. Все такие ошибки должны правильно и, по возможности, унифицированно обрабатываться.
14 |
15 | **Задание**
16 |
17 | Реализуйте автоматизированный поиск тем по ключевым словам на вашем любимом форуме.
18 |
19 | **Предполагаемый алгоритм решения задачи**
20 |
21 | - залогиниться на форуме, используя предоставленные логин и пароль аккаунта, если это требуется для получения списка пользователей;
22 |
23 | - получить список тем с ключевыми словами, используя поиск по форуму;
24 |
25 | - собрать все названия и URL тем из списка результатов, а также количество сообщений в каждой из них;
26 |
27 | - желательно также получить стартовое сообщение темы.
28 |
29 | **Технологии**
30 |
31 | Задание нужно реализовать на Ruby On Rails в виде API-вызова, где логин и пароль аккаунта, а также поисковая фраза (`query`) являются GET-параметрами, а ответ — JSON-объектом с полем `success: true`, `data` - списком объектов с полями `title`, `body`, `replies_count`, `url`, описывающих найденные темы.
32 |
33 | Рекомендуем продумать архитектуру решения: желательно выделить «низкий уровень» элементарных запросов и «высокий уровень» управления навигацией и обработки ошибок навигации. Обязательно использовать принцип «тонких контроллеров» для resque jobs.
--------------------------------------------------------------------------------
/test_assignments/automated_unread_messages_checking.md:
--------------------------------------------------------------------------------
1 | ## RoR + Selenium: автоматизированная проверка новых личных сообщений на форуме
2 |
3 | Необходимо продемонстрировать умение не только решать поставленную задачу, но и качественно оформлять код:
4 |
5 | - выбирать содержательные названия для классов, методов и переменных;
6 |
7 | - писать разумные комментарии к каждому классу и методу, указывать тип и описание для каждого параметра;
8 |
9 | - создавать методы и классы разумного размера (по количеству строк);
10 |
11 | - использовать константы с понятными названиями вместо «магических чисел».
12 |
13 | Необходимо обдумать не только «позитивный» случай, но и возможные ошибки в процессе обработки (на практике они более чем возможны). В том числе случай, когда меняется структура страниц и алгоритм перестаёт функционировать корректно. Все такие ошибки должны правильно и, по возможности, унифицированно обрабатываться.
14 |
15 | **Задание**
16 |
17 | Реализуйте автоматизированную проверку наличия новых личных сообщений на вашем любимом форуме.
18 |
19 | **Предполагаемый алгоритм решения задачи**
20 |
21 | - залогиниться на форуме, используя предоставленные логин и пароль аккаунта;
22 |
23 | - перейти в раздел личных сообщений;
24 |
25 | - попытаться найти элемент,содержащий число новых сообщений;
26 |
27 | - в случае его наличия — прочитать `inner Text/value`.
28 |
29 | Задание нужно реализовать на Ruby On Rails в виде API-вызова, где логин и пароль аккаунта являются GET-параметрами, а ответ - JSON-объектом с единственным полем `unread_messages_count`.
30 |
31 | Рекомендуем продумать архитектуру решения: желательно выделить «низкий уровень» элементарных запросов и «высокий уровень» управления навигацией и обработки ошибок навигации. Обязательно использовать принцип «тонких контроллеров».
--------------------------------------------------------------------------------
/test_assignments/automated_user_data_collection.md:
--------------------------------------------------------------------------------
1 | ## RoR + Selenium: автоматизированный сбор данных юзеров
2 |
3 | Необходимо продемонстрировать умение не только решать поставленную задачу, но и качественно оформлять код:
4 |
5 | - выбирать содержательные названия для классов, методов и переменных;
6 |
7 | - писать разумные комментарии к каждому классу и методу, указывать тип и описание для каждого параметра;
8 |
9 | - создавать методы и классы разумного размера (по количеству строк);
10 |
11 | - использовать константы с понятными названиями вместо «магических чисел».
12 |
13 | Необходимо обдумать не только «позитивный» случай, но и возможные ошибки в процессе обработки (на практике они более чем возможны). В том числе случай, когда меняется структура страниц и алгоритм перестаёт функционировать корректно. Все такие ошибки должны правильно и, по возможности, унифицированно обрабатываться.
14 |
15 | **Задание**
16 |
17 | Реализуйте автоматизированный сбор данных о пользователях вашего любимого форума.
18 |
19 | **Предполагаемый алгоритм решения задачи**
20 |
21 | - залогиниться на форуме, используя предоставленные логин и пароль аккаунта, если это требуется для получения списка пользователей;
22 |
23 | - получить список пользователей, отсортированный по алфавиту;
24 |
25 | - Собрать все `username` аккаунтов и для каждого получить аватар (именно картинку, а не просто URL) со страницы профиля;
26 |
27 | - занести информацию в таблицу `forum_users` базы данных с полями `{ VARCHAR username, VARCHAR profile_url, VARCHAR avatar_image, DATE last_scraped_date }`, если запись уже существует - обновить данные.
28 |
29 | **Технологии**
30 |
31 | Задание нужно реализовать на Ruby On Rails в виде периодической задачи Resque + Resque Scheduler, где логин и пароль аккаунта, а также расписание выполнения хранятся в конфигурационном файле.
32 |
33 | Работу с аватарами реализовать с использованием гема carrierwave.
34 |
35 | Рекомендуем продумать архитектуру решения: желательно выделить «низкий уровень» элементарных запросов и «высокий уровень» управления навигацией и обработки ошибок навигации. Обязательно использовать принцип «тонких контроллеров» для resque jobs.
--------------------------------------------------------------------------------
/test_assignments/billing_system.md:
--------------------------------------------------------------------------------
1 | ## RoR: billing system
2 |
3 | **Requirements**
4 |
5 | Please build us a new billing system. We sell a widget in 3 different ways:
6 |
7 | 1. Direct sale for $100 per item.
8 |
9 | 2. Affiliates who resell our widget based on a tiered billing system. They pay us based on how many widgets they sell total.
10 |
11 | * They sell 0-500 widgets in a month, $60 per widget.
12 | * They sell 501-1000 widgets in a month, $50 per widget.
13 | * They sell 1001+ widgets in a month, $40 per widget.
14 |
15 | We have the following Affiliates:
16 | * A Company: Sells the widget for $75/ea.
17 | * Another Company: Sells the widget for $65/ea.
18 | * Even More Company: Sells the widget for $80/ea.
19 |
20 | 3. Resellers who resell our widget based on a flat billing system. They pay us $50 per widget.
21 |
22 | We have the following Resellers:
23 | * Resell This: Sells the widget for $75
24 | * Sell More Things: Sells the widget for $85
25 |
26 | All three groups can receive orders for this service. An order includes a quantity of widgets ordered, a method used, and an amount paid.
27 |
28 | Build a class that generates 100 randomized orders for one month. These orders should be randomly assigned to each of the 6 possible types of sale and should be for a random number of widgets between 1 and 100. Build a service object that we can use to generate billing reports.
29 |
30 | This library needs to generate the following reports:
31 | * Total amount we should bill each Affiliate and Reseller.
32 | * Profit earned by each Affiliate and Reseller.
33 | * Total revenue for the company from all sales: Affiliate, Reseller and Direct.
34 |
35 | **Additional information**
36 |
37 | This object needs to have a simple and documented interface that we can easily integrate with our existing systems. For the purposes of the test, a persistence layer is not required. Also, testing is very important to our team so please provide some basic unit tests (Rspec or Minitest preferred).
--------------------------------------------------------------------------------
/test_assignments/calculating_bot_for_telegram.md:
--------------------------------------------------------------------------------
1 | ## RoR: бот-калькулятор для Telegram
2 |
3 | **Условия выполнения задания**
4 |
5 | - Выполнить задание нужно на Rails (на языке Ruby).
6 |
7 | - Использовать библиотеки для создания Телеграм-ботов нельзя.
8 |
9 | - Чтобы сдать задание, нужно:
10 |
11 | - ссылку на исходный код под лицензией Apache 2.0 в каком-либо открытом git-репозитории (GitHub, GitLab, Bitbucket);
12 |
13 | - ссылку на работающего бота (в качестве бесплатного хостинга можно использовать, например, Heroku);
14 |
15 | - решения нескольких задач (условия приведены в форме).
16 |
17 | - Срок выполнения задания — чем скорее, тем лучше :) Откладывать в долгий ящик не надо, но и торопиться сделать все за один день не обязательно. Мы рассчитываем, что за неделю вы справитесь, но если справитесь за две — ничего страшного.
18 |
19 | **Задание**
20 |
21 | Напишите Телеграм-бота, который отображает в окне Телеграма примитивный кнопочный калькулятор:
22 |
23 | - кнопки цифр 0-9;
24 |
25 | - кнопки арифметических действий (+, -);
26 |
27 | - кнопка сброса (AC).
28 |
29 | Реализация основывается на двух возможностях Телеграма:
30 |
31 | - редактировать ранее отправленные сообщения;
32 |
33 | - показывать многоуровневые «клавиатуры» из кнопок.
34 |
35 | При нажатии стандартной кнопки «Start» бот отправляет пользователю сообщение с текстом «0» и клавиатурой. Пользователь никаких сообщений боту не отправляет, только нажимает кнопки, что приводит к редактированию исходного сообщения: если нажать кнопки 1 и 3, например, текст сообщения поменяется на «13». Аналогично с арифметическими действиями.
36 |
37 | Обратите внимание: вам не нужно писать разбор арифметического выражения, простые калькуляторы этого не делают.
38 |
39 | **Внимание**: разные пользователи могут пользоваться калькулятором независимо, для каждого из них должна храниться своя версия состояния.
--------------------------------------------------------------------------------
/test_assignments/clinic_management_system.md:
--------------------------------------------------------------------------------
1 | # Реализовать проект по управлению поликлиникой
2 |
3 | Виды пользователей:
4 |
5 | - пациент (User)
6 | - врач (Doctor)
7 | - Admin
8 |
9 | Для каждого вида пользователей необходимо реализовать следующий функционал:
10 |
11 | 1. Пациент может зарегистрироваться, войти в свой личный кабинет (Profile), просматривать список врачей по категориям, записаться на прием, получить рекомендации от врача после приема.
12 | 1. Врач может войти в личный кабинет (Profile), просмотреть список записавшихся пациентов, дать рекомендации пациенту. Врач может относится к определенной категории (терапевт, кардиолог и тд).
13 | 1. Админ имеет доступ к списку пациентов и врачей. Может создавать категории, врачей, асайнить определенного врача к категории. (можно реализовать через ActiveAdmin/Administrate)
14 |
15 | Требования по аутентификации и авторизации:
16 |
17 | - использовать devise;
18 | - реализовать login через phone-password;
19 | - использовать gem cancancan для разграничения прав пользователей;
20 |
21 | Требования по таблице категорий:
22 |
23 | - валидация на уникальность по имени;
24 | - возможность добавления нескольких врачей;
25 |
26 | Требования по таблицам Врач-Пациент:
27 |
28 | - реализовать связь many-to-many;
29 | - у врача может быть только 10 открытых записей (одновременно);
30 | - запись автоматически закрывается (не удаляется) после того, как врач напишет пользователю рекомендацию;
31 |
32 | Общие требования:
33 |
34 | - Сделать публичную часть для пациентов и врачей;
35 | - Для реализации админки можно использовать ActiveAdmin;
36 | - Картинки хранить на S3 или Cloudinary;
37 | - Выложить проект на Heroku, а код на GitHub. Прислать ссылки + доступы в админ часть и публичную часть.
38 |
39 |
--------------------------------------------------------------------------------
/test_assignments/count_html_tags_by_url.md:
--------------------------------------------------------------------------------
1 | ## RoR: подсчет различных видов html-тегов по вводимым url
2 |
3 | **Задание**
4 |
5 | Реализовать подсчет различных видов html-тегов по вводимым url (Rails-приложение).
6 |
7 | **Функционал**
8 |
9 | 1. Главная страница должна содержать поле для указания URL и кнопку. По отправке формы делать запрос на указанный URL (использовать `Nokogiri`), в ответе выводить количество каждого из html-тегов в ответе по указанному адресу (сколько раз встречается в документе), например, `div` - 5 раз, `p` - 1 раз и т. п. Оформить в виде таблицы.
10 | 2. Также реализовать сохранение этих данных в базе (`Postgre`). В одной модели (`Document`) храним `url`, в связанной (`Tag`) - теги и их количество.
11 | 3. Добавить в проект регистрацию и авторизацию (`Devise`). Шаблоны `Devise` можно не переделывать.
12 | 4. Для авторизованных пользователей выводить данные по вводимым ранее url (сохраненным в БД). Сделать ресурс documents (экшены: `index` - список url, `show` - список тегов с кол-вом для url, `destroy` - понятно) и вложенный ресурс `documents/:id/tags` (экшены: `show` - тег и кол-во, `edit/update` (только количества), `destroy`). На индексной странице сделать пейджинг с помощью `Kaminari` (показывать по 5 записей на странице). Добавить всевозможные ссылки (на `edit`, `destroy` и т. п. - можно использовать бутстраповские иконки вместо текста в ссылках).
13 |
14 | Использовать `HAML` и `SASS`, аккуратно оформить все страницы с помощью `Bootstrap` (кроме страниц от `Devise`).
15 |
--------------------------------------------------------------------------------
/test_assignments/credit_card_checker.md:
--------------------------------------------------------------------------------
1 | ## Ruby: credit card checker
2 |
3 | **Task**
4 |
5 | Write a program that accepts a credit card number as a command-line argument. The program should print the card's type (or Unknown) as well a Valid/Invalid indication of whether or not the card passes the Luhn algorithm.
6 |
7 | Hint: use git, cover with specs, make some user friendly interface (can be a command line), make it modular.
8 |
9 | Before a credit card is submitted to a financial institution, it generally makes sense to run some simple reality checks on the number. The numbers are a good length and it's common to make minor transcription errors when the card is not scanned directly. The first check people often do is to validate that the card matches a known pattern from one of the accepted card providers. Some of these patterns are:
10 |
11 | | Card Type | Begins With | Number Length |
12 | | ---------- |------------ | ------------- |
13 | | AMEX | 34 or 37 | 15 |
14 | | Discover | 6011 | 16 |
15 | | MasterCard | 51-55 | 16 |
16 | | Visa | 4 | 13 or 16 |
17 |
18 | All of these card types also generate numbers such that they can be validated by the Luhn algorithm, so that's the second check systems usually try.
19 |
20 | 1. The steps are:
21 |
22 | 1.1. Starting with the next to last digit and continuing with every other digit going back to the beginning of the card, double the digit
23 |
24 | 1.2. Sum all doubled and untouched digits in the number
25 |
26 | 1.3. If that total is a multiple of 10, the number is valid
27 |
28 | 2. For example, given the card number `4408 0412 3456 7893`:
29 |
30 | 2.1. `8 4 0 8 0 4 2 2 6 4 10 6 14 8 18 3`
31 |
32 | 2.2. `8+4+0+8+0+4+2+2+6+4+1+0+6+1+4+8+1+8+3 = 70`
33 |
34 | 2.3. `70 % 10 == 0 #=> Thus that card is valid.`
35 |
36 | 3. Let's try one more, `4417 1234 5678 9112`:
37 |
38 | 3.1. `8 4 2 7 2 2 6 4 10 6 14 8 18 1 2 2`
39 |
40 | 3.2. `8+4+2+7+2+2+6+4+1+0+6+1+4+8+1+8+1+2+2 = 69`
41 |
42 | 3.3. `69 % 10 != 0 #=> That card is not valid.`
43 |
--------------------------------------------------------------------------------
/test_assignments/csv_ascii_converter.md:
--------------------------------------------------------------------------------
1 | Разработать конвертор из CSV файла в таблицу из ASCII символов. Первая строка файла задает типы столбцов. Следующие строки — сами данные (разделитель — точка с запятой).
2 |
3 | Типы:
4 |
5 | * int — целое число (выравнивание вправо)
6 | * string — строка, строковые данные бьются на слова и выводятся в столбик
7 | * money — денежная единица, форматирование 2 занака после запятой, разделитель разрядов — пробел
8 |
9 | Исходные данные (как пример):
10 |
11 | ```
12 | int;string;money
13 | 1;aaa bbb ccc;1000.33
14 | 5;aaaa bbb;0.001
15 | 13;aa bbbb;10000.00
16 | ```
17 |
18 | На выходе скрипта Должно быть:
19 |
20 | ```
21 | +-----------------+
22 | | 1|aaa | 1 000,33|
23 | | |bbb | |
24 | | |ccc | |
25 | +--+----+---------+
26 | | 5|aaaa| 0,01|
27 | | |bbb | |
28 | +--+----+---------+
29 | |13|aa |10 000,00|
30 | | |bbbb| |
31 | +--+----+---------+
32 | ```
33 |
--------------------------------------------------------------------------------
/test_assignments/currency_exchange_rails_api.md:
--------------------------------------------------------------------------------
1 | # Rails API для обменника
2 |
3 | Необходимо реализовать сервис со следующим функционалом на Ruby on Rails.
4 |
5 | В базе данных (желательно применить Postgresql) должна быть таблица `Currency`
6 | и соответствующая модель.
7 |
8 | ### Колонки для таблицы:
9 |
10 | 1. `id` — первичный ключ
11 | 2. `name` — название валюты
12 | 3. `rate` — курс валюты к рублю
13 |
14 | Должна быть `Rake task` для обновления данных в таблице currency. Данные по курсам валют можно взять [отсюда](http://www.cbr.ru/scripts/XML_daily.asp).
15 |
16 | ### Реализовать 2 REST API метода:
17 |
18 | 1. `GET /currencies` — должен возвращать список курсов валют с возможностью пагинации
19 | 2. `GET /currency/` — должен возвращать курс валюты для переданного id
20 |
21 | Ответ должен быть в формате JSON.
22 |
23 | Наличие тестов обязательно.
24 |
25 | API должно быть закрыто bearer авторизацией.
26 |
--------------------------------------------------------------------------------
/test_assignments/database_structure_for_shops.md:
--------------------------------------------------------------------------------
1 | ## RoR: структура БД для хранения данных о товарах и магазинах
2 |
3 | **Задание**
4 |
5 | Необходимо реализовать структуру БД для хранения данных о товарах, магазинах и городах, в которых они находятся, а также остатках конкретных товаров в конкретных магазинах.
6 |
7 | **Требуемые данные**
8 |
9 | 1. Магазин — название, адрес, станция метро(если есть), город.
10 | 2. Товар — артикул, название, вес, размер, цвет, цена, остаток в магазинах.
11 |
12 | _На основе данной структуры данных реализовать следующий функционал:_
13 |
14 | - Возможность сгенерировать xls/xlsx файл с перечислением артикулов и остатков по конкретным магазинам формата (артикул / название магазина / остаток).
15 |
16 | - Должна быть также возможность выбирать любые другие поля из перечисленных выше для добавления в файл.
17 |
18 | - Немаловажно сделать удобным выбор магазинов, остатки из которых должны присутствовать в отчёте.
19 |
20 | **Используемые технологии**
21 |
22 | - Ruby >= 2.2.x
23 |
24 | - Ruby on Rails >= 4.x
25 |
26 | - Postgresql 10
27 |
28 | - Гемсет на свое усмотрение
29 |
30 | Результаты нужно разместить в публичном репозитории GitHub и дать на него ссылку.
--------------------------------------------------------------------------------
/test_assignments/grape_markets_list_app.md:
--------------------------------------------------------------------------------
1 | ## GRAPE: импорт маркетов по заданной ссылке
2 |
3 | Необходимо реализовать сервис со следующим функционалом с использованием гема `Grape`.
4 | Данные по маркетам нужно взять отсюда: https://absrest.realexchange.pro/public/tickers24h
5 |
6 |
7 | Реализовать **2 REST API** метода:
8 |
9 | - `GET` /currencies — должен возвращать список маркетов
10 |
11 | Пример ответа:
12 |
13 | ```ruby
14 | [
15 | {
16 | market: 'BCH/BTC',
17 | base_unit: 'bch',
18 | quote_unit: 'btc',
19 | last_price: 0.01209
20 | },
21 | {
22 | market: 'BCH/USDT',
23 | base_unit: 'bch',
24 | quote_unit: 'usdt',
25 | last_price: 291.14
26 | },
27 | # ........
28 | ]
29 | ```
30 |
31 | - `GET` /currency/ — должен возвращать информацию про маркет по имени маркета.
32 |
33 | Пример ответа:
34 |
35 | ```ruby
36 | {
37 | market: 'BCH/BTC',
38 | base_unit: 'bch',
39 | quote_unit: 'btc',
40 | last_price: 0.01209
41 | }
42 | ```
43 |
44 | Данные по `base_unit` и `quote_unit` нужно вытянуть c поля `market`.
45 |
46 | При REST запросе на Ваш сервис, Ваше приложение должно взять данные со стороннего сервиса и выдать отформатированный ответ.
47 |
--------------------------------------------------------------------------------
/test_assignments/import_commits_app.md:
--------------------------------------------------------------------------------
1 | ## RoR: импорт коммитов из репозитория GitHub
2 |
3 | **Задание**
4 |
5 | Создайте простое приложение на Ruby on Rails 5, которое бы соответствовало следующим требованиям:
6 |
7 | * Приложение должно быть доступно в публичном репозитории на GitHub и содержать историю вашей работы над ним.
8 |
9 | * Если для запуска приложения будут необходимы другие приложения (СУБД и т.п.), то они должны устанавливаться и запускаться через Docker (docker-compose).
10 |
11 | * В файле `README.md` должна быть инструкция по инсталляции и запуску вашего приложения.
12 |
13 | * Для реализации приложения могут быть использованы любые сторонние библиотеки.
14 |
15 | * Необходимо написать тесты (Rspec) для контроллера и остального кода импортирующего данные коммитов.
16 |
17 | **Функционал**
18 |
19 | * Импорт всех коммитов определенного автора из репозитория с github.com в базу данных (см. http://developer.github.com/v3/repos/commits/ List commits on repository).
20 | Как пример: https://api.github.com/repos/thoughtbot/guides/commits.
21 |
22 | * Пользователь самостоятельно вводит `:owner`, `:repo`, `:author_email` и инициирует импорт.
23 |
24 | * Старые данные в базе заменяются новыми.
25 |
26 | * Отобразить коммиты в табличном виде по 10 записей на страницу.
27 |
28 | * Реализовать групповое удаление записей, которое производилось бы асинхронно без перезагрузки страницы.
--------------------------------------------------------------------------------
/test_assignments/import_commits_from_github.md:
--------------------------------------------------------------------------------
1 | ## RoR + PostgreSQL: приложение, которое импортирует коммиты GitHub в БД
2 |
3 | Создать простое приложение, которое импортирует все коммиты из репозитория на GitHub в базу данных (использовать PostgreSQL).
4 |
5 | **Функционал**
6 |
7 | - На главной странице приложения вы вводите имя пользователя GitHub и его репозиторий и инициируете импорт (перед новым импортом очищать таблицы).
8 |
9 | - Пример данных для импорта для пользователя `thoughtbot` и репозитория `guides`: https://api.github.com/repos/thoughtbot/guides/commits
10 |
11 | - В БД создать 2 таблицы:
12 |
13 | - `commits` (поля: дата коммита, user_id, хеш коммита, описание коммита);
14 |
15 | - `users` (поля: имя, email).
16 |
17 | - Результат импорта вывести в виде таблицы с постраничной разбивкой.
18 |
19 | - Добавить форму поиска коммитов по email пользователя.
20 |
21 | - Реализовать редактирование имени пользователя у какого-либо коммита, которое производилось бы асинхронно без перезагрузки страницы (обновление модели `User` и у всех коммитов на видимой странице).
22 |
23 | - Реализация импорта должна учитывать, что есть репозитории с десятками тысяч коммитов.
24 |
25 | **Требования**
26 |
27 | - Написать тесты на RSpec по импорту и моделям.
28 |
29 | - Результатом должно стать развернутое приложение (например, на Heroku) и ссылка на GitHub.
--------------------------------------------------------------------------------
/test_assignments/import_script_csv_to_psql.md:
--------------------------------------------------------------------------------
1 | В рамках тестового задания нужно разработать скрипт импорта товаров из csv файлов в базу данных PostgreSQL.
2 |
3 | В базе данных имеем таблицу товаров:
4 |
5 | ```ruby
6 | create_table "products", force: :cascade do |t|
7 | t.string "price_list"
8 | t.string "brand", null: false
9 | t.string "code", null: false
10 | t.integer "stock", default: 0, null: false
11 | t.decimal "cost", precision: 12, scale: 2, null: false
12 | t.string "name"
13 | end
14 | ```
15 |
16 | Есть 3 тестовых файла для импорта (прайса). (ссылки на прайсы в гугл.док утеряны.)
17 |
18 | Прайсы имеют различные типы разделителей `;` и `,`, также отстутствует единая последовательность в заголовках и их наименованиях. В одном из прайсов содержимое находилось в `""`.
19 |
20 | Соответствие колонок в тестовых файлах импорта:
21 |
22 | price_1.csv:
23 | * Производитель: brand
24 | * Артикул: code
25 | * Количество: stock
26 | * Цена: cost
27 | * Наименование: name
28 |
29 | price_2.csv:
30 | * Производитель: brand
31 | * Артикул: code
32 | * Количество: stock
33 | * Цена: cost
34 | * НаименованиеТовара: name
35 |
36 | price_3.csv:
37 | * Производитель: brand
38 | * Номер: code
39 | * Кол-во: stock
40 | * Цена: cost
41 | * Наименование: name
42 |
43 | Нужно учесть:
44 |
45 | * Уникальность code + brand в рамках одного price_list. В случае конфликта должен сохраниться последний
46 | * brand и code регистронезависимые. Т.е. TOYOTA и Toyota считаются одинаковыми
47 | * Повторный импорт прайса с измененными данными. Позиции, которых не стало в прайсе, не должны остаться в базе после импорта.
48 | * Если кол-во указано как > n, записывать n
49 | * Отбрасывать невалидные строки. При этом поле name не обязательное и может быть сохранено как пустое
50 | * Файлы могут содержать большое кол-во строк (до 1 млн). Можно добавлять колонки \ индексы в базу для оптимизации импорта
51 | * Могут быть другие прайсы с другим наименованием\последовательностью колонок
52 |
53 | * Не обязательно, но большим плюсом будут тесты RSpec
54 |
--------------------------------------------------------------------------------
/test_assignments/job_advertisement_site.md:
--------------------------------------------------------------------------------
1 | ## Ruby + JSON RESTful API: приложение с объявлениями о работе
2 |
3 | Сделать приложение на Ruby с JSON RESTful API.
4 |
5 | **Требования:**
6 |
7 | - Пользователь оставляет объявление (announcement) о работе, а другие пользователи могут на это объявление откликаться (response) с ценой («я могу за столько-то»).
8 |
9 | - Автор объявления может отменить (cancel) его. В этом случае все отклики должны быть автоматически отклонены (declined).
10 |
11 | - Автор может принять (accept) один из откликов, тогда другие отклики должны быть отклонены (declined), а объявление стать закрытым (closed).
12 |
13 | - На закрытое или отмененное объявление нельзя оставлять отклики.
14 |
15 | - Пользователь оставивший отклик может сам свой отклик отменить (cancel).
16 | В этом случае статус отклика должен быть cancelled, а не declined.
17 |
18 | - Также в API должны быть методы для получения своего объявления со всеми откликами и получения списка всех активных объявлений (без откликов).
19 |
20 | **Сущности**
21 |
22 | - `Announcement` (`id`, `user_id`, `description`, `status`),
23 | `description` — текст, не более 1000 символов;
24 |
25 | - `Response` (`id`, `announcement_id`, `user_id`, `price`, `status`),
26 | `price` - int, цена в рублях, от 100 до 10000;
27 |
28 | - `User` (`id`).
29 |
30 | **Статусы объявления**
31 |
32 | - `active` - активно, можно откликаться;
33 | - `cancelled` - отменено автором;
34 | - `closed` - закрыто (есть принятый отклик).
35 |
36 | **Статусы отклика на объявление**
37 |
38 | - `pending` - новый отклик;
39 | - `cancelled` - отменен автором отклика;
40 | - `declined` - отменен автором объявления (или автоматически, если объявление закрыто или отменено);
41 | - `accepted` - принято автором объявления.
42 |
43 | **Ограничения**
44 |
45 | - откликаться можно только на активное объявление;
46 | - если автор объявления отклонил чей-то отклик, то повторно откликаться нельзя;
47 | - если автор отклика отменил свой отклик, то он может повторно откликнуться на это же объявление.
48 |
49 | **Аутентификация**
50 |
51 | В API вместо полноценной аутентификации, можно передавать `user_id` в заголовках запроса.
52 |
53 | Также можно сделать эндпоинт для создания пользователя для тестов: POST/users, который будет создавать нового пользователя и возвращать его `id`.
54 |
55 | **Тесты**
56 |
57 | Обязательны.
58 |
59 | **Время на выполнение задания**
60 |
61 | Перед тем, как выполнять задание, оцените время на выполнение (без учета времени на настройку проекта). Напишите в README проекта оценку и фактическое время выполнения.
62 | Только честно :)
--------------------------------------------------------------------------------
/test_assignments/json_api_for_blog.md:
--------------------------------------------------------------------------------
1 | ## RoR: JSON API с экшенами для блога
2 |
3 | Задание на знания Ruby on Rails.
4 |
5 | **Требования**
6 |
7 | У нас имеется некий блог со следующими сущностями:
8 |
9 | 1. Юзер. Имеет только логин.
10 |
11 | 2. Пост, принадлежит юзеру. Имеет заголовок, содержание, айпи автора (сохраняется отдельно для каждого поста).
12 |
13 | 3. Оценка, принадлежит посту. Принимает значение от 1 до 5.
14 |
15 | **Задача**
16 |
17 | Создать JSON API на RoR со следующими экшенами:
18 |
19 | 1. Создать пост. Принимает заголовок и содержание поста (не могут быть пустыми), а также логин и айпи автора. Если автора с таким логином еще нет, необходимо его создать. Возвращает либо атрибуты поста со статусом 200, либо ошибки валидации со статусом 422.
20 |
21 | 2. Поставить оценку посту. Принимает айди поста и значение, возвращает новый средний рейтинг поста.
22 |
23 | Важно: экшен должен корректно отрабатывать при любом количестве конкурентных запросов на оценку одного и того же поста.
24 |
25 | 3. Получить топ N постов по среднему рейтингу. Просто массив объектов с заголовками и содержанием.
26 |
27 | 4. Получить список айпи, с которых постили несколько разных авторов. Массив объектов с полями: айпи и массив логинов авторов.
28 |
29 | **Технологии**
30 |
31 | Ruby 2.5+, RoR 5+, PostgreSQL 10+. Результат лучше всего опубликовать на GitHub.
32 |
33 | Базу данных используем PostgreSQL. Для девелопмента написать скрипт в `db/seeds.rb`, который генерирует тестовые данные. Часть постов должна получить оценки. Скрипт должен использовать тот же код, что и контроллеры, можно вообще дергать непосредственно сервер курлом или ещё чем-нибудь.
34 |
35 | Постов в базе должно быть хотя бы 200K, авторов лучше сделать в районе 100 штук, айпишников использовать штук 50 разных. Экшены должны на стандартном железе работать достаточно быстро как для указанного объёма данных (быстрее 100ms), так и для намного большего, то есть нужен хороший запас в плане оптимизации запросов. Для этого можно использовать денормализацию данных и любые другие средства БД.
36 |
37 | Можно использовать любые нужные гемы, обязательно наличие спеков, хорошо покрывающих разные кейсы. В коде желательно не использовать рельсовых антипаттернов (типа коллбэков и валидаций в моделях), сервис-классы наше всё. Также желательно не использовать генераторов и вообще обойтись без лишних мусорных файлов в репозитории.
--------------------------------------------------------------------------------
/test_assignments/json_api_service_without_rails.md:
--------------------------------------------------------------------------------
1 | ## Требуется создать JSON API сервис на Ruby без использования Ruby on Rails.
2 |
3 | В качестве веб-фреймворка, необходимо использовать *sinatra, hanami, roda* или что-нибудь другое, но **не** *Ruby on Rails*. Доступ к БД можете осуществлять с помощью *ORM (active_record, sequel, rom)*, можете и без *ORM*, как посчитаете нужным.
4 |
5 |
6 | **Сущности:**
7 |
8 | 1. User.
9 | - Имеет только логин.
10 | 2. Post.
11 | - Принадлежит юзеру.
12 | - Имеет заголовок, содержание, айпи автора (сохраняется отдельно для каждого поста).
13 | 3. Rating.
14 | - Принадлежит посту.
15 | - Принимает значение от 1 до 5.
16 |
17 | **Экшены:**
18 |
19 | 1. Создать пост.
20 | - Принимает заголовок и содержание поста (не могут быть пустыми), а также логин и айпи автора. Если автора с таким логином еще нет, необходимо его создать.
21 | - Возвращает либо атрибуты поста со статусом 200, либо ошибки валидации со статусом 422.
22 | 2. Поставить оценку посту.
23 | - Принимает айди поста и значение.
24 | - Возвращает новый средний рейтинг поста.
25 | - **Важно:** *экшен должен корректно отрабатывать при любом количестве конкурентных запросов на оценку одного и того же поста.*
26 | 3. Получить топ N постов по среднему рейтингу.
27 | - Просто массив объектов с заголовками и содержанием.
28 |
29 |
30 | 4. Получить список айпи, с которых постило несколько разных авторов.
31 | - Массив объектов с полями: айпи и массив логинов авторов.
32 |
33 | **Дополнительно:**
34 |
35 | - Базу данных используем *PostgreSQL*. Для девелопмента написать скрипт в *db/seeds.rb*, который генерирует тестовые данные. Часть постов должна получить оценки. Скрипт должен использовать созданный *JSON API* сервер (можно посылать запросы курлом или еще чем-нибудь).
36 | - Постов в базе должно быть хотя бы 200к, авторов лучше сделать в районе 100 штук, айпишников использовать штук 50 разных.
37 | - Экшены должны на стандартном железе работать достаточно быстро как для указанного объема данных (быстрее 100 мс, если будет работать медленнее, то ничего страшного, все равно присылайте решение), так и для намного большего, то есть нужен хороший запас в плане оптимизации запросов. Для этого можно использовать денормализацию данных и любые другие средства БД. Можно использовать любые нужные гемы, обязательно наличие спеков, хорошо покрывающих разные кейсы. Архитектуру сервиса организуйте на "свой вкус". Желательно не использовать генераторов и вообще обойтись без лишних мусорных файлов в репозитории.
38 |
--------------------------------------------------------------------------------
/test_assignments/lunch_ordering_saas.md:
--------------------------------------------------------------------------------
1 | # Lunch Ordering SaaS
2 |
3 | Each company that uses the services of delivery meals, sooner or later, comes to the great and original idea to develop their own service to order a lunch. Many start, but only few of them bring it to the end. The objective of this task is to develop very small MVP, which could be taken and used already in production.
4 |
5 | We will try to simplify the problem as much as possible. Please find User Stories below. Let’s assume that there is only one organization in the application, all users belong to it.
6 |
7 | * As a guest I should be able to sign up with name, email and password.
8 | * As a guest I should be able to sign in with email and password.
9 | * As a first registered user in the system, I became a Lunches Admin.
10 | * As a user I can edit my profile
11 | * As a user I can see a weekdays on the dashboard page
12 | * As a user, when I click on the weekday(today or days in the past), I can see menu list of items with prices.
13 | * As a user, when I choose items from menu, I can only choose one item from the first course, one item from the main course and one drink. Total 3 items.
14 | * As a user I can press Submit button to process my order.
15 | * As a Lunches Admin, I can browse registered users.
16 | * As a Lunches Admin, I can browse days and see users’ orders there.
17 | * As a Lunches Admin, I can add items in menu only for today by adding a name and price.
18 | * As a Lunches Admin, I can upload photo for each menu item
19 | * As a Lunches Admin, on the date page I can see the list of orders and total lunch cost for today.
20 |
21 | Let’s assume that instead of calling to the Lunches Delivery Company, they have a smart ERP which can request the order for today through our API at a specific time.
22 |
23 | * As a system, I should be able to provide list of the orders for today with details for each person through RESTful JSON API endpoint.
24 | * As a system, I should have a secure API.
25 |
26 | General Notes
27 |
28 | * Keep your code clean.
29 | * Thin controllers, fat models. Don’t forget about validations
30 | * Prefer quality to the speed of delivering this task
31 | * The code should be covered with unit, functional and integration tests. (Please use RSpec+Capybara)
32 | * Frontend can be pretty very simple.
33 | * The source code of application should be uploaded on github.com and deployed to heroku in the end.
34 | * Connect TravisCI to your public repository
35 |
36 | Recommended technologies If you know your way, skip this step. Otherwise we are expecting from you to use these gems in project Rails 4+, devise, twitter bootstrap, haml, simple_form, carrierwave, rspec, capybara
37 |
38 | Next complexity level:
39 |
40 | * Add organizations
41 | * Add registration through Google Apps
42 | * Auto Suggest for menu items
43 | * Weekly Menus
44 |
--------------------------------------------------------------------------------
/test_assignments/meals_delivery_service.md:
--------------------------------------------------------------------------------
1 | ## RoR: meals delivery service
2 |
3 | **Requirements**
4 |
5 | Each company that uses the services of delivery meals, sooner or later, comes to the great and original idea to develop their own service to order a lunch. Many start, but only few of them bring it to the end. The objective of this task is to develop very small MVP, which could be taken and used already in production.
6 |
7 | We will try to simplify the problem as much as possible. Please find User Stories below. Let's assume that there is only one organization in the application, all users belong to it.
8 |
9 | - As a guest I should be able to sign up with name, email and password
10 |
11 | - As a guest I should be able to sign in with email and password
12 |
13 | - As a first registered user in the system, I become a Lunches Admin
14 |
15 | - As a user I can edit my profile
16 |
17 | - As a user I can see a weekdays on the dashboard page
18 |
19 | - As a user, when I click on the weekday(today or days in the past), I can see menu list of items with prices
20 |
21 | - As a user, when I choose items from menu, I can only choose one item from the first
22 | course, one item from the main course and one drink. Total 3 items
23 |
24 | - As a user I can press Submit button to process my order
25 |
26 | - As a Lunches Admin, I can browse registered users
27 |
28 | - As a Lunches Admin, I can browse days and see users’ orders there
29 |
30 | - As a Lunches Admin, I can add items in menu only for today by adding a name and
31 | price
32 |
33 | - As a Lunches Admin, I can upload photo for each menu item
34 |
35 | - As a Lunches Admin, on the date page I can see the list of orders and total lunch cost for today
36 |
37 | Let’s assume that instead of calling to the Lunches Delivery Company, they have a smart ERP which can request the order for today through our API at a specific time.
38 |
39 | - As a system, I should be able to provide list of the orders for today with details for each person through RESTful JSON API endpoint
40 |
41 | - As a system, I should have a secure API
42 |
43 | **General Notes**
44 |
45 | - Keep your code clean
46 |
47 | - Thin controllers, fat models. Don’t forget about validations
48 |
49 | - Prefer quality to the speed of delivering this task
50 |
51 | - The code should be covered with unit, functional and integration tests. (Please use RSpec+Capybara)
52 |
53 | - Frontend can be pretty very simple
54 |
55 | - The source code of application should be uploaded on GitHub and deployed to
56 | Heroku in the end
57 |
58 | - Connect TravisCI to your public repository
59 |
60 | **Recommended technologies**
61 |
62 | If you know your way, skip this step. Otherwise we are expecting from you to use these gems in project: Rails 4+, Devise, Twitter Bootstrap, HAML, simple_form, Carrierwave, RSpec, Capybara.
63 |
64 | **Next complexity level**
65 |
66 | - Add organizations
67 |
68 | - Add registration through Google Apps
69 |
70 | - Auto Suggest for menu items
71 |
72 | - Weekly Menus
--------------------------------------------------------------------------------
/test_assignments/news_site_API.md:
--------------------------------------------------------------------------------
1 | ## RoR: JSON API для новостного сайта
2 |
3 | **Задание**
4 |
5 | 1. Спроектировать БД.
6 | 2. Реализовать API согласно ТЗ.
7 | 3. Реализовать аутентификацию в АПИ (регистрацию можно не делать).
8 | 4. Подготовить тестовые данные (дамп базы, скрипт для генерации тестового набора данных).
9 | 5. Покрыть код тестами.
10 | 6. Выложить код в репозиторий на GitHub.
11 |
12 | Формат маршрутов для доступа к методам, а также формат ответа и запросов можете выбрать и реализовать сами.
13 |
14 | **Условия**
15 |
16 | _Новость_
17 | Представляет собой объект новости и должен содержать следующую информацию:
18 | * заголовок;
19 | * анонс;
20 | * текст;
21 | * статус (опубликована, не опубликована).
22 |
23 | _Пользователь_
24 | Содержит в себе как минимум информацию о конкретном пользователе, а именно:
25 | * логин;
26 | * пароль;
27 | * ФИО;
28 | * подпись.
29 |
30 | Функции:
31 | * может создавать новость;
32 | * может обновлять/удалять свою новость;
33 | * может добавлять новость в избранное.
34 |
35 | _Функции каталога_
36 | Взаимодействие с пользователем происходит посредством HTTP-запросов к API серверу. Все ответы представляют собой JSON объекты.
37 |
38 | _Сервер реализует следующие методы_
39 | * только аутентифицированный пользователь может создавать/обновлять новости;
40 | * выдача всех новостей конкретного автора;
41 | * выдача списка авторов;
42 | * выдача списка новостей;
43 | * показывать запрошенную новость;
44 | * выдача всех непрочитанных пользователем новостей.
45 |
46 | **Используемые технологии**
47 |
48 | При выполнении задания используйте следующие технологии:
49 | * Ruby не ниже 2.5;
50 | * Rails 5;
51 | * RSpec;
52 | * БД Postgres;
--------------------------------------------------------------------------------
/test_assignments/oblako_group_test_app.md:
--------------------------------------------------------------------------------
1 | ## Oblako Group Test-app
2 |
3 | Необходимо сделать API, позволяющее рендерить содержимое страницы, за это отвечает экшн GET /projects, который возвращает всю структуру, необходимую для рендеринга страницы:
4 | image
5 |
6 | Далее на странице имеется функционал, позволяющий перечеркивать задачи, для этого нужно реализовать отдельный экшн для обновления задачи PATCH /project/:id/todos/:id, который в свою очередь будет обновлять значение checked.
7 |
8 | Далее рассмотрим окно создания задачи. Тут нужно предусмотреть следующее: задача может быть добавлена в существующий список, либо в новый. Таким образом, если в списке выбора категории выбрать пункт «Новая категория», должно появиться поле для ввода названия нового списка, и, после сабмита формы, список должен отобразиться на главной странице с новой задачей. Для этих целей на стороне апи лучше всего сделать экшн POST /todos.
9 |
10 | Стоит за ранее позаботиться о сидах, с которыми будет удобно разрабатывать и проверять приложение. В качестве примера можно использовать этот файл.
11 |
12 | Таким образов в результате API должен предоставлять следующие методы:
13 |
14 | GET /projects - вернуть все проекты с задачами
15 | POST /todos - создать новую задачу
16 | PATCH /projects/id/todo/id - обновить задачу
17 |
18 | ### API принимает следующие параметры:
19 |
20 | - todo[todoname] - имя задачи (string)
21 | - project[projectname] - имя проекта (string)
22 | - project[id] - id проекта (integer)
23 |
--------------------------------------------------------------------------------
/test_assignments/pdf_diploma_generator.md:
--------------------------------------------------------------------------------
1 | ## RoR: генерация pdf-файлов (дипломов) по гитхабу
2 |
3 | Мы в UCHi.RU пишем на руби и нам часто приходится иметь дело с обработкой JSON.
4 | Ещё мы проводим онлайн-олимпиады и генерируем pdf-дипломы на лету.
5 | Поэтому наше задание про это.
6 |
7 | **Задание**
8 |
9 | Нужно по адресу публичного репозитория на гитхабе найти трёх его самых активных контрибьюторов и сгенерировать для них простые pdf-дипломы и архив с ними.
10 |
11 | Спроектируйте приложение, напишите тесты проверяющие его работоспособность,
12 | и разверните его на любой публичной платформе (например, на бесплатном аккаунте в Хероку).
13 | Код, конечно же, должен быть на Гитхабе.
14 |
15 | **Полезные ссылки, которые могут пригодится:**
16 |
17 | Git:
18 | https://git-scm.com/book/en/v2
19 | https://proglib.io/p/git-for-half-an-hour
20 | http://gitimmersion.com/index.html
21 | https://learngitbranching.js.org
22 | https://try.github.io/levels/1/challenges/3
23 |
24 | Docker:
25 | https://www.docker.com
26 | https://habrahabr.ru/post/253877
27 | http://rus-linux.net/MyLDP/vm/docker/docker-tutorial.html
28 | https://proglib.io/p/docker
29 | https://habrahabr.ru/post/310460
30 |
31 | Хероку:
32 | https://blog.heroku.com/container-registry-and-runtime
33 | https://devcenter.heroku.com/articles/container-registry-and-runtime
34 |
--------------------------------------------------------------------------------
/test_assignments/player_statistics.md:
--------------------------------------------------------------------------------
1 | ## RoR: консольное приложение для проверки статистики футбольных матчей
2 |
3 | **Предметная область**
4 |
5 | * Есть игроки, которые играют за команду, принимая участие в матчах.
6 | * Есть показатели (например, «пробежал 10+ км», «сделал 70% точных передач»).
7 | * Игроки в каждом матче какие-то показатели выполняют, а какие-то нет.
8 |
9 | **Задание**
10 |
11 | Создать модели к данной предметной области.
12 |
13 | Написать методы, которые позволяют:
14 |
15 | * отметить, что игрок выполнил такой-то показатель в матче;
16 | * проверить выполнил ли игрок конкретный показатель хотя бы один раз за предыдущие 5 матчей команды;
17 | * выбрать топ-5 игроков по конкретному показателю в конкретной команде и по всем командам в целом.
18 |
19 | P.S. Полный набор атрибутов в моделях не принципиален, так что можно обойтись минимальным.
--------------------------------------------------------------------------------
/test_assignments/price_list_export_algorithms_for_marketplace.md:
--------------------------------------------------------------------------------
1 | ## RoR: выгрузка тестового прайс-листа и создание карточек для онлайн-магазина
2 |
3 | **Задание**
4 |
5 | Для создания нового маркетплейса необходимо произвести выгрузку из тестового прайс-листа, [ссылка на прайс-лист](https://drive.google.com/open?id=1422EskkhBB2Yj7SaVN7Qn4o2ZkFOosY0).
6 |
7 | За основу берем стандарты Яндекс.Маркет по обработке и вводу информации в
8 | прайс-листы, формируемые поставщиками.
9 |
10 | **Способы ввода информации:**
11 |
12 | - Автоматический. Обработка csv/xls из указанных источников. Источник указываем в административном модуле, при заполнении карточки поставщика.
13 |
14 | - Ручной. Ввод товарной позиции (разделов и подразделов) производится в ручном режиме в административном модуле с назначением поставщика.
15 |
16 | Важно: при автоматическом и ручном вводе информации необходимо избегать конфликта версий для согласованности разделов и подразделов.
17 |
18 | В первой итерации создаем административный модуль только для внутреннего использования (роль Супер-администратор). Данный модуль должен включать в себя информацию о загруженных прайс-листах и поставщиках в виде простой таблички.
19 |
20 | Ручной метод ввода товарной карточки, разделов и подразделов пока реализовывать не нужно. Административный модуль может использовать любой предложенный вами дашборд (GUI, с которым вам проще работать).
21 |
22 | **Фильтры**
23 |
24 | Реализовать на основе главных передаваемых параметров в данной товарной категории (бренд, размеры, вес и так далее). Для MVP допустимо автоматическое отображение фильтров.
25 |
26 | В следующей итерации необходимо реализовать настройку отображения фильтров в ручном режиме.
27 |
28 | **Сортировка**
29 |
30 | В данной первой итерации рассматриваем следующие алгоритмы сортировки: сначала дешевле, сначала дороже, по алфавиту.
31 |
32 | **GUI**
33 |
34 | Для тестирования MVP требуется использовать один из популярных CSS-фреймворков. Мы работаем со следующими сборками: http://getbootstrap.com/, https://getmdl.io/,https://materializecss.com/
35 |
36 | [Примерный визуальный образ каталога](https://www.figma.com/proto/LT7nmllCTYQmZ4EwmrrDkGp5/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC-%D0%B4%D0%BB%D1%8F-%D0%BC%D0%B0%D0%B3%D0%B0%D0%B7%D0%B8%D0%BD%D0%BE%D0%B2?node-id=122%3A185&scaling=min-zoom).
37 |
38 | К работе над товарными карточками переходим после реализации загрузки данного прайс-листа (и двух-трех дополнительных листов от других поставщиков). Дополнительные прайс-листы для тестирования будут созданы позже.
--------------------------------------------------------------------------------
/test_assignments/prototype_for_car_hiring_system.md:
--------------------------------------------------------------------------------
1 | ## JSON API: прототип для системы бронирования авто
2 |
3 | **Задание**
4 |
5 | В рамках тестового задания нужно разработать прототип системы бронирования автомобилей.
6 |
7 | **Условия**
8 |
9 | В базе содержится определенное количество автомобилей различных марок и года выпуска, а также стоимость брони за один день. Считаем, что авто в базу заносятся через другое приложение, писать для этого API не нужно.
10 |
11 | Клиент может забронировать единовременно только один автомобиль. Минимальный срок аренды автомобиля — 1 день, максимальный — 30 дней. Клиент может делать поиск доступных авто на определённые даты. Клиент может забронировать доступный авто. В момент бронирования клиенту начисляются бонусы равные стоимости брони.
12 |
13 | Итак, в рамках ТЗ должно получится бэкенд-приложение с:
14 |
15 | 1. Endpoint для регистрации клиента (Sign up);
16 |
17 | 2. Endpoint для входа (Sign in);
18 |
19 | 3. Endpoint для поиска авто на заданные даты;
20 |
21 | 4. Endpoint для бронирования авто;
22 |
23 | 5. Endpoint для истории броней клиента;
24 |
25 | Формат для всех endpoint - JSON.
26 |
27 | Не обязательно, но большим плюсом будет документация к API, доступная по какому-либо URL.
28 |
29 | Исходный код можете разместить на GitHub или Bitbucket.
--------------------------------------------------------------------------------
/test_assignments/rails_api_for_real_estate_site.md:
--------------------------------------------------------------------------------
1 | ## RoR + Ember: API для сайта продажи/аренды недвижимости
2 |
3 | **Условия**
4 |
5 | *Ember*
6 |
7 | Модели:
8 |
9 | - `Building` (здание). Поля: `class:string`, `street:string`, `house_number:string`, `floors:number`;
10 |
11 | - `Block` (офисные блоки). Поля: `area:number`, `floor:number`;
12 |
13 | - `Price` (цена). Поля: `value:number`, `currency:number`, `1` — рубли, `2` — доллары, `3` — евро).
14 |
15 | Связи:
16 |
17 | - `Building hasMany Blocks`;
18 |
19 | - `Block belongsTo Building`;
20 |
21 | - `Block hasMany Offers`;
22 |
23 | - `Offer belongsTo Price`.
24 |
25 | Создать раут `buildings`.
26 |
27 | Создать `template buildings`, в котором будут 4 `input` поля (класс, улица, номер дома и этаж) и кнопка «Добавить».
28 |
29 | При нажатии на кнопку «Добавить» отправлять save-запрос к API, в промисе мы добавляем созданный `building` в массив `buildings`. После этого зачищаем форму. Ниже формы отображаем массив созданных `buildings`.
30 |
31 | **Дополнительно:**
32 |
33 | В `template buildings` добавить возможность добавлять `block` => `offer` => `price`. То есть помимо обычных инпутов в форму создания здания добавить ещё кнопку «Добавить блок». При нажатии на неё появляется форма с инпутами для создания модели `block`, которая привязывается к модели `building`. В форме блока, соответственно, есть кнопка «Добавить предложение», при нажатии на которую появляется форма с полями `offer` и кнопкой «Добавить цену». Цена по аналогии.
34 |
35 | *Rails*
36 |
37 | Создать небольшое API.
38 |
39 | Модели:
40 |
41 | - `Building` (здание). Поля: `class:string`, `street:string`, `house_number:string`, `floors:integer`;
42 |
43 | - `Block` (офисные блоки). Поля: `area:integer`, `floor:integer`;
44 |
45 | - `Offer` (предложение). Поля: `offer_type:string`, `rent` — аренда, `sale` — продажа;
46 |
47 | - `Price` (цена). Поля: `value:integer` (limit — 8), `currency:integer`, `1` — рубли, `2` — доллары, `3` — евро).
48 |
49 | Связи:
50 |
51 | - `Building has_many :blocks`;
52 |
53 | - `Block belongs_to :building`;
54 |
55 | - `Block has_many :offers`;
56 |
57 | - `Offer has_one :price`.
58 |
59 | Контроллеры:
60 |
61 | Создать контроллер для `building` с методами `create`, `update`, `delete`, `index`, `show`.
62 |
63 | В `create` должна создаваться модель `Building` (без параметров в запросе, просто вызывать метод создания модели). Возвращать `render json` созданной модели.
64 |
65 | В `update` должна сохраняться модель `Building` с соответствующим `id` (без параметров в запросе, просто вызывать метод сохранения модели). Возвращать `render json` созданной модели.
66 |
67 | В `delete` удалять модель с соответствующим `id`.
68 |
69 | В `show` возвращать `render json` модели `Building` с определённым `id`.
70 |
71 | В `index` возвращать `Building`. В `params` могут быть переданы все поля модели `building` и по ним желательно вести поиск и возвращать отфильтрованные значения.
72 |
73 | Выбор БД на ваше усмотрение.
74 |
75 | *SQL*
76 |
77 | Написать одинаковые запросы на SQL и на Rails ORM.
78 |
79 | Найти все офисные блоки от 150 до 300 кв.м включительно, которые находятся на 1, 8 или 10 этажах, сдаются в аренду по цене не более $5000 в зданиях класса «А» на Пресненской набережной.
80 |
81 | *Объединение frontend + backend + БД*
82 |
83 | С фронта отправлять запрос на созданное Rails API. В `create` методе `buildings_controller` берём поля из тела POST-запроса.
--------------------------------------------------------------------------------
/test_assignments/rest_api_for_blog.md:
--------------------------------------------------------------------------------
1 | ## RoR: REST API для блога
2 |
3 | ### Часть 1. REST API для блога
4 |
5 | **1.1 Модели**
6 |
7 | `Post` — записи в блоге,
8 |
9 | - `title` — строковое, обязательное
10 | - `body` — строковое, обязательное
11 | - `author` — ссылка на автора
12 | - `published_at` — дата-время размещения записи
13 |
14 | `Comment` — комментарии к записям
15 |
16 | - `body` — строковое, обязательное
17 | - `author` — ссылка на автора
18 | - `published_at` — дата-время размещения комментария
19 |
20 | `User` — пользователи. Поскольку у нас есть авторы, нужна модель в которой мы будем их хранить.
21 |
22 | - `nickname` — строковое, обязательное
23 | - `email` — строковое, обязательное
24 | - `password` — строковое, обязательное
25 |
26 | **1.2 Эндпоинты**
27 |
28 | - Реализовать эндпойнт для аутентификации. Как его сделать, up to you.
29 | - POST /api/v1/posts.json
30 |
31 | Отправляем:
32 |
33 | - `title`
34 | - `body`
35 | - `published_at`
36 |
37 | В ответ получаем json с полями:
38 |
39 | - `id`
40 | - `title`
41 | - `body`
42 | - `published_at`
43 | - `author_nickname`
44 |
45 | Если в запросе не передали `published_at`, то нужно подставлять текущий момент времени. Если передали не все поля, то ответ должен содержать одно поле `errors` — массив ошибок.
46 |
47 | - GET /api/v1/posts/:post_id.json
48 |
49 | Получить post по его id, поля в ответе как в эндпойнте POST /api/v1/posts.json
50 |
51 | - GET /api/v1/posts.json
52 | Отправляем:
53 |
54 | - `page`
55 | - `per_page`
56 |
57 | Получаем в ответ список записей отсортированных полю published_at по убыванию поля каждой записи как в эндпойнте POST /api/v1/posts.json. В заголовках ответа нужно передать общее количество страниц и записей.
58 |
59 | - Эндпойнты для комментариев можно не делать
60 |
61 | **1.3 Прочие требования**
62 |
63 | - Rails 5.x
64 | - Postgres 9.x
65 | - Rspec 3.x
66 | - Json — ActiveModelSerializer или jsonapi-resources
67 | - В таблицах нужно указывать все необходимые индексы
68 | - Код моделей и контроллеров нужно покрыть тестами
69 | - Работающее приложение нужно разместить на heroku
70 |
71 | ### Часть 2. Интерфейс, загрузка файлов и фоновые задачи
72 |
73 | **2.1 Загрузка аватара**
74 |
75 | На базе первой части сделать страницу, где пользователь может загрузить свой
76 | аватар. Интерфейс может быть простейшим, сделанным на дефолтном бутстрапе.
77 | Пользователю нужно выбирать файл `jpg/png` размером до 3мб, загружать его и видеть
78 | его превью после загрузки, урезанный до 300x300px. Файлы нужно загружать на S3
79 |
80 | **2.2 Аналитический отчет**
81 |
82 | На базе первой части , сделать аналитический отчёт.
83 |
84 | Эндпоинт: POST /api/v1/reports/by_author.json
85 |
86 | Параметры запроса:
87 |
88 | - `start_date` — начало интервала
89 | - `end_date` — конец интервала
90 | - `email` — куда отправить отчёт
91 |
92 | Поля в ответе:
93 |
94 | - `message: “Report generation started”`
95 |
96 | Эндпоинт добавляет задачу на генерацию отчёта в очередь, очередь обрабатывается отдельным процесом. Готовый отчёт отправляется на email указанный в задаче.
97 |
98 | Отчёт должен представлять собой таблицу со столбцами:
99 |
100 | - `nickname`
101 | - `email`
102 | - количество записей за период
103 | - количество комментариев за период
104 |
105 | Строки в отчёте должны быть отсортированы по значению вычисляемому как (количество постов + количество комментариев/10). Таблицу можно оформить как в виде html таблицы так и при помощи ASCII символов. Для этого задания нужно заполнить базу тестовыми данными, для чего удобно использовать gem `faker`.
106 |
107 | **2.3 Общие требования ко второй части**
108 |
109 | Результат выполнения второй части тестового задания так же нужно опубликовать на
110 | heroku в виде работающего приложения.
111 |
--------------------------------------------------------------------------------
/test_assignments/restaurants_with_tables.md:
--------------------------------------------------------------------------------
1 | Необходимо сделать систему для резервации столов в ресторанах.
2 |
3 | В каждом ресторане есть столы. Эти столы можно резервировать. При этом шаг резервации - 30 минут, а пользователь может резервировать стол на 30, 60, 90 и т.д. минут. В каждой резервации должен быть пользователь. У каждого ресторана есть график работы, который может переваливать за полночь. Резервации на один стол не должны пересекаться. При этом, если одна резервация закончилась в 5 вечера, вторая может начинаться в 5 вечера.
4 |
5 | Интересует только реализация моделей и структура базы данных.
6 |
7 | Обязательные условия выполнения:
8 |
9 | * 2 коммита с разрывом в 2 часа. 1 коммит - стартовая инициализация проекта. 2 коммит - готовая работа.
10 | * Исключить из Gitignore папку Log.
11 | * Продумать шаги по улучшению кода, если бы было больше времени и описать их в сопроводительном письме к решению тестового.
12 |
--------------------------------------------------------------------------------
/test_assignments/ror_api_reference_counting.md:
--------------------------------------------------------------------------------
1 | ## Реализуйте web-приложение для простого учета посещенных (неважно, как, кем и когда) ссылок.
2 |
3 |
4 | **Требования к приложению:**
5 | - Приложение предоставляет *JSON API* по *HTTP*.
6 | - Приложение предоставляет два *HTTP* ресурса.
7 |
8 | **Ресурсы:**
9 | 1. Ресурс загрузки посещений.
10 | - Принимает *POST*-запрос, по адресу `/visited_links`, в формате: `{"links": ["https://ya.ru", "https://ya.ru?q=123"]}`
11 | - Ресурс служит для передачи в сервис массива ссылок в *POST*-запросе. Вре-
12 | менем их посещения считается время получения запроса сервисом.
13 |
14 |
15 | 2. Ресурс получения статистики:
16 | - Принимает *GET*-запрос, по адресу `/visited_domains`, формата: `/visited_domains?from=1545221231&to=1545217638`
17 | - Отдает ответ формата: `{ "domains": ["ya.ru"], "status": "ok" }`
18 | - Ресурс служит для получения *GET*-запросом списка уникальных доменов, посещенных за переданный интервал времени.
19 |
--------------------------------------------------------------------------------
/test_assignments/shop_dashboard.md:
--------------------------------------------------------------------------------
1 | ## RoR: панель администратора магазина
2 |
3 | **Задание**
4 |
5 | Тестовое задание заключается в написании несложного управляющего интерфейса для магазина загогулин.
6 |
7 | **Условия**
8 |
9 | На сайте магазина загогулин отображаются товары (загогулины), разбитые по категориям.
10 |
11 | Категории имеют древовидную структуру. У категории есть название, родитель (другая категория или `NULL`) и слаг (генерируется автоматически из названия товара, если не задан).
12 |
13 | Товар принадлежит к одной категории, имеет название, слаг, изображение и описание.
14 |
15 | **Требования**
16 |
17 | Необходимо:
18 |
19 | 1. Сделать раздел редактирования категорий товаров. Администратор может: создать категорию, изменить категорию, удалить категорию (товары не
20 | должны в ней удаляться), изменить порядок категорий внутри ветки (перетаскиванием, на странице списка), переподчинить категорию другому родителю (перетаскиванием).
21 |
22 | 2. Сделать раздел редактирования товаров. Администратор может: cоздать товар (выбрав соответствующую категорию, и загрузив при этом изображение), удалить товар, изменить товар.
23 |
24 | 3. Запрограммировать навигацию по двум разделам («Товары» и «Категории») в соответствии со стандартными правилами, чтобы всегда было понятно «Где я нахожусь?» и «Куда я могу отсюда пойти?»
25 |
--------------------------------------------------------------------------------
/test_assignments/shop_with_checkout.md:
--------------------------------------------------------------------------------
1 | ## Ruby: функция Checkout для магазина
2 |
3 | **Условия**
4 |
5 | Дан список товаров:
6 |
7 | | Код | Название | Цена |
8 | | ------ | ---------- | ------ |
9 | | CC | Кока Кола | $1.50 |
10 | | PC | Пепси Кола | $2.00 |
11 | | WA | Вода | $0.85 |
12 |
13 | Для некоторых продуктов есть определенные правила дисконтирования:
14 |
15 | - если покупаете 3 и более бутылки Пепси Колы, то стоимость каждой бутылки Пепси Колы снижается на 20%;
16 |
17 | - если покупаете одну бутылку Кока Колы, то вторая даётся бесплатно.
18 |
19 | **Задача**
20 |
21 | Реализуйте класс `Checkout` и необходимые дополнительные классы, которые считают общую стоимость покупки.
22 |
23 | **Пример использования:**
24 |
25 | ```
26 | co = Checkout.new(pricing_rules)
27 | co.add(item)
p
28 | co.total
29 | ```
30 |
31 | Примеры:
32 |
33 | - Input: CC PC WA
34 |
35 | Output: $4.35
;
36 |
37 | - Input: CC PC CC CC
38 |
39 | Output: $5.00
;
40 |
41 | - Input: PC CC PC WA PC CC
42 |
43 | Output: $7.15
;
44 |
45 | Оценивается работоспособность, структура, архитектура, используемые шаблоны проектирования и тесты (используйте RSpec).
--------------------------------------------------------------------------------
/test_assignments/simple_to_do_list.md:
--------------------------------------------------------------------------------
1 | ## RoR + Ember: простой трекер задач
2 |
3 | **Функционал:**
4 |
5 | - создание задач;
6 |
7 | - закрытие (закрытые должны быть перечеркнутыми) и переоткрытие задач;
8 |
9 | - удаление задач.
10 |
11 | **Внешний вид:**
12 |
13 | У задачи должно быть название, расширенное описание и приоритет (minor, major, critical). [Примерный вид начальной страницы (`url/tasks`)](http://joxi.ru/5mdoZxeS96war1).
14 |
15 | Строки списка должны быть раскрашены в зависимости от приоритета (критичный — красный, мажорный — жёлтый, минорный — зелёный). [Примерный вид добавления задачи (`url/task/new`)](http://joxi.ru/v29DKEVcBLB5mG) (слева все тот же список задач, а справа форма добавления новой задачи).
16 |
17 | Для верстки использовать foundation. [Аддон для эмбера](https://www.npmjs.com/package/ember-cli-foundation-6-sass).
18 |
19 | **Технологии:**
20 |
21 | - backend: RoR 5.2+ (API mode);
22 |
23 | - frontend: Ember.js 3.2+;
24 |
25 | - DB: MongoDB.
--------------------------------------------------------------------------------
/test_assignments/solving_mathematical_equations_app.md:
--------------------------------------------------------------------------------
1 | ## RoR: система решения математических уравнений
2 |
3 | **Задание**
4 |
5 | Система должна состоять из двух основных компонентов: фронтенд и бэкенд сервер.
6 |
7 | _**Фронтенд** сервер — основной функционал_
8 |
9 | RoR приложение должно предоставлять:
10 |
11 | 1. Выбор типа уравнения (по умолчанию линейное и квадратное).
12 |
13 | 2. Форму ввода параметров для решения уравнения.
14 |
15 | 3. Передачу параметров уравнения на бэкенд сервер в формате JSON.
16 |
17 | 4. Получение и отображение результата в «дружественном» виде.
18 |
19 | _Дополнительные пожелания_
20 |
21 | 1. Использование CSS на формах / страницах «Выбор», «Вввод», «Результат».
22 |
23 | 2. Использование JS / Ajax / JS-framework на формах / страницах «Выбор», «Ввод», «Результат».
24 |
25 | 3. Использование тестовых фреймворков TestUnit / RSpec / Cucumber (один или несколько).
26 |
27 | 4. Обеспечить валидацию параметров и обработку исключительных ситуаций (500 от бэкенда, ввод буквенных параметров,
28 | ввод дробных параметров и т.д.).
29 |
30 | _**Бэкенд** сервер — основной функционал_
31 |
32 | Допустимо использование приложения на Sinatra или подобном фреймворке. Приложение должно:
33 |
34 | 1. Предоставить точку входа для получения параметров уравнения.
35 |
36 | 2. Обеспечить решение уравнения.
37 |
38 | 3. Предоставить ответ в формате JSON.
39 |
40 | _Дополнительные пожелания_
41 |
42 | 1. Использование наследования при решении различных типов уравнения (единый интерфейс для решения любого типа уравнения).
43 |
44 | 2. Обеспечение валидации параметров и обработки исключительных ситуаций (недостаточное количество параметров, неверный тип уравнения, неверный тип аргументов и тд).
45 |
46 | 3. Использование TestUnit / RSpec / Cucumber.
47 |
48 | 4. Использование аутентификации при приеме запроса.
--------------------------------------------------------------------------------
/test_assignments/task_manager_with_authentication.md:
--------------------------------------------------------------------------------
1 | ## RoR: таск-менеджер с функцией аутентификации
2 |
3 | **Функции приложения**
4 |
5 | Полный процесс авторизации пользователя:
6 |
7 | - Регистрация нового пользователя, Sign in, Sign out, Forgot Password, Unlock, Update Account.
8 |
9 | - После регистрации пользователь попадает на список задач, которые либо он создал сам, либо ему назначили.
10 |
11 | - Создать полный CRUD процесс задач: создание, удаление, просмотр, изменение.
12 |
13 | **Требования к реализации**
14 |
15 | У пользователя есть следующие атрибуты:
16 |
17 | - имя, фамилия — обязательные поля;
18 |
19 | - email — обязательное поле, уникальное;
20 |
21 | - пароль;
22 |
23 | У задачи следующие атрибуты:
24 |
25 | - название задачи — обязательно;
26 |
27 | - описание задачи — текст, не обязательно;
28 |
29 | - кто создал — пользователь, обязательно;
30 |
31 | - на кого назначена — пользователь, обязательно;
32 |
33 | - статус задачи — new, started, finished.
34 |
35 | Требования к вьюшкам:
36 |
37 | - HAML или Slim;
38 |
39 | - Twitter Bootstrap;
40 |
41 | - JQuery.
42 |
43 | Требование к коду:
44 |
45 | - Rspec - тестовое покрытие кода 100 %, проверка через гем Simplecov (вьюшки тестировать не надо);
46 |
47 | - зелёный Rubocop.
48 |
49 | **Оценка задания**
50 |
51 | При оценке тестового задания будут учитываться следующие пункты:
52 |
53 | - следование Style Guides;
54 |
55 | - соответствие требованиям к тестированию, полнота тестов;
56 |
57 | - DRY;
58 |
59 | - наличие «интересной функции», которая не описана в требованиях, но может быть полезной в проекте.
60 |
61 | Код выложить на GitHub или Bitbucket и прислать ссылку.
--------------------------------------------------------------------------------
/test_assignments/telegram_bot_sticker_png.md:
--------------------------------------------------------------------------------
1 | ## TelegramBot: конвертация стикеров в PNG-файлы
2 |
3 | Create Telegram chat bot.
4 |
5 | Use Ruby and related technology stack to create simple Telegram bot to convert Telegram stickers to PNG files.
6 |
7 | **Requirements:**
8 |
9 | - Create Telegram bot with configurable ID.
10 |
11 | - Implement long polling method to get updates from the API.
12 |
13 | - Implement bot command /start. Bot should answer the description.
14 |
15 | - When user send some text message, bot should response the warning message with small description.
16 |
17 | - When user send some built-in Telegram sticker, bot should response same sticker as a PNG file.
18 |
19 | - User should be able to save PNG to the device (phone, computer, etc).
20 |
21 | - Use static code analyzer.
22 |
23 | - Create Github repository with all code work and valid README file.
24 |
25 | **Additional score requirements:**
26 |
27 | - Cover all necessary code with unit tests.
28 |
29 | **Implementation details:**
30 |
31 | - Use last stable Ruby version.
32 |
33 | - You can use any other gems you want, but make the choice reasonably.
34 |
35 | - Write code as clean and as readable as possible.
36 |
37 | - Consider using RSpec for testing.
38 |
39 | - Consider using RuboCop as a static analyzer.
40 |
41 | - Consider using GitFlow workflow.
42 |
--------------------------------------------------------------------------------
/test_assignments/totalizator.md:
--------------------------------------------------------------------------------
1 | ## Ruby: тотализатор
2 |
3 | **Условия**
4 |
5 | На вход подаются 2 счёта на игру (реальный и предполагаемый игроком), на выходе получаем количество заработанных или потерянных очков.
6 |
7 | Функция на вход принимает 4 целочисленных значения от 0 до 9, на выходе возвращает целочисленное значение от -1 до 1
. Первые 2 значения — реальный счёт игры
, следующие 2 значения — предполагаемый счёт игры
.
8 |
9 | Если реальный счет игры 2:1, а предполагаемый — 0:1, то параметры функции — 2, 1, 0, 1.
Если реальный счёт игры 0:3, а предполагаемый счёт 2:1, то параметры функции — 0, 3, 2, 1.
10 |
11 | Функция должна возвращать:
12 |
13 | - 1, если счёт угадан полностью;
14 |
15 | - 0, если угадано, какая команда выиграла;
16 |
17 | - -1, если не угадан ни реальный счет, ни кто выиграл.
18 |
19 | Пример использования:
20 |
21 | - score(0, 1, 0, 1) вернет 1 (счет угадан полностью)
;
22 |
23 | - score(2, 1, 1, 0) вернет 0 (угадано какая команда выиграла)
;
24 |
25 | - score(0, 4, 2, 0) вернет -1 (ничего не угадано).
--------------------------------------------------------------------------------
/test_assignments/url_shortener_app.md:
--------------------------------------------------------------------------------
1 | ## RoR: Приложение для сокращения ссылок - url shortener
2 |
3 | - Необходимо реализовать сервис сокращения ссылок. Данный сервис должен реализовывать 3 запроса:
4 | - `POST` **/urls** который возвращает короткий url
5 | - `GET` **/urls/:short_url** который возвращает длинный URL и увеличивает счетчик запросов на 1
6 | - `GET` **/urls/:short_url/stats** который возвращает количество переходов по URL
7 |
8 | - Проект необходимо реализовать на Ruby On Rails.
9 |
10 | - База Данных - на выбор.
11 |
12 | - Необходимо вести статистику уникальных IP запросов.
13 |
--------------------------------------------------------------------------------
/test_assignments/video_view_statistics_service.md:
--------------------------------------------------------------------------------
1 | ## Ruby: сервис статистики видеопросмотров
2 |
3 | Напишите на Ruby сервис, реализующий REST API со следующими функциями:
4 |
5 | - Принимает от клиентов уведомления о том, что клиент смотрит видео.
6 |
7 | Параметры: `customer_id` — идентификатор пользователя, `video_id` — идентификатор видео, которое смотрит пользователь.
8 |
9 | - Отвечает на запрос, сколько видео потоков смотрит пользователь в данный момент.
10 |
11 | Параметры: `customer_id` - идентификатор пользователя.
12 |
13 | - Отвечает на вопрос, сколько пользователей смотрят данное видео.
14 |
15 | Параметры: `video_id` — идентификатор видео.
16 |
17 | **Дополнительные сведения:**
18 |
19 | - Клиенты посылают уведомления о просмотре видео каждые 5 секунд, пока работает плеер. Если в течение 6 и более секунд уведомление от пользователя не пришло, то считается, что просмотр этого видео завершен.
20 |
21 | - Клиентов много и их не интересует ответ на уведомление о просмотре.
22 |
23 | - Запросы 2 и 3 приходят существенно реже, нежели запрос 1.
24 |
25 | - Ответ на запрос 2 должен быть максимально актуальным.
26 |
27 | - Ответ на запрос 3 может отставать и отражать ситуацию не на текущий момент, а, например, на минуту назад.
28 |
29 | Использовать можно любой фреймворк, можно не использовать. Для хранилища можно использовать: память внутри самого ruby-приложения, postgresql, redis.
30 |
31 | По желанию: реализовать адаптеры для разных хранилищ.
--------------------------------------------------------------------------------
/test_assignments/weather_statistics_api.md:
--------------------------------------------------------------------------------
1 | ## ROR6 + Grape: API для статистики по погоде
2 |
3 | **Требования**
4 |
5 | Как источник данных можно использовать https://developer.accuweather.com/apis.
6 |
7 | Город можно использовать любой (можно захардкодить).
8 |
9 | Законченный код передать в виде приватного репозитория на GitHub
10 |
11 | API открыт для всех, авторизация не нужна.
12 |
13 | Должны быть интеграционные тесты на эндпоинты и юнит тесты на общие классы/модули.
14 |
15 | Ожидаемая нагрузка на любой эндпоинт: 5 RPS
16 |
17 |
18 | **Необходимые эндпоинты**
19 |
20 | /weather/current - Текущая температура
21 |
22 | /weather/historical - Почасовая температура за последние 24 часа (https://developer.accuweather.com/accuweather-current-conditions-api/apis/get/currentconditions/v1/{locationKey}/historical/24)
23 |
24 | /weather/historical/max - Максимальная темперетура за 24 часа
25 |
26 | /weather/historical/min - Минимальная темперетура за 24 часа
27 |
28 | /weather/historical/avg - Средняя темперетура за 24 часа
29 |
30 | /weather/by_time - Найти температуру ближайшую к переданному timestamp (например 1621823790 должен отдать температуру за 2021-05-24 08:00. Из имеющихся данных, если такого времени нет вернуть 404)
31 |
32 | /health - Статус бекенда (Можно всегда отвечать OK)
33 |
34 |
35 | **Дополнительно**
36 |
37 | Рекомендуется хранить данные о температуре локально для снижения нагрузки на сторонний API.
38 |
39 | Рекомендуется использовать библиотеки: Rails 6, Grape, Delayed::Job, Rufus, RSpec, VCR.
40 |
41 | Приветствуется использование кеширования и Trailblazer, swagger документации, Docker
--------------------------------------------------------------------------------
/test_assignments/web_panel_for_users_control.md:
--------------------------------------------------------------------------------
1 | ## RoR + Front end: RESTful JSON API для управления пользователями сайта
2 |
3 | **Задание**
4 |
5 | Разработайте веб-интерфейс для управления пользователями сайта. Используйте _Ruby 2.6_ и _Ruby on Rails 5_.
6 |
7 | **Требования**
8 |
9 | *Пользователи*
10 |
11 | Создайте сущность для пользователей с атрибутами (все обязательные):
12 |
13 | - имя;
14 | - уникальный email;
15 | - пароль;
16 | - аватар.
17 |
18 | *Интерфейс*
19 |
20 | В панели управления можно просматривать, создавать, изменять, удалять пользователей. Уделите большое внимание внешнему виду и дизайну. Для создания интерфейса используйте Bootstrap или любой другой CSS-фреймворк. Сайт должен отображаться на мобильных и десктопных устройствах.
21 |
22 | *API*
23 |
24 | Разработайте RESTful JSON API для мобильных приложений, где можно будет:
25 |
26 | - регистрироваться по почте и паролю;
27 | - получать и изменять свои данные;
28 | - просматривать информацию о других пользователях.
29 |
30 | **Дополнительные детали**
31 |
32 | Результат загрузите на GitHub, приложение разверните на сервере. Ссылку на репозиторий отправьте на почту. По вопросам обращайтесь в Telegram.
33 |
34 | Оцениваем качество кода, читаемость, соответствие гайдлайнам синтаксиса и дизайна, внимание к деталям. Использование библиотек приветствуется, ограничений нет.
--------------------------------------------------------------------------------