Завершая работу над приложением Sinatra Ruby, я хотел завершить свой проект и вспомнить предыдущие дни, когда я понятия не имел, в каком направлении двигаться при создании своего приложения. Просмотрев несколько веб-сайтов в поисках идей, я захотел сделать свой проект пригодным для использования, и я хотел отказаться от использования всего, что связано с фитнесом, поскольку мой проект CLI был нацелен на это направление. В целях практики я рассмотрел несколько идей приложений, которые могут быть кому-то полезны, например, трекер расходов, календарь, генератор мемов, движок блога, приложение для рейтинга шоу.
В эти трудные дни из-за COVID-19 я решил придерживаться того, что мы будем делать, «запойного просмотра». Может быть, люди хотели бы дать отличную оценку и описание шоу, прежде чем другие решат запоем посмотреть шоу. Звучит просто, правда? Проблемы людей в это время неясны, я буду продолжать думать о новых идеях приложений, которые поднимут мои навыки в другую стратосферу, но до тех пор….
Создать приложение с нуля может быть чрезвычайно сложно, но оно того стоит. Это дает мне возможность начать действительно демонстрировать свои навыки! Я смог создавать сложные вещи благодаря лабораториям Flatiron, но, зная, что мне придется самому следить за этим приложением, это подготовит меня к проверкам кода, если я просто добавлю комментарии по ходу работы!
Первое, что я решил сделать, это записать несколько идей схемы и пробежаться глазами по навигации по моему приложению. Что этот пользователь Роберт сможет делать в этом приложении?
«Я хочу иметь возможность публиковать и оценивать шоу для просмотра другими пользователями».
Давайте разберем его еще больше. Роберт создаст свою учетную запись, зарегистрировавшись, затем он будет перенаправлен на свою панель управления. Затем он сможет создать новое шоу, которое он «запоем смотрел». Затем он будет отображаться на странице шоу «шоу», где он может редактировать свои рейтинги, описание и т. д., если это необходимо. Он также может просматривать другие «шоу» других пользователей, но не может их редактировать/удалять. Схема была в первую очередь ориентирована на шоу.
Давайте подумаем о классах Ruby: Users, Shows и, возможно, Ratings. Ассоциации были бы важны, так как мне нужно было бы включить мою базу данных, чтобы правильно использовать макросы own_to, has_many,.
Это была в первую очередь моя схема, построенная с помощью иллюстратора.
Эта схема очень проста, однако мне не понадобился даже звездный класс. Я в первую очередь хотел разбить рейтинг на звезды, но подумал, что это будет слишком сложно. Я также думал о разделении категорий, так как они будут собраны в необходимом выпадающем списке, и пользователи смогут просматривать шоу по категориям, но это также было бы излишним для этого приложения. Я могу использовать все свое оружие, когда придет время заняться React.
Технический план заключается в том, что у пользователя есть много шоу, шоу принадлежит пользователю и имеет много рейтингов или, может быть, категорий. Над схемой все еще нужно немного поработать, однако я был так взволнован, чтобы начать работу, и я знал, что внесу необходимые изменения, как только начну работу над проектом.
Я подумал, что было бы проще настроить мое приложение, если бы у меня был способ настроить план необходимых файлов для моего приложения. Вот тут-то и появляется Corneal. Corneal — это генератор приложений для Sinatra, который настраивает необходимые папки, файлы и зависимости, чтобы вы могли начать работу с помощью простого «corneal new APP-NAME». Как только мои файлы были на месте, я добавил и удалил необходимые драгоценные камни, представления и папки, чтобы завершить макет. Я также настроил репозиторий GitHub и создал свой первый коммит git….. -m «первый коммит»
Разделение забот. Добавление этого вместе с комментариями и осмысленными коммитами позволило мне сосредоточиться на последовательной системе для планирования моего кода. Это включает в себя разделение и соединение файлов и папок, чтобы попрактиковаться в том, чтобы стать организованным разработчиком. Например, моя папка «приложение» содержит все мои модели, представления, контроллеры и папки помощников. Дальнейшее разделение их на отдельные объекты в зависимости от их действий помогает разработчику с легкостью перемещаться по вашему коду. Максимальное использование DRY-метода сделает код более простым и понятным при использовании слов, соответствующих методам действия. Синтаксис Ruby также упрощает объяснение моего кода.
Чтобы в первую очередь подключить мое приложение к базе данных, я должен установить соединение в папке вашей среды. Эта папка содержит информацию, которая потребуется для запуска вашего приложения.
Вы хотите создать модели ассоциации, соответствующие вашим таблицам Пример модели
Пример таблицы
Наличие ActiveRecord::Base дает вам доступ к таким методам, как has_many, own_to и многим другим, чтобы связать ваши модели друг с другом.
Теперь я могу начать создавать свои таблицы, используя «rake create_migration NAME=»name-of-table». Это создаст файл .rb с классом, унаследованным от моего ActiveRecord::Migration, который дает вам доступ к определенным методам, таким как изменение, вверх, вниз, create_table и т. д. Он выполняет SQL-запросы для нас.
Теперь пришло время украсить мой код! Ну, по крайней мере, сделать его немного чище. Я решил создать собственный логотип в иллюстраторе, а также несколько пользовательских изображений, соответствующих названию проекта. Кроме того, я использовал классную ссылку без засветки, которая использовала пользовательские фотографии во время обновления входа в систему, регистрации и панели инструментов. Я заметил, что потратил много времени на то, чтобы убедиться, что пользовательский опыт не был небрежным или неэффективным.
Я также смог создать собственные сообщения об ошибках, используя гем Sinatra Flash. Это позволило мне контролировать сообщения во время обновления ошибки входа/регистрации пользователя и оповещение об успешном завершении, когда пользователь успешно создал шоу.
Было много других драгоценных камней, таких как bcrypt, которые помогают шифровать пароль пользователя с помощью драгоценного камня Sinatra. Это позволило мне контролировать сеанс пользователя, пока он был в системе.
Tux и Pry в основном использовались для тестирования. Tux позволил мне протестировать мои таблицы перед переносом их в базу данных, а Pry использовался для проверки моих параметров, чтобы убедиться, что я получаю пары ключ/значение, необходимые в моих .erb-формах.
Не повторяйтесь! Да, вы слышали это! Я хотел показать форму ограничения повторяемости в моем коде. Я создал вспомогательные методы, которые будут дополнительно отслеживать сеансы пользователей и проверять, вошел ли пользователь в систему. Я создал файл helper.rb в папке «приложение». Я заметил, что для использования CRUD в пользовательских шоу мне нужно проверить, часто ли пользователь входит в систему. Поэтому я решил создать вспомогательные методы
Я хотел проверить, вошел ли пользователь в систему, проверив, был ли активен сеанс [:user_id]. Но до этого шага я знал, что мне нужно очень внимательно следить за реальным пользователем, поэтому я хотел контролировать этого фактического пользователя во всем приложении. Я создал другой метод
Session[:user_id} принадлежит идентификатору пользователя, поэтому только соответствующий пользователь может использовать CRUD для вещей, которые ему «принадлежат». Например:
Я провожу некоторое время в своем коде, пытаясь проверить эти условия, поэтому я решил создать такие методы, которые предотвратят DRY. Я уверен, что есть другие мелкие исправления, которые я могу найти, чтобы очистить мой код.
Получение обратной связи было важно, так как я хотел убедиться, что пользовательским опытом можно управлять. Поэтому я позволил нескольким своим коллегам перемещаться по приложению, пока мы проверяли возможные сбои или ошибки. Кроме того, я создал файл seed.rb, в котором я создал пользователей и шоу.
Спецификации для завершения моего проекта были чрезвычайно полезны. Это не давало мне слишком сильно сбиться с верного пути.
Характеристики:
x Используйте Sinatra для создания приложения x Используйте ActiveRecord для хранения информации в базе данных x Включите более одного класса модели (например, User, Post, Category) x Включите хотя бы одно отношение has_many в вашу модель User (например, User has_many Posts) x Включите по крайней мере, одно отношение own_to в другой модели (например, опубликовать own_to User) x Включить учетные записи пользователей с уникальным атрибутом входа в систему (имя пользователя или адрес электронной почты) x Убедитесь, что ресурс own_to имеет маршруты для создания, чтения, обновления и уничтожения x Убедитесь, что пользователи не могут изменять содержимое, созданное другими пользователями x Включать проверки ввода пользователя o БОНУС – не требуется – отображать ошибки проверки пользователю с сообщением об ошибке (пример формы URL, например, /posts/new) x Ваш README.md включает краткое описание, инструкции по установке, участников гайд и ссылка на лицензию на ваш код
Подтверждать
x У вас есть большое количество небольших коммитов Git x Ваши сообщения о коммите имеют смысл x Вы внесли изменения в коммит, которые относятся к сообщению коммита x Вы не включаете в коммит изменения, которые не связаны с сообщением коммита
Контрольный список кажется полным, но посмотрим, что из этого получится!
Первоначально опубликовано на https://rshield1.github.io 10 апреля 2020 г.
