Rails Project Management, (or just RailsPM) is my first full scale web application, built from scratch for my Flatiron School Ruby on Rails assessment. As a former project manager, I thought it would be fun to build an app based on the knowledge I acquired at my previous job. While realistically I wouldn’t be able to currently build an application that could complete with robust software on the current market (like Teamwork, my favorite PM application), I had a lot of fun in the process. There were a number of challenges I faced along the way but I also learned a lot!
About Rails Project Management
RailsPM features include Projects, Tasks, Notes, Comments, and Tags. Users can create Projects and invite other users to collaborate on those projects with View or Edit permissions, which can be managed in Project settings. Every Project has Notes, Tasks and Comments. Notes are singular objects used to store general information related to a project (EG a project scope document, perhaps). Tasks are the meat of Projects. Tasks can be created and assigned to users. Tasks can be marked complete when they’re done. All users collaborating on a project can comment on tasks. Lastly, Tasks have Tags, which help identify keywords associated with a task (The plan was to extend the application with tag search feature and some sort of aggregation of the tags, but I had to cut these features). I also added an Admin section. Admins have permissions to view and manage everything, but currently the only functionality available through the interface is to update User profiles (changing passwords, deleting accounts, etc.).
Model relationships. Figuring out the appropriate types of models and their relationships was tough, but I definitely had an easier time on this project than with the Sinatra Car Maintenance Tracker, especially with the UserProject join model for the User and Project relationships. A user can own a project but also be a collaborator on someone else’s project.The UserProject model also included a permission column so we know what type of relationship the project collaborator has to the project (view or edit, managed by Pundit). Figuring out how to create these advanced relationships was tricky but I definitely understand it much better now!
Scope Creep. You would think that as a former PM, I would be able to fend this off. The problem is I became way engrossed in this project (not necessarily a bad thing!) and if I had an idea that seemed halfway reasonable and directly related to a feature I was working on, I would try and implement it. This was not a good idea as it distracted me from meeting the actual project requirements, introduced more bugs and testing, and extended the timeline for the entire project. About halfway through the project I put the brakes on this and started cutting features that were not critical to meeting the project requirements. It’s also worth mentioning that I started with a different, well documented, well planned idea ( a personal task manager ) that evolved over time into Rails PM so a lot of that planning went out the window.
Devise for authentication. Devise was tricky (and frustrating) when I first started learning it. I felt that because it hides a lot of the details in the gem, I was clueless as to what was going on under the hood and how to modify it. However, after reading more of the documentation and working with it on this project I am much more comfortable using it and modifying it from it’s default behaviors.
Front end styling. This took a very long time, even using Bootstrap. I probably could have saved some time if I started the styling earlier in the project, versus waiting until most of the features had been built. This led to a lot of initial CSS code duplication and no styling guidelines for me to work with, which also slowed me down.
Workflow with Git. My workflow, including how I branch, the frequency of my commits, and the commit messages were decent at best at the beginning of the project. Much like the feature building, the quality of my workflow vastly improved halfway through the project after I read up on best practices for Git and related workflows, including committing small, related chunks of code every few minutes, using specific (but not overly specific) commit messages, and using master / develop / feature-xxx branches. I discovered GitFlow during my project and will certainly be using it on future projects.
Overall, this was a challenging project to work on but I learned a lot. I improved on constructing models and relationships, using Devise for authentication, and managing my Git workflow. Now that I’ve built a complex project (versus managing it) I’m keenly aware of how easy it is for scope creep to set in and will be much more vigilant about it on future projects.
Check out Rails Project Management in action:
Check out the Rails Project Management repo on Github .
Suggestions for Rails Project Management? Leave them in the comments or shoot me an email at firstname.lastname@example.org.