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

Основными требованиями этого проекта были следующие:

  • Создайте приложение MVC Sinatra и используйте ActiveRecord
  • Используйте несколько моделей, из которых модель пользователя должна иметь отношение has_many, а другая модель — belongs_to модель пользователя.
  • Пользователи должны иметь возможность регистрироваться/входить в систему и подтверждать уникальность своего имени пользователя.
  • Пользователи могут создавать, читать, удалять, удалять только свои записи.

В начале я совершенно потерялся в том, с чего начать. Моя первоначальная идея проекта заключалась в том, чтобы сделать приложение для отслеживания производительности (я даже назвал его «Tracktivity»). Но после того, как я начертил его блок-схему, я понял, что это было бы невозможно с тем количеством знаний и времени, которые у меня были. Поэтому я обратился к своей второстепенной и личной для меня беде: ведению дневника.

Я всегда стараюсь как можно больше напоминать себе вести дневник и записывать свои мысли в конце дня, чтобы успокоиться и заняться самоанализом, но давайте будем реальными. У кого действительно есть время и мотивация, когда вы устали, чтобы достать ручку и блокнот, когда все, что вы хотите сделать, это включить Netflix и посмотреть Tiger King? Используя свою лень в качестве катализатора, я решил, что должен, по крайней мере, сделать так, чтобы мне было легко вести дневник.

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

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

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

Как вы можете видеть, когда я закончил работу над серверной частью моего кода, я сосредоточил много (ладно, может быть, слишком много) оставшегося времени на внешнем интерфейсе и визуальных эффектах.

Стойка-Flash

Одна, казалось бы, простая задача, с которой я по какой-то причине продолжал бороться на протяжении всего проекта, заключалась в том, как заставить Rack::Flash работать. Были моменты, когда всплывающее сообщение появлялось, как я и ожидал, а иногда — нет. Но что такое программирование без отладки? 🤷🏻‍♀️

Я хотел, чтобы мои флеш-сообщения выглядели как сообщения об ошибках. Итак, с помощью CSS я сделал это следующим образом:

Видите этот крошечный выделенный желтым текст вверху?

«У вас нет доступа к записям этого пользователя».

Да, это флеш-сообщение! Это сообщение появится только в том случае, если пользователь попытается получить доступ к записям другого пользователя. Код, стоящий за сообщением, по существу блокирует их возможность взломать учетную запись этого пользователя.

Хотя мне удалось выяснить причины, по которым флэш-память не работала должным образом, сам процесс отладки был головной болью. Причина, по которой у меня постоянно возникали проблемы с моими флеш-сообщениями, заключалась в том, что между операторами if/else они были зажаты. Поскольку маршруты RESTFUL и перенаправления были переплетены друг с другом, если пользователь НЕ был logged_in, мое приложение сигнализировало бы flash[:signed_out] (в строке 57) и перенаправляло пользователя на страницу входа. Однако, если на странице входа есть отдельное всплывающее сообщение (например, «Пожалуйста, войдите в систему» ​​для пользователей, не являющихся logged_in?, то появится сообщение «Пожалуйста, войдите в систему», а не «Вы' Вы вышли из системы. Пожалуйста, войдите снова».

Мои общие мысли

Меня мысленно и эмоционально толкнули влево и вправо из этого проекта, и я с нетерпением жду нашей недели перерыва, прежде чем мы начнем наш следующий этап. Как я уже говорил ранее, этот проект действительно стал для меня обучающим опытом, как с точки зрения программирования, так и с точки зрения борьбы со своим внутренним хаосом. Забегая вперед, я понял, что необходима последовательная организация на протяжении всего проекта. Раньше я считал, что, если я тщательно спланировал свой проект в начале, последует дальнейшая организация. О, как же я ошибался. В спешке, чтобы исправить их соответствующие ошибки, я обнаружил, что перескакиваю с одного контроллера на представление индекса, а затем на представление шоу, а затем на другой контроллер. Поскольку это был только мой второй проект, мне еще предстоит понять, нормально ли это или мой процесс программирования просто не организован. Думаю только время покажет. 🤡