├── README.md ├── first_meeting.md ├── case_study_project.md ├── offroading.md ├── solo_project_requirements.md ├── how_to_ask_for_help.md └── git_guide.md /README.md: -------------------------------------------------------------------------------- 1 | ## Apprentice 2 | 3 | My guide on how I mentor Junior developers. I am formerly a mentor at [Bloc.io](www.bloc.io) but also have taught at [Railsbridges](http://www.railsbridge.org/). 4 | 5 | ### Topics 6 | =========== 7 | 8 | #### [First Meeting](https://github.com/wonderwoman13/apprentice/blob/master/first_meeting.md) 9 | 10 | #### [Git Guide](https://github.com/wonderwoman13/apprentice/blob/master/git_guide.md) 11 | 12 | #### [Offroading](https://github.com/wonderwoman13/apprentice/blob/master/offroading.md) 13 | 14 | #### [How to Ask For Help](https://github.com/wonderwoman13/apprentice/blob/master/how_to_ask_for_help.md) 15 | 16 | #### [Solo Project Requirements](https://github.com/wonderwoman13/apprentice/blob/master/solo_project_requirements.md) 17 | 18 | #### [Case Study Project](https://github.com/wonderwoman13/apprentice/blob/master/case_study_project.md) 19 | 20 | ### Contributing 21 | ================ 22 | 23 | If you have other topics that you would like to add when mentoring junior developers, please submit a pull request. 24 | -------------------------------------------------------------------------------- /first_meeting.md: -------------------------------------------------------------------------------- 1 | ## First Meeting 2 | 3 | One of the most important meetings a mentor will have with a mentee is their first meeting. Mentoring is not only about learning how to code but understanding your mentee's motivations and goals. This usually means asking a lot of questions and listening. 4 | 5 | 1. What inspired you to learn how to code? 6 | 7 | _I'm looking for their motivations._ 8 | 9 | 2. In an ideal world, what kind of coding position would you want? In office or remote? 10 | 11 | _It's harder to secure a remote junior position._ 12 | 13 | 3. Tell me about your working career so far. 14 | 15 | _This helps me think of what industry or positions they would be suited for._ 16 | 17 | 4. What does your typical week look like? When will you be coding? Night? Day? Weekend? 18 | 19 | _When will they be contacting me for help or feedback?_ 20 | 21 | 5. Do you tend to be more of a visual or text learner? 22 | 23 | _Will they want to watch the videos or will they prefer reading the curriculum?_ 24 | 25 | 6. From the coding exercises you have done so far, what did you think? 26 | 27 | _What languages did they gel with?_ 28 | -------------------------------------------------------------------------------- /case_study_project.md: -------------------------------------------------------------------------------- 1 | ## Case Study Project 2 | 3 | As my mentees work towards their portfolio, I encourage them to create an application that they want to create. During a Bloc.io course, this is called the Capstone Project. 4 | 5 | I ask that they build an app that they 6 | 7 | * Would want to use 8 | * Have domain expertise in 9 | * An idea that they've experienced missing from the market 10 | * Above all, has a great story to tell in an interview or lightning talk 11 | 12 | I ask them create to a Google Doc so we can pair on the project requirements with the following template: 13 | 14 | **************** 15 | 16 | __Name of the Application__ 17 | 18 | _Short descriptive name_ 19 | 20 | __App Availability__ 21 | 22 | _Is this meant for desktop or mobile? Where will you host it?_ 23 | 24 | __App User__ 25 | 26 | _Describe the typical users and the market for the app. Is this for a real market or do you hope to create a market for it?_ 27 | 28 | __Domain Expertise__ 29 | 30 | _Why are you a good choice for building this app? Is there a story?_ 31 | 32 | __Planned Technologies__ 33 | 34 | * ROR 35 | * Postgres 36 | * Rspec 37 | * Bootstrap 38 | 39 | __Third Party Applications__ 40 | 41 | ****** 42 | 43 | __User Stories for Phase 1 of Capstone__ 44 | 45 | _Example: As a user I want to: 46 | I want to be able to sign in, sign up, and sign out_ 47 | 48 | __User Stories for Phase 2 of Capstone__ 49 | 50 | __User Stories for Phase 3 of Capstone__ 51 | 52 | 53 | ****** 54 | __Competitor Apps for Inspiration__ 55 | 56 | __Data Population__ 57 | 58 | * Example: Wikipedia 59 | 60 | __Wireframes__ 61 | 62 | I recommend [Balsamiq](https://balsamiq.com/) for a rapid wireframing tool. 63 | -------------------------------------------------------------------------------- /offroading.md: -------------------------------------------------------------------------------- 1 | ## Offroading 2 | 3 | Based on a students interests, abilities, and company they want to work for, I will "extras" into their assignments so they will become a more well rounded developer. 4 | 5 | ### Devops 6 | 7 | After they have deployed to Heroku for the first time, I request they handle all subsequent app deployments on a bare server (Digital Ocean or Amazon Web Services). 8 | 9 | Deployment guides: 10 | 11 | [Digital Ocean](https://www.digitalocean.com/community/tutorials/how-to-use-the-ruby-on-rails-one-click-application-on-digitalocean) 12 | 13 | [Amazon Web Services](https://www.sitepoint.com/deploy-your-rails-app-to-aws/) 14 | 15 | ## Development Database 16 | 17 | [SQLite](https://www.sqlite.org/) is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. It's great for developing locally but is not ideal for hosting databases in production. After my mentees have completed their Rails project, I have them start developing locally with a production level database, like [PostgreSQL](https://www.postgresql.org/). 18 | 19 | __Installation Guides__ 20 | 21 | * [PostgreSQL Database Installation Guide for Macs](http://exponential.io/blog/2015/02/21/install-postgresql-on-mac-os-x-via-brew/) 22 | 23 | * [PostgreSQL Database Installation Guide for Windows](https://www.postgresql.org/download/windows/) 24 | 25 | ### Continuous Integration 26 | 27 | After my students have completed their first solo project and they start submitting pull requests to me, I ask they set up free opensource CI on their projects. 28 | 29 | My recommendations: 30 | 31 | * [TravisCI](https://travis-ci.org) 32 | * [Codeship](https://codeship.com) 33 | -------------------------------------------------------------------------------- /solo_project_requirements.md: -------------------------------------------------------------------------------- 1 | ## Solo Project Requirements 2 | 3 | ### Authentication 4 | 5 | All junior developers should learn how to roll their own authentication service. That being said, in production, it is far too risky to depend on homemade authentication. 6 | 7 | [Devise](https://github.com/plataformatec/devise) is the most popular authentication solution for Rails applications. It provides a full array of features, and can be configured to meet most requirements. I ask all projects use Devise (but I'd love to have a developer try [Clearance](https://github.com/thoughtbot/clearance)). 8 | 9 | ### Rspec and Simplecov 10 | 11 | The students I work with have been taught to use Rspec. While Minitest has a clean syntax, more positions are looking for Rails developers who have Rspec experience. 12 | 13 | I require all students to install the following gems in their Test group. 14 | 15 | group :test do 16 | gem 'rspec-rails' 17 | gem 'shoulda' 18 | gem 'faker' 19 | gem 'factory_girl_rails' 20 | gem 'simplecov' 21 | end 22 | 23 | [SimpleCov](https://github.com/colszowka/simplecov) is a code coverage analysis tool for Ruby. It uses Ruby's built-in Coverage library to gather code coverage data and provide an interactive coverage report. 24 | 25 | ### Debugging 26 | 27 | All projects must have the following gems installed: 28 | 29 | group :development do 30 | gem 'pry-rails' 31 | gem 'better_errors' 32 | gem 'binding_of_caller' 33 | end 34 | 35 | Pry-rails assists developers in live debugging code and tests. Better Errors and Binding of Caller provide an interactive web console when code errors out. 36 | 37 | ### Pull Requests 38 | 39 | 1. Checkout to a new branch 40 | 2. Complete the feature 41 | 3. Run your specs using Rspec 42 | 4. Verify with the Simplecov gem that your code coverage is at least __80%__ test coverage 43 | 5. Push up the branch and create a pull request (to merge with the Master branch) 44 | 6. Assign the pull request to me. Help guide [here](https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/) 45 | 7. I will make comments and tag your Github handle into them. Keep an eye on Github or your email 46 | 8. Once your pull request is merged, checkout to your local branch locally and pull down the master branch 47 | 9. Check out to your next feature branch! 48 | -------------------------------------------------------------------------------- /how_to_ask_for_help.md: -------------------------------------------------------------------------------- 1 | ## How to Ask for Help 2 | 3 | As you are learning to code, several challenges will get in your way and learning how to ask for help is an art. 4 | 5 | * Developer Tool Issue 6 | * Debugging Code 7 | * Foggy Problem 8 | * The Nuts and Bolts of Implementation 9 | 10 | __Developer Tool Issues__ 11 | 12 | Ever messed up Git before? We all have. When my students suffer from a bad installation, I ask them to message me with this information. 13 | 14 | Operating System: 15 | Installation Steps: 16 | Error Logs: 17 | 18 | __Debugging Code__ 19 | 20 | Every error is an opportunity to learn, almost always about yourself as a developer. 21 | 22 | Bugs are a mystery that are always interesting to crack. Then after the mystery is solved, you can do even better by looking through all your code for similar errors you may have made; and write an automated test to ensure the error will not happen unknowingly again. 23 | 24 | First, try to read the logs for the error. The logs will often print the line that is erroring out with the first couple of lines. 25 | 26 | Second, begin finding bugs by reproducing the problem. Start by getting exact input if you can. Try reproducing the problem in your dev env with as little data as possible. I ask for my students to collect all the conditions present when the problem occurred (for example, other users, data types, etc). 27 | 28 | Here are some suggestions from the Elements of Programming Style: 29 | 30 | * Make sure all variables are initialized before use. 31 | * Don't stop at one bug (there are always more). 32 | * Watch for off-by-one "end" errors. 33 | * Test programs at their boundary values. 34 | * Program defensively. 35 | 36 | Once my students are at a dead end, I ask them to push up their code and tell me the following: 37 | 38 | 1. Commit URL: 39 | 2. I expected x to happen when I did x, but x happened instead. 40 | 3. I tried x. 41 | 42 | __Foggy Problem__ 43 | 44 | At times, the problem is that the requirement is not clear enough. 45 | 46 | I ask my students to message me what they think the requirement is. Many times we (requirement writers) combine requirements, change terminology, and add extra words to our requirements because we haven’t appropriately described or visualized how the requirements fit together and what purpose they serve. 47 | 48 | I ask my students to then break it down further. 49 | 50 | * What arguments are being sent in? 51 | * What class are they? 52 | * Example: 1 Array => ["the", "great", "gatsby"] 53 | 54 | * What value should be returned? 55 | * What class should it be? 56 | * Example: 1 String => "The Great Gatsby" 57 | 58 | __The Nuts and Bolts of Implementation__ 59 | 60 | A solution can be clear but the actual implementation steps might stump a new developer. 61 | 62 | Excellent guide to follow: [Solving Problems, Breaking it Down](https://simpleprogrammer.com/2011/01/08/solving-problems-breaking-it-down/) 63 | 64 | Stack Overflow is a major tool that developers use. It is where the world's developers get answers, share knowledge & find jobs. I recommend that students [learn](http://stackoverflow.com/tour) how to use the SO as early in their careers as possible. 65 | -------------------------------------------------------------------------------- /git_guide.md: -------------------------------------------------------------------------------- 1 | ## Git Guide 2 | 3 | Below are the steps that I take to check the health, create/delete branches, push and pull down changes from Github. This stuff can definitely be tricky but you will be amazed at how much of it becomes habit as you do it more and more. 4 | 5 | __Where in the World is Carmen Sandiego (errrr… what folder are you in)?__ 6 | 7 | It important that you are in the right application (code project) folder on your local machine. 8 | 9 | Open Terminal and then navigate to the right folder: 10 | 11 | $ cd code/ 12 | 13 | or 14 | 15 | $ cd address-bloc 16 | 17 | Anytime you need to check where you are, run: 18 | 19 | $ pwd 20 | 21 | Anytime you need to see what is in your current folder: 22 | 23 | $ ls 24 | 25 | anytime you want to start over and go back to the base folder, run: 26 | 27 | $ cd 28 | 29 | To open Atom on a code project folder (aka the one you are currently in), run: 30 | 31 | $ atom . 32 | 33 | To see which branch you are on: 34 | 35 | $ git branch 36 | 37 | There is a * next to the one you are on. All of them are listed. 38 | 39 | To checkout to a new branch: 40 | 41 | $ git checkout -b 42 | 43 | To checkout (move) to a branch that already exists 44 | 45 | $ git checkout 46 | 47 | To delete a branch: 48 | 49 | $ git branch -D 50 | 51 | __Pushing and Pulling with Github Remotes__ 52 | 53 | _Push_ 54 | 55 | When you are in your app folder, check that you have a remote setup for Github by running 56 | 57 | $ git remote -v 58 | 59 | You should see something like: 60 | 61 | origin git@github.com:Brit200313/alliance.git (fetch) 62 | origin git@github.com:Brit200313/alliance.git (push) 63 | 64 | this means that when I 65 | 66 | $ git status 67 | $ git add . 68 | $ git commit -m ’Some really smart commit message’ 69 | $ git push origin 70 | 71 | I will be able to push code to Github successfully. 72 | 73 | Do you not see anything when you run “git remote -v”? Do you have the repo created on Github? If you are missing the remote, run this: 74 | 75 | $ git remote add origin https://github.com/kraniasar/.git 76 | 77 | _Pull_ 78 | 79 | Once I start collaborating with you on your code, I will push code up that you will then need to pull down (fact: keeping your local copy of code and your Github copy of code as close to the same as possible is an art and something you will be practicing a lot). 80 | 81 | So if I updated your “master” branch of your repo, you would then: 82 | 83 | $ git pull origin master 84 | 85 | You will see changes come down. 86 | 87 | _MERGE CONFLICTS_ 88 | 89 | When you pull and you see MERGE CONFLICTS, this means that I adjusted a file in a different way than how you changed it locally. No biggie! It just means that you need to open the file in Atom that it is complaining about. 90 | 91 | Remove any line from the file that looks like: 92 | 93 | <<<<<<< HEAD 94 | 95 | Adjust the code so that between the two branches, the code is right. Go ahead and commit the fixed file (you may have several) back to Github: 96 | 97 | $ git status 98 | $ git add . 99 | $ git commit -m ’Some really smart commit message’ 100 | $ git push origin 101 | 102 | __The Ultimate Guide to Checking Out Branches and Pushing to Github__ 103 | 104 | I included some of these skills above but I wanted to make it uber clear. 105 | 106 | $ cd 107 | $ git branch 108 | Which branch? Look for the * 109 | $ git pull origin 110 | $ git checkout -b 111 | Make some codez in Atom and save them. 112 | $ git status 113 | Are the files listed that are changed correct? 114 | $ git add . 115 | $ git commit -m’ Another smart commit message.’ 116 | $ git push 117 | You will get a message like this: 118 | 119 | fatal: The current branch hello has no upstream branch. 120 | To push the current branch and set the remote as upstream, use 121 | 122 | git push --set-upstream origin hello 123 | 124 | $ git push --set-upstream origin hello 125 | $ git checkout master 126 | $ git branch -D 127 | 128 | Hint: You almost never delete the “master” branch. 129 | 130 | ### Bloc Specific 131 | 132 | __Checkpoint - Starting with Master branch__ 133 | 134 | $ git checkout -b checkpoint-number 135 | ---complete work--- 136 | $ git push origin checkpoint-number 137 | $ git checkout master 138 | $ git merge checkpoint-number 139 | $ git push origin master 140 | 141 | __Assignment - Starting with Master branch__ 142 | 143 | $ git checkout -b assignment-number 144 | ---complete work--- 145 | $ git push origin assignment-number 146 | 147 | Do not merge assignments back in Master. 148 | --------------------------------------------------------------------------------