As a part of the review of learning Rails in Flatiron’s Learn program, we were charged with building an app with certain technical features.  In a production environment, you would never search for a model to include a new technical feature, but for training purposes, that sounds great.

I chose to give the Springfield Community Center an online tool to help Lisa, Bart, and Marge with their goal of serving their community better.  (This is also slightly inspired by my time aboard the Logos Hope, but that’s a story for another day.)

Starting from a bare-bones Rails project is as easy as typing ‘rails new MyProject’ into a terminal, but fleshing it out takes time and care.  There’s models to decide on, interactions to plan, and an overall idea of how the app will operate that must at least be thought about before the first keystroke will ever make any sense.

Users, is easy.  You’ve gotta have users.
Events are what will take place.  Meetings, parties, rehearsals, bridge tournaments, pasta bridge tournaments, whatever.
Assets are what will be utilized and reserved for an event.  Everything from Tables and Chairs to Projectors and Speakers would be assets.  Add Rooms to that, and it’s a good basic level to start with.  These will not have CRUD functionality for basic users.
EventAsset will be the model for the join.  An EventAsset is the registration of a specific asset for a specific event.

The OmniAuth bits are so incredibly annoying for small projects like this.  In production, when you are planning on thousands of people using your product, it is obviously worthwhile to code it properly.  If you request a profile of a user from a provider, they’ll give it to you if the user lets them; however, the problem comes if a user has different emails for any provider and tries to log in by those two ways.  Have a different github email from your facebook?  Well you’ll end up with two different profiles in the app.  Did you use your work email for your linkedin profile?  Well if you log in with google, you’ll have some of your app data/history on one profile, and some of it on another.  This is totally aside from the fact that Twitter doesn’t necessarily return an email at all.  There are ways around this, and these are good ways.  But these are the ways of professionals who are paid for their time, not students who are paying for the time and on a budget.

The basic flow of the app is to display events, if you want to register an event, you have to sign up and sign in.  An event is created and EventAssets are associated with it as needed.

I think the biggest hurdles I had with this one was getting the EventAsset management to work.  I know it’s not the best or even close to perfect, but it works.

I noticed as I was working that I had a lot of good ideas for good features.  But most of them fell under You Ain’t Gonna Need It reasoning, so I made a note and kept my focus on only features that would count towards to completion of the project.  That includes styling and making it look ‘pretty’.  There MUST be a balance between how much time a project consumes vs how much payoff there is.  The payoff, in this case, is the project’s submission and successful review.  I’m not making portfolio material here.  Perfect isn’t the goal, completed is.