Overall, having functional code for yourself is only mildly exciting.  Having code you can share with others is good.  The best, however, is when your code becomes invisible and is no longer the product, but the avenue for the product or service.

Most people have heard of All-Recipes.com, but this will be the cheap knock-off: Mall-Recipes.com.  Most things with malls are cheap, quick, and dirty and this will be no exception.

My Fwitter project, along with all my other submissions to Flatiron’s Learn program, have been pretty rough, stylistically.  I’d like this to be a *little* bit prettier, but it’s gotta be quick.  (I wanted to keep it under 24 hours, but PostgreSQL had other ideas)  This will be greatly sped up by simply re-factoring code I already have functioning give it a new-found purpose.

I also wanted to have it live on Heroku and found ample set-up help.  Then as new features were installed, push out to it like a normal release cycle.  After the initial difficulty in deploying due to the fact that they run on PostgreSQL, not SQLite, it’s at long last up and running.

A quick note here about database usage.  There are many blog posts and tutorials out there that seem to have no problem with having development and test use one database, SQLite for example, and then have the production space run on an entirely different database software suite, PostgreSQL.  This is absolutely in no way acceptable in a truly production environment.  In ANY situation, you always want your production/development/test points to be as close to each other as absolutely possible.  All the database, framework, infrastructure, architecture, and platform documentation I read about it said that they should be as similar as possible.

Simply put, I built a recipe app.  But when you get into the nitty gritty of it, it’s actually pretty complicated.  You want to create a new recipe?  You have to be logged in.  That’s easy enough in plain english, but teaching a server how to do that isn’t.  You want to be able to list all the recipes in your database that have a certain ingredient in it?  Well, imagine the hassle it would be to do that for your own recipe box, but oh the revelations when you do it online and shows you hundreds of tofu recipes!

I have several classes: Users, Recipes, Reviews, Ingredients, and RecipeIngredients.  I have database tables to go with each one of those, the most interesting of which I thought was the RecipeIngredients table.  Each row of that table represents a single entry of a single ingredient in a single recipe and has all the information for that entry like ‘how many/much’ of the ingredient, how many ‘whats’ you’re putting in (3 cups, 5 cloves, 2 lbs, etc.), and also a ‘qualifier’ (chopped, warm, cubed, chilled, pressed, etc.).

It actually worked out really well because I could then have a simple dropdown menu so the user can easily choose from the available ingredients.  However, at scale, this would be a little impractical.  In reality, if your business/site takes off, you could potentially end up with 1,000’s of ingredients!  Selecting each new ingredient would be like a whole trip through the grocery store!  So the practicality of this implementation has it’s limits, and they’re pretty low, but still it was fun.

A user has many recipes, a recipe has many ingredients through recipe_ingredients.  An ingredient has many recipes through recipe_ingredients.  A review belongs to a user and a recipe.  A user has many reviews and a recipe belongs to a user.  You got all that?  😉

A recipe must have a name and a description; a user has to have a username, email, and password; a user must have a unique username and unique email.

Well, after several days of development, it’s finished.  Overall I’d say with this project I wish I had bitten off a little bit less.  Sure I accomplished most of what I set out to do.  My app is live on Heroku.  But at what cost?  4 days?  Probably 2 of those were from the Postgres nightmare, but 2 of those at least were from simply choosing a scope that was too large.  This wasn’t meant to push the horizons of internet architecture.   It was just meant to show that I can do what I want in Sinatra.