Giters

maxmiller413 / Ruby-CLI-Setup

đź”»A treat for those who'd like to make a ruby CLI but don't know where to start.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Ruby CLI stub repo

NOTE

  • this setup contains a rakefile with helpful process reminders

Table of Contents

Getting started

After you have drawn your ERD out (with the "crow feet" & attributes/proper foreign keys) and decided on the user stories, follow these steps.

Setup

  1. Fork and clone the repo, cd to the folder and then run rm -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.
  2. Create/update the info in the Gemfile + run bundle
  3. Create migrations: run rake db:create_migration and add the syntax you need (e.g. NAME=create_users)
  4. Migrate: run rake db:migrate
  • REMEMBER never ever ever change anything manually in the schema.
  1. Go to .bin/run.rb and change the name of the app on line 3 AND/OR go to Rakefile and change the name of the app on line 15
  2. Go to ./app/models and change the names of the files (e.g. User.rb <- singular) and the class names inside
  3. Set up association macros in classes (belongs_to / has_many / has_many, through:)
  4. Create seed file in db/seed.rb + then run rake db:seed
  • remember: seeding does not give you any output so no news on your console == good news
  1. Check if you've seeded correctly: run rake console and check the last instance of any of your class
  2. 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)
  3. Go to ./Rakefile and change nameOfYourApp there as well (save the file!);
  4. Now you can start your app either by running rake start in your terminal OR by running ruby ./bin/run.rb. You can delete the rake task or the run.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
  5. Remember to change the readme at the end. If you need an inspiration on how to write a good readme, check this blog post.

Coding

  1. 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
  2. Test often by running the file, by running rake console or by binding.pry
  3. What I fould useful is drawing out every step I want to guide users through before coding - my whiteboard looked like this:
  4. I first coded the dummy version (without saving to the database, just to see if all "if"s are working and all that jazz)
  5. Then I added the database methods.
  6. Then only I beautified the code and the app to make it visually pleasing

Github workflow primer

I thought I’d share the git workflow my tech collective follows:

  1. Add everyone as a collaborator to the repo
  2. clone the repo; in the repo, have two standard branches: main and dev;
  3. before a coding session (each time), first run git pull origin main, then git checkout -b nameOfTheFeature-yourName; every now and then, once you’re done with some deliverable, add/commit/push the code to that new branch;
  4. 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
  5. once it’s on the dev, your partner checks your code and if it’s okay, they merge it to main; SO:
  • main branch: ONLY push to this branch if the feature is working + reviewed by both partners
  • dev branch: code that works + is up for review (it’s like a pull request)
  • feature branch: always created from the last version of the dev 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.

Tools

I collected tools for your app that might be helpful.

Fun Gems

  • tty-prompt - nice interface for prompting for user input -- see here how to set it up
  • rest-client - make HTTP requests and get data from APIs
  • faker - randomly generated seed data fun
  • colorize - colored text output in your terminal
  • lolcat - enabling rainbow text coloring
  • formatador - styling output information into a neat table
  • artii - creating text banners

Other tty gems

  • 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

APIs

Tutorials

Other tools

About

đź”»A treat for those who'd like to make a ruby CLI but don't know where to start.

Languages

Language:Ruby 100.0%