本周在维京代码学校，我们的任务是使用《星际大战》 API从头开始构建CRUD Rails应用程序。 我们获得了这项任务的自由范围。 现在，如果我在这里很诚实，那么仅使用脑海中的想法来构建Web应用程序就是一场噩梦。 我喜欢将别人的想法交给别人并尝试付诸实践。 我喜欢创造性地提供帮助。 我知道这将使我紧张。
当我们被告知该项目的那天晚上，我发现自己全神贯注，如何使用《星球大战》 API，该API向用户提供有关JSON中电影的信息，以构建创意。 在最长的时间内，我所能想到的就是建立《星球大战》宇宙的纲要。 第二天早上，我想到了用它来制作自己的《星球大战》电影的想法。 将为用户提供标题，角色和船只的选择，并使用它们来制作自己梦dream以求的《星球大战》电影。
建设开始
早上早上，Scrum开始了我的项目。 首先，设置我的应用程序的骨骼。 我已经创建了足够多的Rails框架，以了解有关如何使我的应用程序结构化的一般想法。 但是，我只使用了真正的基础数据库，因此当我开始考虑如何构建数据库中API返回的对象时，事情变得有些繁琐。
因为API返回了有限数量的对象，所以我认为最好的主意是将所需的信息存储在数据库中，从而需要尽可能少的调用并加速应用程序。 这意味着我数据库中的每个角色，飞船或电影都可以属于多个用户创建的电影，并且每个用户创建的电影都可以具有多个这些对象。 从理智上讲，我知道解决方案，联接表，但实际上，我仅使用了一对一和一对多关系。
多对多
幸运的是，Rails使创建联接表相对简单。 创建具有两个“引用”类型的属性的模型需要进行大量工作。 由于担心产生错误的迁移顺序，因此我发现自己现在行动缓慢……尽管尽了最大的努力，我还是最终还是做了。 建立我的模型和数据库需要花费大部分时间。 但是，即使我的应用程序没有像我梦strongly以求的那样充实，但这种数据库实践对我来说确实很不错。
量产
我们的最终任务是在Heroku上部署我们的应用程序。 这是我之前做过的几次，但是从来没有使用过半复杂的数据库。 将我的数据库从开发中使用的SQLite3迁移到生产所需的Postgresql（PG）时遇到的问题。 事实证明，PG对它的结构有些挑剔，部署后我的一些迁移失败了。 最终，在我进行演示之前，大多数问题都已解决。
在演示我的应用程序时，我意识到与SQLite3一起使用的destroy动作与后端上的PG无关。 浏览日志后，我意识到与SQLite3相比，PG与引用处理方式有关。 不幸的是，我不确定该解决方案，幸运的是，该应用程序的其余部分仍然可以运行。
部署思路
依靠外部API在一天之内构建完整的CRUD应用程序，使我对期望有了很多了解。 一个小的语法错误可能需要30到45分钟才能弄清楚，这确实减慢了您的处理速度。 我认为现在我对建立基本的Rails应用程序有更深入的了解，并且在考虑自己的应用程序想法时，我被要求扩大我的创造力。
如果您想制作自己的《星球大战》电影，尽管具有原始的用户界面，请在此处查看。 如果您想查看此应用程序源代码，请在GitHub上查看。
