You've all done a fantastic job get to this point and we are all excited for next week. Let's talk about what your technical work will look like starting next week!
Priorities
- Finish current features (especially if you don't have much CRUD)
- Heroku Ready
- Styling
- Round-out the core of the app MVP
- Tests and Refactoring
- Needle Moving Dream Features
- New App / New Study
- We'll want to ensure that we continue to train each of these muscles strategically.
- Maintaing daily organization and motivation will be EXTREMELY important. When you feel yourself becoming frazzled, I encourage you to work away from your home, hang out with your fellow launchers or get out of your house!
- When in doubt, follow the post grad plan, and reach out.
We strongly recommend you continue to add depth to your breakable toys for at least the next 3-4 weeks.
You need to ensure that what you have, regardless of where it is in your app story timeline, is minimally polished. This way those going to your website do not see empty webpages, unstyled elements, and half finished features. This is priority number one. You can't have unfinished features in main or on heroku anymore.
- Use BT Deliverable Part 3 as a rubric
- Ensure that both admins and users can CREATE something on your site
- Bounce feature ideas off the EE team for guidance
Remember to think Agile. Iterate and plan features in small scope. One branch at a time. Do not give up on Git after the program, otherwise you're codebase will be a mess and take as much time to maintain as it does to develop.
Reference for getting the right style: Styling Best Practices
I encourage folks to look at Blue Apron for simple modern styling as an example
Common Pitfalls
- colors blend together because there is not enough contrast
- too much colored text
- colors on the site are too bright or too saturated
- too much whitespace
- some elements are still at base style or base Foundation styling
- form fields are still full width
- text is still serif
- forgot to avoid italics and underlines in headers
- buttons foundationay or default gray
Your ability to use CSS is not most important. Your ability to remark upon and evaluate the styling of what makes OTHER sites remarkable is. Don't style blindly, find similar websites and take inpsiration from them.
- Deploy with every new merge to main to your staging environment.
- Click test your core features
- If errors, use
heroku logsto isolate, or make a post-grad request for support - Don't forget to return to material in GP weeks when setting up new apps (ENV keys, production configuration, running commands in heroku, etc)
- Begin adding cypress tests for each of your features
- Begin adding API endpoints for your APIs
- Unit tests: relevant if you have a POJO/Service Object
Unit tests require SMALL method on service objects. You might have method that converts measurements from grams to kilograms, but it will be difficult to test if the method is 30 lines long. Only those methods that you call ON the service object should be tested. Methods that are simply helpers to other methods don't need to be tested.
Tests are lower in priority for evaluation readiness, particularly given that every company does them differently. But even just getting some basic test for your simpler features is a good proof of concept.
The guiding advice is: reconsider how you can make each file less than 100 lines with helper methods and service objects
-
POJOS: If you have any sort of API integration, its time to finally abstract that into a POJO to hold that logic and state rather than have it in your controller. This POJO should initialize with any data that it needs to make a Got or third party api requests, and should have separate methods for: making the api request; parsing the response; retrieving important info from the response and formatting it. See our best practices facilitation for guidance.
-
Simplifying Controllers Many of you have router routes that are too long and are responsible for many things. Start thinking about how you can take some of that logic and either add those to services, or create a data management POJO that performs some logic for you.
-
POJOs and Functions as Modules Your top level component/containers are meaty. I would advise moving each fetch request into a function in its own file (ideally in a separate folder called
apiorrequests). You can then import and use that fetch request as needed in any component. If you have numerous fetch requests, you can also optionally define these methods asstaticmethods (similar to class methods but for JS) on a new POJO
const getAdminUsers = () => {
fetch(/api/v1/admin/users)
.then(...)
.then(() => {
return response.json()
})
}
export default getAdminUsersimport createNewUnicorn from ....
import getAdminUsers from ....
class UnicornApi {
static createNewUnicorn(newUnicornPayloads) {
return createNewUnicorn(newUnicornPayload);
}
static getAdminUsers() {
return getAdminUsers()
}
....
....
export default UnicornApi
- Serializers: Use em if you arent....Or else. In addition to whitelisting properties, they can also become more advanced if you want to coordinate a lot of information that you wish to send to the frontend, and can become a lot more complex.
- Prioritize finishing your core CRUD/MVP if you have not already!!!
- Consider first quality of life features: how easy is it to navigate around the site? How does my site's accessbility compare with that of similar sites on the web?
- Begin considering CTAs: what do you want your user's to be focused on doing?
- Mobile-first design / styling
- Expand your ER diagram: how can user's access historical data? What can admin's do with the historical data?
- Add more datapoints: if your app tracks cool restaurants, what aren't you tracking in your DB? Can we track categories of restaurants, accessibility, restaurants for delivery/takeout, chains, etc. And how do my user's intereact with these restaurants?
- With your newly tracked data, more features can be added. Data visualization, email reminders, and new APIs can be utilized.
We recommend working on your final project for at least 2 more weeks (at roughly 20 hours a week) during post-grad if not longer. Consider how motivated you are, and whether or not new features would improve the app. Consult with EEs if you think you are ready to move to your next project.
To begin once you have finished, polished and refactored your BT
-
Review any concepts that didn't make sense!
-
SERIOUSLY THOUGH. What assumptions have you been making? What concepts have you been avoiding reviewing and understanding?
-
First Priority: Review Other React Hooks: Specifically,
useReduceranduseContext. Beyond the react docs themself, I would recommend this tutorial, in combination with others on line. https://hswolff.com/blog/how-to-usecontext-with-usereducer/ -
Second Priority: get more vanilla JS depth - domain knowledge and OOP (Dan Abramov's Just JavaScript). You should not need to refer to JS documentation for whiteboarding or React in interviews.
-
Adjacent technologies. Greater depth of Knowledge in React and Node with new projects is encouraged. Typescript. Investigating GraphQL, React Query, Gatsby for static sites and React Native.
- Find a compromise between your interests and what the market wants...but lean toward the market
- Join groups like Boston Ruby Group, Boston React or JS groups, Code for Boston, Railsbridge or Inclusive Tech Lab to start collaborative projects
- HACKATHONS ARE VERY VERY GOOD
- schedule your days
- wake up early
- get dressed
- get to work
- get accountability
- get you some R&R
- Becoming a hermit in your home
- Not talking to other launchers or engineers
- Not taking notes and making action items after interviews
- Not learning new things
- Having unfocused coding projects
- Not networking
- Slowing down on job apps
- NOT TIMEBOXING
Remember that one of the most important things that you can do is get more "at-bats". The only way to do this is to continuously apply to numerous jobs, work with numerous technologies and NETWORK.
- See the technical resources below
- Review all of the Screening Questions
- If you don't know how a technology we use works, now is the time to polish up on that
- All of you are likely currently weak at: JS OOP & JS Domain knowledge & Big O / Comp Sci topics
- As such, return to games like "High Card Dealer" or "Blackjack and tackle in JS. Start to scrutinize and find best practices or ask for review. Alternatively, start adding service objects to your app
Technical Interview Prep Resources
- Just Javascript Course with Dan Abramov
- Practical Object Oriented Programming in Ruby (POODR) by Sandi Metz
- The Pragmatic Programmer (ideally the latest edition)
- The Ultimate Guide to Kicking Ass on Take-home Coding Challenge
- Front End Developer's Handbook
- Domain Level React Questions
- Consider reading "Eloquent Javascript" textbook.
- Take a cursory look at react hooks https://reactjs.org/docs/hooks-intro.html (new curriculum updates on the way!)
Whiteboarding
- Interview Cake https://www.interviewcake.com/table-of-contents
- LeetCode https://leetcode.com/
- CodeWars https://www.codewars.com/
Forums CS Career Questions Subreddit
Increasing Typing Speed
Remember, Launch Academy has been a sprint, and a rightly tiring one. Once you have hit the minimum action items each week, your should also be considering how you can reserve a healthy work/life balance for yourself once again. Your mental and holistic health are important!
Be a part of technical post grad support and we can help you with work styles and with your apps!