I finally finished the Ruby tracks in the pre-course work, and I’ve also completed the Git tracks as well, which means – I’ve finished all of my pre-course work!
So, does this mean I am a Command Line, HTML, CSS, Ruby and Git expert!?!?!? Yea… not even close. In fact, having spent the last week learning Ruby, I feel like I’ve forgotten a lot of Unix, HTML and CSS stuff, but have no fear! I have plenty of time to go back and review, which I’m very grateful for as I feel like it’s not only necessary, but I’m excited to do some more tutorials in the early stuff as I hope it will be a lot easier this time around. When I get back to reviewing Ruby, hopefully I can clarify some things I am still unsure about, (attr_accessor/reader, etc., ActiveSupport::Concern, differences between blocks, procs, lambdas, hashes, & arrays, when to use classes, and how to cope with instance variables, etc. etc. etc.) in addition to just refreshing my memory on punctuation, capitalization and format use.
So I’m at the end of this first hurdle and I’m actually really looking forward to going over it all again – good sign! Plus, I’ve started dreaming in code in the most logical ways, which is very, very odd. I rationalize my dream-decisions and boss Stu around using dream-instructions all with/in code! Excellent.
But before I celebrate, let me just go over what I learned in Git today. I’m skipping what I learned in Ruby because I learned SO much that it would be silly to try to revisit and explain it all. Plus, as I said, I need to still clarify a lot of aspects of it, so I think it’s best to leave a Ruby wrap-up for the final pre-course review.
So, let me go over Git. Git is what is known as version control. Skillcrush has a great explanation for what version control is here, but essentially, version control is the way that you literally control versions of your code. We need this because with coding, you often get a lot of people working on one project at once, either on the same files, or on multiple files (yes, projects can be made up of multiple files of code that are all linked together). So version control, sort of like Google Docs, allows multiple people to edit things all at once, and successfully merge these edits together into a new updated version of your code (using “commits”, or essentially new snapshots of the updated code).
Another reason this is really useful, even if you’re the only person working on the code, is rather obvious: you are just creating back-ups. This way, if you write a whole bunch of code and then accidentally lose it, you can go back to the last commit and retrieve what you had before the erasure. Or, if you just change your mind about something, you can go back to a previous commit (any previous commit) as well, to start working from the last time you were happy with the project as it was.
I find it really useful to think of this in terms of a time machine in the same way that your Mac will back-up all of your data for you using Time Machine. It’s really as simple as doing stuff on your computer (making changes to the code), saving these on your computer (what in Git, is comparable to “staging”, or preparing to be backed up), and then backing it up to time-machine (or “commit”ting to your timeline).
So this all seems really straightforward so far, and it is. The CodeSchool tutorial on Git (Git Real) was the best one I’ve done so far (I found the CSS one a bit poor, and the Ruby Bits one was, at times, incredibly confusing and poorly explained). They start you off with a Try Git course, which anyone even without a CodeSchool account can try out (go for it!). It is essentially like a Try Ruby for Git, but a tutorial that I found much clearer. Then I did the actual course, Git Real. You essentially learn all of the basic commands for moving around within your timeline, making changes, staging things, and then committing them. But more importantly, you learn how to use Git with remote web-based hosting services, like GitHub, which is basically somewhere to which you can upload all of your changes and commits, as an external back-up, and as an easy place to share them with your coworkers. Sort of like a Drop-Box for code projects.
So we learned how to “push” our changes to GitHub, and “pull” or “fetch” updated versions off of GitHub, to our local repository (essentially, where we are working on them on our computer… our “local” place for our code project, as opposed to our “remote” one, which is the one on GitHub), to then merge with our existing code, or further update it. It’s all very clever, and while I can’t say I 100% understand how to do everything I learned, I think I get this the most out of everything I’ve learned so far, which is very good as it is crucial to writing and working with professional, error-free code.
So that is Git, and I will be trying to do a bit more on my own today, and maybe even going a bit further and learning Git Real 2, a follow-up and more advanced tutorial, to see how far I can push my knowledge.
But really, the next step is revision. I realize that I need to have a really solid foundation of all of this beginner information, in order to properly build on it once the course begins, so I’m hoping I can garner that knowledge over the next two weeks. I am off to America this Thursday for a friend’s wedding in NYC, some much needed family and old-friend reunions in NJ, and a restful family retreat in Maine. Stu will be joining me as well, of course, for a much needed, and well deserved, rest from lawyering. Hopefully amidst all the wonderful food, nostalgia, pool/porch time and gossipping I can find time every day to code, revise, and learn a bit more before returning in June. We’ll call it the calm before the storm… wish me luck!