Сочинение что в ком? Если бы вы прочитали мне этот заголовок месяц назад, это был бы мой ответ. Теперь я несколько… э-э, скажем так, уверен, что могу объяснить, что это значит, и, создавая свой первый, я сделал важные выводы, которые нужно держать в заднем кармане.
Если вы никогда раньше не слышали о CRUD, найдите минутку, чтобы прочитать мою предыдущую статью, в которой более подробно рассматривается CRUD.
В рамках нашей второй оценки в школе Flatiron нас попросили создать приложение CRUD в Sinatra. Было 7 основных требований: внедрить шаблон программного обеспечения MVC, использовать ActiveRecord, включить несколько моделей, использовать по крайней мере одно отношение has_many, включить учетные записи пользователей, которые могут изменять только контент, который они создают, проверять пользовательский ввод, чтобы гарантировать неверный данные не создаются, и любые ошибки проверки должны отображаться пользователю с сообщением об ошибке.
Прочитав все это, вы, вероятно, немного похожи на этого парня. Ничего страшного, я выглядел так же. На самом деле, я выгляжу именно так каждый раз, когда начинаю новое упражнение во Flatiron. Обычно это выражение длится 10–15 минут, после чего я вздыхаю, после чего начинаю писать код.
Шаблоны MVC и CRUD особенно полезны в отношении этого начального… взгляда «мозг говорит «нет». Частично это связано с тем, что CRUD забавно говорить, но в основном это потому, что оба предоставляют воображаемую структуру для приложения еще до того, как будет написана хотя бы одна строка кода. MVC описывает, как будут структурированы папки и файлы, поэтому, если вы полностью застряли в начале, начните создавать свою структуру MVC. Создайте свои предполагаемые модели в их собственных файлах .rb, затем в файлах .erb для каждого представления, которое может существовать, а затем в контроллерах для доставки информации между ними. Как только это будет завершено, продолжайте создавать действия CRUD в каждом контроллере. Некоторым контроллерам могут не требоваться все четыре действия, включенные в CRUD, так что это может потребовать некоторого размышления, но общее преимущество все же есть — вы пишете базу для своей программы. Вы начали!
После создания структуры MVC и действий CRUD у меня появилась мотивация. Я позволил этому импульсу нарастать, и он привел меня к концу… хм, еще одна дилемма. Чтобы понять это, быстро прочитайте краткое изложение моего веб-приложения с GitHub.
Much Free, Very Wow — это приложение CRUD Sinatra, в котором пользователи могут зарегистрироваться, войти в систему и участвовать в бесплатных мероприятиях в Нью-Йорке.
И пользователи, и действия сохраняются в базе данных SQLite3 при создании.
Подробности активности можно просмотреть по их URL-адресу RESTful. Например, если создано мероприятие под названием «Бесплатное комедийное шоу», подробности можно просмотреть в /activities/free-comedy-show.
Действия также могут быть отредактированы или удалены, но только пользователем, создавшим действие.
На мою дилемму. При создании действий я хотел включить категорию, чтобы пользователи знали, просматривают ли они действие, связанное с музыкой, едой, искусством и т. д. В течение пары часов я взвешивал, должна ли эта категория быть частью таблицы и модели действий или если это должна быть собственная таблица и модель. Я спрашивал инструкторов, я спрашивал других студентов, и я спорил сам с собой в разочаровывающей манере. В конце концов, имело смысл использовать категории как часть существующей таблицы и модели «Действия» по нескольким причинам. Во-первых, если бы категория была сама по себе, мне пришлось бы запрашивать целую дополнительную таблицу каждый раз, когда я хотел отобразить те категории, которые, как я предсказывал, будут частыми действиями. Если бы категория отсутствовала сама по себе для каждого из этих запросов, теоретически я бы увеличил время загрузки на 33%. Преимущество наличия отдельных категорий было бы в том, что я мог бы иметь атрибуты и методы, специфичные для категорий, но мне это не нужно! Выбор был практически сделан за меня.
Одним из вариантов, который имел бесчисленное количество вариантов, был выбор драгоценного камня для отображения сообщений пользователю, когда он сталкивался со сбоями. Эти сбои происходят, когда пользователь не вошел в систему и пытается изменить действие, он вошел в систему и пытается изменить действие, которое ему не принадлежит, когда поля остаются пустыми во время регистрации или входа в систему, и когда пользователь успешно выходит из системы. Двумя выдающимися вариантами такого поведения были Rack-Flash и Sinatra-Flash. Из того, что я читал, sinatra-flash — это расширение рэка-flash, включающее возможность использовать ‹%= styled_flash %›, который будет чередовать флеш-сообщения в зависимости от того, что активно в данный момент. Он также позволяет стилизовать флеш-сообщения с помощью всего одного правила CSS — невероятно просто.
После того, как я прочитал приведенное выше руководство и реализовал флэш-сообщения для всех сбоев, мне нужно было применить всего несколько опечаток и настроек, и мое самое первое приложение CRUD было создано! С каждым проектом становится все яснее, что начинать — это самая сложная часть, и каждый раз, когда в проекте возникает препятствие, продолжайте настаивать, и в конце концов оно рухнет. Иногда… часто… чаще всего может показаться, что я застреваю на каждой контрольной точке и не могу двигаться дальше, но тогда я это делаю. Думаю, это главный урок, который я усвоил на данный момент.
