Skip to content

Latest commit

 

History

History
251 lines (160 loc) · 18.8 KB

README.md

File metadata and controls

251 lines (160 loc) · 18.8 KB

Rubizza Survival Camp: Summer 2019

Алгоритм примерно следующий:

  • Для сдачи всех заданий каждому нужно будет форкнуть этот репозиторий.
  • Каждый курсант ( он же участник курсов ) должен в этом репозитории создать папку со своим личным номером ( например 3522 ).
  • Каждое задание должно выполняться в отдельной ветке и для него необходимо создать отдельную папку, которая будет отражать номер задания. ( например для задания 0 - 3522/0/ )
  • После завершения задания - нужно выслать pull request ( он же далее PR ) в master-ветку этого репозитория. Формат названия PR должен быть персональный номер - номер задания ( например 3522 - 0 ). Обратите внимание что при отправки нужно заполнить все поля в шаблоне.
  • PR после отправки всегда будет проверять шальная собака на соответствие человеческим стилям. Если стиль кода ей не понравится - она будет ругаться.
  • Только если собака довольна - на вашу задачу будет назначен ментор, который уже будет просматривать код и принимать задание.
  • После того как ментор решил что задание выполнено полностью и ему все нравится - он зальет ваше задание в основной репозиторий. Именно этот момент и будет считаться временем сдачи задания.

Задание 0

Чтобы показать все прелести языка Ruby вам придется пройти через сложный путь к просветлению. На выходе вы получите незабываемые впечатление и навыки написания кода согласно тому, как все привыкли его видеть! Запомните, что каждое следующее задание должно строго следовать букве закона и быть на стиле!

  1. Форкаем репозиторий
  2. Фиксим все коэны. (см. инструкцию к репу ruby_koans)
  3. ...
  4. Profit!

Как доказать, что я справился

  • Все решения ( вместе с кодом решения ) должны быть залиты в папку, которая отражает номер текущего задания.
  • Видео, прикрепленное к PR, обязательно должно показывать, что все koans пройдены.

Дедлайн

2019-07-09 18:00:00 UTC+3

Задание 1

Существует масса Ruby gems, которые помогают нам в повседневной жизни создавать продукты. Но просто существовать мало, интересно насколько они популярны и как их сравнить между собой, так сказать, подбить статистику.

Помним про оформление - жалеем ревьюверов!

Общее описание

В рамках задания пишем консольную утилиту, определяющую популярность Ruby gems. Запуск выполняется следующей командой:

ruby top_gems.rb

Cписок гемов для проверки находится в файле в формате YAML следующего вида:

gems:
  - sinatra
  - rspec
  # ...

Для каждого гема в этом списке мы находим его Github repo, со страницы этого repo достаем следующие данные: Used by, Watch, Star, Fork, Contributors, Issues.

Популярость гема определяется по совокупности всех этих параметров, алгоритм определения данного фактора оставляем за каждым курсантом.

Вывод программы должен быть следующего вида:

rails    | used by xxx | watched by xx |  x stars | xx forks | xx contributors | x issues |
sinatra  | used by xxx | watched by xx |  x stars | xx forks | xx contributors | x issues |

Обязательное задание со звездочкой:

Мы можем передать дополнительные аргументы:

  • Параметр --top, показывает количество гемов согласно рейтинга:
ruby top_gems.rb --top=2
  • Параметр --name, выводит все Gems согласно рейтинга в имя которых входит заданное слово:
ruby top_gems.rb --name=active
  • Параметр --file, который является путем к yml файлу, содержащему список имен гемов:
ruby top_gems.rb --file=gems.yml

Как доказать, что я справился

  • Все решения (вместе с кодом решения) должны быть залиты в папку, которая отражает номер текущего задания.
  • Видео, прикрепленное к PR, обязательно должно показывать, что ваша программа работает.

Дедлайн

2019-07-15 18:00:00 UTC+3

Задание 2

Многие из вас скоро получат свои первые проекты, где по самые локти окунутся в производство своего первого программного продукта. И как на любом уважающем себя заводе по выпуску продукции нам необходим такой инструмент как система учета рабочего времени. В рамках данного задания и в добрых традициях индустриального производства мы хотим разработать современный аналог карточной системы учета рабочего времени. Лучшее решение получит жизнь и будет использоваться в августе всеми участниками рубиццы.

Общее описание

В этом домашнем задании мы будем писать телеграм бота, в котором каждый участник после регистрации сможет “принимать смену” и “сдавать смену”.

Регистрация начинается после команды “/start” и предлагает ввести номер по лагерю. Если такой номер уже существует или номер не совпадает ни с одним из списка всех номеров по лагерю ( которые находятся в файлике в папке data вашего проекта ), то пользователю показывается ошибка. В противном случае регистрация проходит успешно и номер пользователя вместе с его telegram_id сохраняется в базу данных.

Зарегистрированному пользователю доступны 2 действия: “принять смену”, и “сдать смену”, которые вызываются командами “/checkin” и “/checkout” соответственно.

При инициализации каждого действия пользователю необходимо сделать следующие действия:

Отправить селфи, в качестве доказательства того, что ты на месте. Отправить текущую геопозицию.

В общем виде диалог будет выглядеть приблизительно следующим образом:

bobka_user: /checkin
bot: Пришли мне себяшку:
bobka_user: [ selfie.jpg ]
bot: Точно пришел на место?
bobka_user: [ geolocation ]
bot:  Отлично, порви сегодня всех. За себя и за Сашку.

В простой версии мы не требуем валидацию данных, и если что-то пошло не так, то попытка сдать/принять смену считается проваленной и бот сообщает что произошла ошибка. В более продвинутой версии вы можете реализовать проверку данных на валидность и переспрашивать у пользователя, пока он не предоставит правильные данные.

Как именно организовать все данные с технической точки зрения смотрите в разделе ниже.

Техническое описание

Библиотеки и общие рекомендации

Для реализации нужно использовать гем telegram-bot. Пример создания бота в одном файле: https://github.com/telegram-bot-rb/telegram-bot/wiki/Not-rails-application.

Для разработки удобно использовать poller-mode, чтобы не заморачиваться с вебхуками.

Изменения в коде не подгружаются автоматически. Чтобы запустить измененный код — нужно перезапустить процесс с ботом.

Рекомендуемая архитектура

Обработчики команд нужно хранить в отдельных модулях и отдельных файлах, чтобы не получился один большой файл:

require “commands/start”

class WebhooksController < Telegram::Bot::UpdatesController
  extend StartCommand
end

commands/start.rb:

module StartCommand
  def start!
    respond_with :message, text: 'Hello!'
  end
end

Для того, чтобы не приходилось регистрироваться каждый раз заново, бот должен запоминать пользователей после регистрации. Для этого можно использовать сессии, которые хранятся в редисе: https://github.com/telegram-bot-rb/telegram-bot#session. Понадобится установить и запустить на компьютере редис.

При программировании диалогов с пользователями, когда нужно задать подряд несколько вопросов (например, сначала спросить о фото, а потом о локации), удобно использовать контексты: https://github.com/telegram-bot-rb/telegram-bot#message-context. Методы для контекстов должны лежать в том же модуле, что и метод команды.

Селфи пользователей и гео-координаты нужно сохранять на диске с такой структурой папок:

public
  <session_id>
    checkins
      <timestamp>
        selfie.jpg
        geo.txt
    checkouts
      …

Требования

В рамках данного задания вам надо придерживаться правила один модуль/класс - один файл. Необходимо разбивать весь ваш код на модули/классы, которые бы занимались одной и понятной функцией. Заданиe не будет принято, если код написан в одном или нескольких файлах.

Как доказать, что я справился

  • Все решения (вместе с кодом решения) должны быть залиты в папку, которая отражает номер текущего задания.
  • Видео, прикрепленное к PR, обязательно должно показывать, что ваша программа работает.

Дедлайн

2019-07-22 18:00:00 UTC+3

Задание 3

Кто работает — тот ест. В современном городе нас окружают множество заведений, куда можно пойти на обед. Наверняка, с вами случались ситуации, когда вы заказали бургер, а вам его готовили 30 минут, и в нем еще оказался теплый салат.

Чтобы избежать подобных разочарований, в этом домашнем задании мы будем делать веб-приложение с отзывами о заведениях и местах.

Общее описание

На главной странице пользователи должны видеть список заведений с названием, описанием и координатами.

Пользователь может нажать на название заведения и перейти на отдельную страницу этого заведения, на котором будут видны более подробное описание, координаты и средняя оценка от пользователей.

Кроме описания, на странице заведения должен быть список отзывов, оставленных пользователями об этом заведении.

Каждый отзыв содержит в себе текстовый комментарий и оценку пользователя по шкале от 1 до 5.

Оставлять отзывы могут только зарегистрированные и залогиненные пользователи.

Пользователь может зарегистрироваться на отдельной странице, введя свои имя, имейл и пароль.

Пользователь может войти в систему, когда введет свой имейл и пароль на странице логина.

Пользователь может разлогиниться (когда, например, он залогинился не на своем компьютере, а на компьютере друга).

На странице заведения должна быть форма, в которой пользователь выбирает оценку от 1 до 5 и пишет текстовый комментарий. После отправки формы, пользователь перенаправляться на страницу заведения и видит свой отзыв.

Если пользователь ставит плохой балл заведению, то он должен обязательно ввести комментарий и аргументировать свою оценку или рассказать о своей ситуации.

Техническое описание

Для этого задания используем синатру. В качестве базы данных — sqlite. Самой базы в репозитории быть не должно.

Чтобы удобно работать с базой данных, нужно использовать паттерн ActiveRecord и гем, который его реализовывает и позволяет использовать в синатра-приложении.

Первоначальные данные в базу должны добавляться из скрипта (можно подсмотреть пример из Rails).

Подсказка: для реализации очень простой регистрации и логина можно использовать sinatra sessions и хранить в сессии айди пользователя, когда он залогинился.

Подсказка: нельзя хранить пароль в базе данных в чистом виде, т.к. если вашу бд взломают, то пароль попадет в руки злоумышленникам. А если пользователь использовал один и тот же пароль в вашей системе и в своей почте…

Подсказка: если пользователь введет некорректный имейл, то письма, которые мы захотим отправить, ему не дойдут.

Приложение должно иметь читаемую и организованную структуру файлов.

Организованность будет оцениваться.

Использовать архитектуру REST (ссылка на ознакомление)

Как доказать, что я справился

  • Все решения ( вместе с кодом решения ) должны быть залиты в папку, которая отражает номер текущего задания.
  • Видео, прикрепленное к PR, обязательно должно показывать, что ваша программа работает.

Дедлайн

2019-07-29 18:00:00 UTC+3