Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chitter Challenge Most Recent #2195

Open
wants to merge 47 commits into
base: main
Choose a base branch
from

Conversation

MattHammond94
Copy link

Personal review:
I wanted to jump straight into the project after completing my design recipe for how the database would work/interact with the repo classes so I only gave a short overview to how the routes would work and this can be referenced in the “routes_recipe.md” file.

I quickly became intrigued by new ideas and new features as I was working through creating the routes which meant my test driven approach became somewhat sloppy and less structured.

Also because of this my commits also became relatively fast and loose and not as structured as they have been on previous projects.

I also encountered issues later on down the road where because my tests were written before having figured out a specific function I caused a mass of problems for myself when tests had to be re adjusted.

I reached out for help from the coaches after implementing the BCrypt gem as I was struggling to use dependency injection to test the encryption was working at the login stage.

Kays solution can be seen on line 52 of the maker_repository_spec.rb file.

After Kay helped to resolve this I realised my tests would need to be adjusted as the seed files were created pre the encryption change meaning their passwords were not encrpyted in the database.

Questions:
Do I still need to write fails within my repo classes? I have scenarios which I want to fail and these scenarios will return a 500 error anyway when the route is found/called. Where would I control these fails, within the route or the class method?

I’m starting to stack up a large amount of view/erb files - is this normal?

I have a method used to validate all the params for user signup. Is it better to refactor this into 4 different methods one for each param? I think this is a safer approach but would violate the DRY principle as I would be repeating a lot of variables.

What’s the best approach to get all my commits(green squares) to show on my commit history on my own GitHub? They don’t currently show as the repo worked on was forked from makers (I want my commits lmao)

Chitter to do’s:

  1. General design/look - Learn and apply more CSS - currently mad ugly
  2. Reformat the way the time/date is shown.
  3. Further tests added to control user input
  4. Go back and research database joins - use this knowledge to implement comments on peeps
  5. Add a route to the user page for removing account - implement a piece of JS to warn the user that is account is removed all peeps will go with it.
  6. Add some regex to control password and email acceptability.
  7. Update and include diagrams in my route recipe/design
  8. Finish README
  9. IMPORTANT - DEPLOY THE DAMN TING!
  10. For fun: Maybe add some censorship

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant