Sinatra Portfolio Project: Bass & Bait Tracker

For my second portfolio project I had to create a Sinatra application that would track something important to me. One of my favorite activities is bass fishing. When fishing for bass, sometimes certain baits work at different times. A lot of times you end up changing baits during the day until you hopefully find something that works. However, over time I couldn't tell you which baits work the most consistently and would give me the best chance, on average, to catch a fish. My memory just isn't that good. An application to keep track would definitely be helpful to track this information over time.

During the process of brainstorming for these first two portfolio projects, I have tried to focus on what applications actually provide value to my life. Typically if it adds value to my life, then it may add value to someone else's. As a developer the main goal is to add value to a web application for your company, users, customers, and society. Practicing that during school can help get in the mindset of doing that. I also think people learn better when there is value behind what they are doing. If you don't believe in what you are doing then retention can be more difficult.

One thing that was difficult in the beginning was setting limits on what this project was to do. When doing object oriented programming and trying breaking things down into models of real objects, the scope of the project can grow very quickly. For instance, with the fishing application I created, you have a user who owns bait. With each bait you then have catches that belong to that bait, and each catch has a fish associated with it. That is what I built my basic application with. However, you can also have location of the catch, weather, bait manufacturer, boat type, fishing line type and manufacturer, fishing pole type and manufacturer, fishing reel type and manufacturer, etc etc etc. The list just goes on and on with the objects that you can have, relationships you can make, and data mining that you can do. All of this information can add value for the user. For instance, you could keep data on what weather is best to fish for, which bait manufacturer is the best overall, or how many fish have been caught in a particular location. But along with the information comes more and more pages to create to display that information which means more and more time to develop. It really puts in perspective how real world applications start small and then continuously need developers to add content, features, and support. Even some of the biggest websites in the world such as Amazon and Facebook still are constantly being developed because there are so many possible features, content, and data that adds value to people's lives but it takes significant time and brainpower to create it.

In the end, I decided that I would focus on a user being able to view their baits, see how many catches they have with each bait, and then view their catches. The catches show information about the fish and which bait it was caught on. That kept things simple enough to start with and would allow for a solid foundation to build on if this were a real web application that would continue to be developed.

Another thing that was interesting during this project was going through the process building it out in separate layers. I was able to identify four major layers:

1. Object Creation, Manipulation and Basic View Navigation - First everything had to be functioning from a data/object creation and navigation standpoint.
2. Editing and Deleting of Objects
3. Validation of Information - Modify what you did to include validations for the information that a user must enter. (This one was a little bit tricky for my application at one point because when I setup creating a catch, I wanted to be able to select an existing bait or create a new bait when creating the catch. This lead to having to verify check boxes and text inputs for too much or too little information).
4. Security - Ensure that information that belongs to a specific user is protected from others and that a user must be logged in to navigate to the correct areas.

I didn't really go into the application with the four layers fully defined in my head, but as I worked through the project, the four layers became apparent. I think I had some overlap between #3 and #r where I bounced back and forth between working on them. I think being more conscious about this four layer approach will help with development time in the future if I can stick to one layer at a time.