It is time. Your final project for this course. This is the capstone project that you'll be showing off to demonstrate all the things that you've learned so far. This is awesome.
Before we dive into what your project is going to be about, we need to establish some ground rules.
For this project, you get to pick what you want to work on within Nitro. You can choose any area of Nitro that interests you, whether it relates to your past roles at Power or not. While the scope is not limited, be mindful not to choose something too large, as there is a lot of new material that may take time to learn. Your project doesn't have to be practical or useful, though it must be related to Nitro/Power.
Your project must meet the following criteria:
- TypeScript React with GraphQL and Apollo:
- Implement at least one query and one mutation.
- React Hook Form:
- Integrate React Hook Form into your project for form handling.
- Playbook Kits:
- Use at least 3 playbook kits in your project for consistent and reusable UI components.
In addition to the primary objectives, aim to incorporate the following elements to elevate your project:
- Rails Page: Incorporate a Rails page (or multiple rails pages) into your project that includes the following:
- ViewComponent: Utilize ViewComponent for building modular, reusable views.
- Stimulus: Add interactivity with Stimulus.
- Specs: Include specifications, especially for GraphQL operations.
- Styling:
- Ensure your project follows Nitro's styling guidelines by utilizing Playbook kits for consistent design. Additionally, adhere to Nitro's established conventions for CSS and component structure to maintain coherence with the existing codebase.
- Responsive Design:
- Make sure your project is fully responsive, adapting to various screen sizes and devices. This can involve using CSS Grid, Flexbox, or Playbook kits designed for responsiveness.
As mentioned, your final project will not be a standalone codebase. Instead, it will be a Pull Request (PR) opened up against the nitro-web
repository. Your PR should follow all best PR conventions:
- Accurate PR title
- Correct team label as well as correct use of WIP label (xavier, WIP)
- Detailed PR summary that includes:
-
- Complete sentences and paragraphs explaining your additions
- Screenshots of all your additions
- All React code must strictly adhere to ESLint conventions
- All Ruby code must strictly adhere to Rubocop linting conventions
- All of you code must not break any automated tests (
rspec
andmocha
) - Commits should be small and logical changesets. Read this article about best practices with commits and apply its seven rules to all of your Nitro commits.
- There must be a commit level divisions between each tier
For the most part, Nitro uses the newest tools, libraries, and technologies out there. However, the application started in 2009. So it also contains a lot of valuable, profitable, substandard, old code. Why "fix" something if it isn't broken? Changing code simply to use a newer system is risky. There has to be a clear reason to take that risk. If there is not a good reason, older code should not be changed.
There may be 3 different ways to accomplish a goal in Nitro. To decipher which coding approach may be the best to mimic, you have to ask. Lean on you instructor, TAs, and your team when the best way to make an addition is not clear.
One such example is functional components versus class components in React. Both exist in Nitro, but functional components are now the better and official way to write React (in both Nitro and React communities).
-
Kanban/Scrum Board: Because this will be the most complex project you've made during this course, you'll need something to keep you organized. We recommend Trello or a Github Project Board. Use this to track what you're doing and what you need to work on. It's also a great idea to keep track of bugs that you're not going to immediately fix.
-
Pomodoro Timer: If you don't take breaks, you'll end up hurting your eyes, getting RSI (repetitive strain injury) or burning yourself out. The Pomodoro Timer method lets you put in solid chunks of work while also giving you regular breaks. We like Marinara Timer, since it's nicely customizable.
This is when you get to pitch whatever ideas you have for what you would like to build. We're not yet worried about what your Minimum Viable Product (MVP) is or whether your idea is practical --- just come up with ideas. Think of this as your research and development phase. Take some time to research and learn some additional concepts that could be helpful in your project plan. Your instructor will give you an idea of what is and isn't practical, and provide some guidance on the technologies you're investigating.
Project proposals must be submitted, presented, and approved in advance of building your capstone. You must complete a project pitch meeting with an instructor.
Resources:
- How to put together a software project proposal
- How to Write a Software project Proposal from Rutgers-
- How to write a proposal and get what you want
After your proposal is approved by your instructor, you may proceed with building your project.
Create a schedule that allows you to build out the bulk of your project. We encourage you to jump into the watercooler to connect with other classmates or join an Open Office Hour if you have questions about how to implement something in your project. You can find the schedule for these sessions in the calendar in Homeroom on Canvas.
Build out the full scope of your project plan and improve the styling of your project. Ensure that all bugs have been resolved and that the project is fully functional. Styling s is an important skill that you want to practice and demonstrate. Once your project is completed, please submit the project in Canvas.