I've spent a good amount of time thinking about this project's end state. It's been one of those ideas that has always felt a little out of reach. I filed it away to pull back out when I had the skill. The quick pitch is a personal journal of local places that you've been with a way to share that journal with your friends. Since this is a boot camp project, it's pretty tightly time constricted. Since software development cycles are pretty notoriously longer than expected I planned to roll out features in order of importance. While that's the moral of the story the journey can be just as instructive.
I had the idea to build out the back-end from most to least important feature and then move on to the next. Hopefully this would cut down on the amount of time I would take to plan out new features. To begin, the two main features, location tracking and sharing, wouldn't take too many models, just Users, some way for them to self join, and a many to many relationship between Users and Places. This phase was completed before any front end work started.
After those features were completed I started working on the user facing features along with building the user interface. I planned to all users to make Lists to share with other users. Lists would be a simple join table between Users and Places. Users would be able to create lists of places and decided whether to share those lists with other users. While Lists are implemented on the back end, they aren't implemented on the front-end. I'll get into it in another blog post, but I ended up focusing on the front-end a little more than the back-end which caused a decent amount of back-end code to be unused at the deadline, but available for future implementation.
Filtering was the last planned feature. Unlike Lists, only the models and relations were created for filtering. However, instead of focusing on a different portion of the app at the expense of this one, I almost completely phased this feature out in favor of working on bounding the map and locations that render on it dependent on User's locations. Unfortunately, I chose to focus on getting the core functionality working as smoothly as possible at the cost of nonessential features. Not only did I move my focus away from inessentials, but this feature was stymied by the libraries I used. This is the one that hurt the most to kill. Interacting with a map can be difficult and ways to narrow a user's focus down to only what they want is important. I added a few niceties to the front-end that made the user experience better, but still it can be overwhelming to use a blank map when you have the entire world to choose from.
The back-end for this project was disappointingly simple. I think that most of the interesting features usually come from a complex and clever back-end. Making large queries based on validations and knowledge of structures in place look easy is skill set I would like to build upon. The better a database is designed the less you're supposed to notice it. To that end, at least, I think the early planning of the roll out of back-end features worked. I spent a very small amount of time working on the back-end because my planning allowed me to implement it and then essentially forget it. The monolithic design structure and waterfall approach to building features before I needed them would have saddled me with even more dead end features.
Top comments (0)