DEV Community

Anya Brun
Anya Brun

Posted on

1 1

rails new task-team

NOTE: I wrote this blog post some time ago for Phase 3 of my Flatiron School SE program.

My goal for this project was to refine my process for building apps, in order to do so more efficiently. I came up with the following list of steps + questions to guide the development process:

Brainstorm app idea

  • What problem do you want to solve?
  • What experience do you want to provide?
  • Is there something your app can make more convenient or less confusing/time-intensive?
  • Why should a user choose your app over another?

Write up User Stories

  • Who is going to use your app? What is your target audience?
  • What exactly will members of that audience want to do with your app?

Draft a list of features

  • What features make the app? What are the MVP (minimum viable product) features?
  • What stretch features will you add if the MVP is completed ahead of schedule?
  • What features can you omit from the first version? What features will be added with subsequent releases of your app?

Backend, pt. 1 - Schema, Models, and Associations

  • What models does your app need? What attributes do those models have?
  • How are those models related? What associations are necessary to make these relationships work?
  • Create a detailed schema diagram.

Backend, pt. 2 - bin/rails console

  • Write out seed data based on your user stories.
  • Test associations in the Rails console. Be thorough and use the seed data to exercise your models & associations in a similar manner to how they'll be used in-app.
  • Make any changes to models or schema, if necessary.

NOTE: go feature by feature (i.e., build vertically).

Frontend, pt. 1 - views

  • Make mock-ups (e.g., wireframes) of every page (or the most important ones, at least) your app will need.
  • Note how a user will get from one page to another, and consider a nav menu for getting to frequently-used pages quickly.
  • Generate dummy views (e.g., a login form that isn't connected to the backend).

Frontend, pt. 2 - controllers

  • Generate controllers and routes needed for the feature you're working on.
  • Make the "dummy" views "smart" by grabbing and/or manipulating the data you need and displaying them to the user.

DRY things up

  • Consider ways you can slim down your controllers by extrapolating logic into class/instance methods on models.
  • Write helper methods for actions you perform repeatedly, such as grabbing the current user from the session user id.

Finishing touches

  • Style your app, maybe using a framework or some simple HTML & CSS.

NOTE: I have yet to start writing tests. However, I plan on incorporating this into my development process in the future. As of now, I'm relying on manually testing stuff like models, views, &c.

The aspect of the development process with which I had the most difficulty was creating the backend--namely, creating and associating models in a way that made sense for my app.

The (relatively) final version of my app ended up with 4 models: User, Team, List, and Task.

Initially, though, I didn't have the Task model. I was trying to associate the remaining as follows:

  • User has_many lists and has_many teams through lists
  • Team has_many lists and has_many users through lists
  • List belongs_to user and belongs_to team

That wasn't working because it didn't make sense for List to be the join-table, as it were, between User and Team. And building the association the other didn't make sense because a List can't have_many teams. No matter how I tried to make it work, it wouldn't--because that's not the relationship between these models "in real life."

Outside the context of a Rails database, a User can work independently of a Team, as well as collaborate with other people. A person belongs to a Team, and the people on that team may be grouped into sub-teams (which I simplified into Lists) to work on different tasks.

  • A User (optionally) belongs to a team, has many tasks, and has many lists through tasks. The tasks are directly associated to the user because many different users can have assigned tasks on the same list.
  • A Team has many users and lists, and has many tasks through lists. Tasks are associated through lists because a user may leave a team, yet the list is "stuck" to the Team and will still have the task (that was formerly assigned to the user).
  • A List has many tasks, has many users through tasks, and belongs to a team.
  • A Task belongs to a list and (optionally) to a user (allowing for tasks to be 'unassigned').

Structuring the relationships this way made much more sense and allowed me to proceed with considerably less confusion and headache.

I knew designing the database was (arguably) the most important part of building the MVP, but I underestimated how much time I should spend brainstorming/planning/testing my models and associations. On my next project, I'll dedicate more time to this step of the process so that subsequent steps can progress smoothly.

Image of Datadog

The Essential Toolkit for Front-end Developers

Take a user-centric approach to front-end monitoring that evolves alongside increasingly complex frameworks and single-page applications.

Get The Kit

Top comments (0)

Hostinger image

Get n8n VPS hosting 3x cheaper than a cloud solution

Get fast, easy, secure n8n VPS hosting from $4.99/mo at Hostinger. Automate any workflow using a pre-installed n8n application and no-code customization.

Start now

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay