The end is here! Well... at least the end of the Rails section of the Learn.co Software Engineering curriculum.
For the project, I created a web application called Social Grads - a social tool for graduate school submissions. This app was inspired by the forum section of The Student Doctor Network - if you have never been to this site, it's AMAZING.
When I was applying to grad school myself, I spent MANY hours reading anything and everything I could on this site. Two of my favorite (and super popular) forums are "The All-Encompassing, "What are my chances" thread!" and "Applied, Interviewed, Rejected, Attending" - the latter is truly what inspired me to create Social Grads. I know the pain of scrolling down to read every last post hoping to find any information on who is applying to what school, what their background is, and most importantly, did they get in?
Social Grads takes this forum and creates a tool where users can create an account and add their information to a user profile. Users can sign up for a new account or login via GutHub.
Once logged in, they can add submissions for each program they are applying to as show below:
Not only is this an easy way to keep track of all the programs you are applying to, you can also easily search the site for other users - look at their profiles, see the submissions they have created and even look at college profiles with a summary of all the submissions by the Social Grads community who have active submissions at that school.
Reflections
User experience & urls
I added my nested routes after I had already done a fair amount of work on the rest of my app and view pages. When I was reviewing my application I noticed that while my app was redirecting to the correct views, my urls didn't always follow a consistent path that would make sense to a user as they are navigating the application. Essentially, the application was functioning correctly but would likely cause confusion once deployed in the real world. This exercise highlighted that it is critical to not get lost in thinking about our applications from the developers point of view - but to always remember to think about the design from the user's perspective.
Focus on MVP
A challenge I saw myself falling into was getting overwhelmed with all the features I could add or wanted to add. I would spend time thinking through everything to realize a few hours passed and I hadn't added a single feature. I learned that it is better to hit that MVP to meet the requirements of the project even if there is a lot more potential. To keep momentum through this journey, I need to focus myself and know that I can always continue to build on this project later as well. This is something I will have to remember when it's time to build the final project for this program.
Commit F.R.E.Q.U.E.N.T.L.Y
One of the biggest lessons this project has taught me is to be more thoughtful and frequent with my commits. I used to commit features as a package (login, logout, new, edit etc...)
This method worked for a while - it was neat and clean. If I wanted to see all code that went with adding a feature, I had it all in that single commit. However, this is not the best use case for commits.
Two-thirds into this project, my master branch and my local directory somehow didn't align. I still had code that hadn't been pushed up because I was waiting to finish a feature. After much debugging (git stash, git pull, git rebase....) with the help of my instructors, the only thing that worked was:
git add .
git commit -m 'Please work.'
push --force
I forced all my code in one commit - luckily, this fixed my merge conflict but I lost some code.
Lesson learned. Commit frequently, even if it is a single addition of a link to a view page. You will thank yourself later!
Happy Coding,
Michaella
Top comments (0)