Here’s why you might want to do this:
This is the article I wish I had when I started software development with Ruby.
Bottom Line - Ask for feedback after your rejection. Find the common threads, fix them, and get better at the interview game.
Bottom Line - Don’t involve the reviewer prematurely in product management / feature iterations.
I use Pry on a daily basis while writing / debugging code. I want to show you how to go beyond a simple breakpoint with pry. I’ll show you how I use it to learn about unfamiliar code and how to debug code.
I can’t be the only one who occasionally tries to start
rails server and gets:
Bottom Line - Practice SQL by solving real problems.
Bottom Line - Don’t waste the reviewer’s time. Don’t make them over-think about things you should have provided ahead of time in the pull request description.
Forms are a huge part of a dynamic website. It’s through forms that you take user input and do something with it. It’s worth taking time to understand how to build different types of forms with rails.