Accompanying videos for your first 2 weeks of Makers Academy.
A word of caution before you read on. DO NOT replace writing code with watching videos. Personally, I believe that actually writing code is far more important in learning to code than almost anything else. You will write code, it will fail, and you will learn from it — don’t let the fact that you don’t know how to write perfect code stop you from trying, and don’t wait until you understand everything about what you’re learning to code to start trying to code it.
At Makers Academy, we cover TDD and Ruby in the first couple of weeks. It’s a tough experience. You’re introduced to a lot of new concepts and it can feel very overwhelming. The resources given are mainly text based, and while they’re comprehensive I found some accompanying videos on the topics we were trying to pound into our brains were very useful. Here’s a list of ones I’d recommend.
Please note — they’re all Upcase. You need a subscription ($9 a month just for the videos, link here). Thoughtbot have very kindly given Makers students a free trial, so get in touch with someone on the course to get hold of details of how to access.
Testing
Four phases of testing. This video gave me a really clear technique of how to structure a test. Staring at a blank test and not knowing where to start sucks, and I still use their setup/exercise/verify steps to overcome this mental hurdle.
Outside in testing. This will help explain why writing the feature tests before your unit tests is beneficial.
Isolated tests. Struggling to understand how to test in isolation? Check out this video and this one too.
Stubs, Mocks, Spies, and Fakes. This video MASSIVELY helped me understand how to isolate my tests and what the hell each of these things mean.
Integration/feature tests vs Unit tests. If you’re not sure what the difference between a Unit test and a feature/integration test is, check this out.
Refactoring
Live refactoring. I found it so beneficial to see people refactor live. These guys do a great job of talking through what’s going on in their mind as they see the code, and what’s triggering their decision to refactor part of their code. Here, and here.
3 major techniques that you’ll be regularly using when refactoring your code: Moving methods.
Extracting methods.
Extracting classes.
SOLID principles for making code that’s easy to change
S-ingle responsibility principle
O-pen/closed principle
L-iskov Substitution Principle
I-nterface Segregation Principle
D-ependency Inversion principle
I hope these help you as much as they’ve helped me!
