One of the most important processes in building any application is planning — let's take some time to map out our project to save ourselves time and heart/headache later. Unlike labs, projects do not have the guardrails of a README and tests to structure your work. Instead, you need to design and plan your features yourself. These tips should help you plan your project effectively.
Use this document to help you complete this planning form
Tips on all aspects of the project are included here, so make sure to have a look through!
Note: Keep in mind that the Ask a Question team is not permitted to help while you are building your projects. Use the internet and the resources provided in this document if you get stuck!
Read through the project requirements here carefully before getting started.
Come up with a project idea of your own, and devote some time to a planning session. Think about the following:
a. Brainstorm the problem that you want your application to solve. It's okay to take inspiration for the features you want to build from other sites or projects you've seen (it's not okay to use their code, though).
b. Plan what features your app will have. You can write User Stories to help make it clear what you are planning to build.
c. Model your domain. You need to know what the nouns in your project are
d. Plan how your features will work. Use this form to jot down your plans and submit them to us so we can see what you are planning! Check out the sections below on User Story and Flow Diagrams for help in filling out the form.
Create a skeleton app and push to a remote repository on Github.
Plan your schedule. Note that it takes most full time (40+ hrs/week) students between 3-7 days to complete, and can take up to 5 business days to schedule your project review after that.
Join the Slack channel #rails-js-section to connect with others who are working on their projects as well. Students often set up a peer review in advance of their project review as a way to practice talking through your code.
User Stories are a powerful tool for succinctly describing a set of functionality in terms of what it allows the user to do.
Some examples of user stories:
When you have written the user stories for your application, you can turn them into the technical requirements needed to turn those stories into working features.
As you turn your user stories into more clear technical specifications for features, you can start by modeling the data that your application will store and show. Identify the nouns in your stories, their properties, and their relationships.
A description of the domain for the above stories might be:
Later on, you will be ready to create the database schema and application models corresponding to this domain.
We recommend using draw.io to put together a flow diagram. It doesn’t need to be over-complicated - just a visual idea of your app’s structure.
You don’t have to use software for this - a photo of a (legible) hand-drawn sketch on a napkin also works!
The following GIF shows how to make a shareable link on draw.io:
Please make sure the image or file you share with us is accessible.
(Minimum Viable Product, As Soon As Possible)
Building things is hard. It's tough to predict what will be difficult in a project. Sometimes things that appear on the surface to be easy will end up taking hours of debugging.
With that in mind, it's important to build a Minimum Viable Product (MVP) as quickly as possible. Instead of getting stuck on advanced features, start with a basic working version of the application, then steadily add features piece by piece.
It's easy to end up having to do lots of rework and fixing depending on how you order the things you build in your application, particularly if you build 'horizontally.'
You can visualize all the parts you of an app you need to build as a grid, with the features along the x-axis (columns) and the different layers of the stack along the y-axis.
A strong temptation is to build your project row-by-row. It feels easy to start by writing all the migrations for all your models, then all the models, etc...
Do not do this!
If you try to build all your migrations, then all your models, then all your controllers, then all your fetch calls, then all your view logic, you will have a bad time. Inevitably, your view logic will end up requiring changes to the underlying layers, and you will write code that doesn't get used.
Instead, build vertically, column-by-column. Write code for all the vertical layers involved in one feature before moving on to the next feature. That way, you'll minimize rewriting, and end up with working features without waste.
A visual explanation of this suggested development workflow can be found here
The project process should look like: