- this setup contains a rakefile with helpful process reminders
After you have drawn your ERD out (with the "crow feet" & attributes/proper foreign keys) and decided on the user stories, follow these steps.
- Fork and clone the repo,
cd
to the folder and then runrm -rf .git
to remove git tracking. This will allow you to use this repo as your own repository, unconnected to mine. Go to github, create a new repository and upload the starter there. - Create/update the info in the Gemfile + run
bundle
- Create migrations: run
rake db:create_migration
and add the syntax you need (e.g.NAME=create_users
) - Migrate: run
rake db:migrate
- REMEMBER never ever ever change anything manually in the schema.
- Go to
.bin/run.rb
and change the name of the app on line 3 AND/OR go toRakefile
and change the name of the app on line 15 - Go to
./app/models
and change the names of the files (e.g.User.rb
<- singular) and the class names inside - Set up association macros in classes (
belongs_to
/has_many
/has_many, through:
) - Create seed file in
db/seed.rb
+ then runrake db:seed
- remember: seeding does not give you any output so no news on your console == good news
- Check if you've seeded correctly: run
rake console
and check the last instance of any of your class - Go to
./app/yourAppName.rb
and change that file's name and whatever is inside (the class name should correspond to what you wrote in.bin/run.rb
on line 3) - Go to
./Rakefile
and change nameOfYourApp there as well (save the file!); - Now you can start your app either by running
rake start
in your terminal OR by runningruby ./bin/run.rb
. You can delete the rake task or therun.rb
if you have a preference. You can also change the rake task name, or even -- more advanced and not necessarily the best use of your time -- create an alias that would start your app - Remember to change the readme at the end. If you need an inspiration on how to write a good readme, check this blog post.
- Create a dummy version of your logic -> hardcode it and don't yet make your code save anything to the database, just make sure that the logic works
- Test often by running the file, by running
rake console
or bybinding.pry
- What I fould useful is drawing out every step I want to guide users through before coding - my whiteboard looked like this:
- I first coded the dummy version (without saving to the database, just to see if all "if"s are working and all that jazz)
- Then I added the database methods.
- Then only I beautified the code and the app to make it visually pleasing
I thought I’d share the git workflow my tech collective follows:
- Add everyone as a collaborator to the repo
- clone the repo; in the repo, have two standard branches:
main
anddev
; - before a coding session (each time), first run
git pull origin main
, thengit checkout -b nameOfTheFeature-yourName
; every now and then, once you’re done with some deliverable, add/commit/push the code to that new branch;- ALWAYS WRITE DESCRIPTIVE COMMIT MESSAGES, it is extremely important for the future employer -- here's a guide to what makes a good commit message
- once the feature is “done” and you checked whether it’s not bugging out, merge it to
dev
:- add/commit/push your code to your feature branch
- then change the branch to dev:
git checkout dev
- then merge:
git merge nameOfTheFeature-yourName
- then test all your code (in rake console test the associations, in CLI test the workflow)
- fix bugs, add/commit/push
- once it’s on the
dev
, your partner checks your code and if it’s okay, they merge it tomain
; SO:
main branch
: ONLY push to this branch if the feature is working + reviewed by both partnersdev branch
: code that works + is up for review (it’s like a pull request)feature branch
: always created from the last version of thedev branch
, contains code in progress
PLEASE DO USE MULTIPLE BRANCHES AND NOT ONLY ONE to minimize the risk of overwriting your working code with an accidental commit. Traveling in time with git is possible but it’s not the most pleasurable thing to do with your day.
For project management, we use git projects (instead of trello or asana) and git issues. We do stand ups and stand downs every day, where we distribute tasks and give summaries of what has been done. We pair program whenever possible, stair each pairing with discussing ground rules and end with giving each other feedback. However, given the fact that we all have full-time jobs it is not always the case.
I collected tools for your app that might be helpful.
tty-prompt
- nice interface for prompting for user input -- see here how to set it uprest-client
- make HTTP requests and get data from APIsfaker
- randomly generated seed data funcolorize
- colored text output in your terminallolcat
- enabling rainbow text coloringformatador
- styling output information into a neat tableartii
- creating text banners
- tty-box -- creating boxes in your terminal
- tty-progressbar -- flexible progress bar drawing in terminal emulators
- tty-tree -- if you want to represent e.g. file structure
- tty-reader -- allows you to trigger some events on specific keys
- tty-markdown -- formatting tools for long texts
- Lecture: Setting up TTY Prompt in your CLI by Sylwia Vargas
- Adding animations to your CLI by Sylwia Vargas
- Adding ASCII Art to your CLI by Sylwia Vargas
- Reload method for when your CLI doesn't reflect the changes you've just made -- a blog by Alex Suthammanont
- Sending SMS with Twilio API in your CLI by Danny Sasse
- Refactoring your app into modules by Danny Sasse
- Introducing music to your CLI
- Streamlining git add/commit/push by Shane Lonergan
- Good git primer by Isabel K. Lee
- A git cheat-sheet
- Project tracking tool from GitHub (where you can connect projects, issues, etc) by Isabel K. Lee:
- Terminal recording for your readme
- Github projects for better project management