A big thing for me as I make the transition away from my former life as an English and writing instructor is to make sense of coding by relating it to familiar concepts by means of analogy.

So a big thing in Ruby is methods. Thus far, I’ve been thinking about methods as if they were verbs in English — just like verbs describe actions, so methods let us act upon and DO things with objects.

Now, a particular type of object called Enumerables has caused me some grief this past week, as it seems you can call upon an Enumerable an infinite list of methods. What are some examples of Enumerables? Well, basically any data structure that holds data and is therefore useful in Ruby — two common ones being arrays and hashes. And thanks to David Grayson’s Las Vegas Ruby Group presentation, “Ruby’s Enumerable Module”, I now know that ranges, sets, String#chars, and String#bytes are also considered Enumerables.

Grayson’s deck is pretty straightforward — no fluff, mostly examples of how an Enumerable might respond to or behave under a method. But this is great! Sometimes you get tired of consulting this and it’s nice to have found another source that really emphasizes what the ‘verbs’, i.e methods, do. Because let’s face it. Without Enumerables and their corresponding methods, there’s just… really not much else to do in Ruby. If you’re not acting upon data by transforming/accessing/re-organizing/passing it around from one part of your program to another, then what are you doing? Right. And the only way you’re going to accomplish any of the above is by taking advantage of all of Ruby’s insane methods.

So the most prevalent Enumerable method that I’d encountered way early on in my Ruby journey — dare I say the most commonplace or well-known method — is:

.each

Up until the end of last week, I tried to solve all my iteration problems using .each. And while the method does encompass the very spirit of iteration (how much more literal can it get than telling your program, “I want you to consider each thing and do what I say to it”???), relying on it for every scenario is like having one verb in your vocabulary and running around insisting that it should convey exactly what you mean, regardless of what it is you’re trying to say (i.e “play!” to play, “play!” to eat, “play!” to sleep, “play!” to go home, “play!” to go to bed — WHY WON’T ANYONE DO WHAT I ASK?!). It’d be ludicrous.

So I expanded my Ruby vocabulary the tiniest bit and discovered a few more Enumerable iterators that are SUPER useful, including:

.collect or .map (they do the same thing)
and
.select

(to grasp how useful .select is, just take a look at this Anagram exercise I solved in class yesterday)

Finally, in the wee hours of this morning/night, Grayson has introduced me to a few more iterators and methods that seem potentially very useful (and I can’t wait to try them out tomorrow):

.collect_concat
.cycle
and
.group_by

The last one, .group_by, I’m sure I’ve come across before but probably forgot existed. Just being honest.

KEY TAKEAWAYS

1. Methods are like verbs… you need to have a decent vocabulary of them, or else you’ll be limited in how you can express yourself
2. Enumerables are pretty important in Ruby; they store data
3. Methods are also pretty important in Ruby; they let you access and manipulate the data stored in the Enumerables
4. Some cool iterators and methods you can call on Enumerables include:
   .each
.collect or .map (they do the same thing)
   .select
.collect_concat
.cycle
.group_by

I meant to write this post last week, when I had my first Git/GitHub breakthrough. In my first post — after Day 2 at Flatiron — I bemoaned the fact that everything I’d attempted to absorb about Git and Github had, by the end of the day, turned into unpalatable git soup. A week later, after enough exposure and repetition (and causing one too many merge conflicts), I was able to strain some method out of the git soup-madness.

Let’s start by establishing a key concept: Git and GitHub ARE NOT THE SAME THING.

They’re not??? But, like, programmers refer to them (seemingly) interchangeably!

Nope. Still not the same. They work hand in hand, but this doesn’t equate to…. sameness.

SO WHAT IS GIT?

Git can seem like total madness for a number of reasons, not the least of which because… well, GitHub’s sheer existence. The latter has added a whole slew of very niche terminology to an already-extensive list of GIT-specific terminology: i.e, there’s more shit to memorize. Anyway, you can think of Git as a really awesome version-control software. You download it. It lives locally on your computer. You run it from your terminal. You might be typing some Git-ish commands that look like this, from your command line:

git init
git add .
git commmit -m "some witty message here"

If you are, then you’re using Git — NOT GitHub.

And what exactly, by the way, is “version-control software”? It’s basically just a handy program you install on your computer – just like when you download and install cool things like Skype – except you install Git from your command line. Which makes you really cool. Oh, and what it does: a million things. But two fundamental ideas are that:

1) Git allows you to save different “versions” of your work as you go — via adds and commits. As long as you’ve installed Git on your computer and you do a git init in whatever directory you’ll be doing your work, you can start saving versions of your work. And “work” really means anything; it could be Photoshop edits, essay drafts, spreadsheet modifications, you name it. It just so happens that if you’re a programmer, you’ll mostly be using Git to keep track of all your versions of code.

2) Git lets you create and work on something called ‘branches’, which are basically parallel universes that you can switch back and forth out of interchangeably — via git checkout <branch_name here>. If that’s still confusing to you, imagine if you could make as many copies as you wanted of your EXISTENCE, i.e seven different parallel universes, and in each of them, you can run around and live out a different version of your life that you’ve ever dreamed. When you feel like one particular universe has yielded the perfect outcome (you’ve become the next Jay-Z, met the man of your dreams, have been elected President of the United States), you can throw away the other six and decide “I ONLY WANT TO KEEP THE ONE WHERE I BECOME PRESIDENT.” That’s kind of how branches work. You get to make and work in as many as you want, and when you write code that you’re happy with in any one of them, you can say, “THIS IS THE BRANCH I WANT TO KEEP” and throw the others away.

Then we get into merging and pushing and some advanced Git topics that I’ll chronicle in future posts (when I’ve actually wrapped my head around them). But this poses a natural segueway into GitHub.

COOL. NOW WHAT’S GITHUB?

Remember how I said Git lives locally on your computer? Well, GitHub is the exact opposite: it lives remotely, on the Internet. That’s right — as its name would suggest, GitHub is an online ‘hub’ that some really smart dudes built so that programmers could share their code remotely and collaborate on projects at the same time. It’s kind of like the flashstick/Dropbox analogy — sure, the flashstick was small and compact and mostly useful, but what if you wanted to access everything on your flashstick remotely? On the Internet? Especially if, like, you didn’t have your flashstick with you?? Sorry, no can do. Until Dropbox came along! Suddenly, you could access ALL your files from any computer, as long as you had an Internet connection and as long as you’d explicitly added those files to Dropbox! Similarly, I like to think that GitHub is to Git what Dropbox is to the flashstick (yes, I know this is an oversimplification but if you just think about the remote-access part of the analogy, it works).

So if you’ve got an Internet browser open, and you’re typing “www.github.com” and hit enter, and you can see the Octocat mascot, you’re using GitHub — NOT Git. And why is this distinction so important? Well, that’s like asking why it’s important to understand that the files on your computer won’t be accessible remotely unless you MAKE them ‘remote’ somehow, say, by uploading them to Dropbox. As long as you understand that GitHub is a remote entity to which you’re ‘pushing’ (i.e uploading) stuff that would otherwise only exist locally, you’re in good shape.

This will save you a lot of confusion and heartache down the road when you’re wondering why stuff you’re adding and committing locally isn’t magically appearing online on GitHub (chances are, you did a git init locally first then forgot to create a ‘pathway’ between your computer and GitHub via git remote add origin <some GitHub URL>).

Anyway, I’ll be doing more Git and GitHub posts down the road because I don’t think any existing manuals on the Internet have really done an excellent job at illuminating how they work together (or explaining what they are, for that matter, hence this blog post). Even more egregious, in my opinion, is the lack of sensible visuals (most Git diagrams suck and have only confused me more) and the dearth in helpful analogies — so I’ll try to provide a little of both.

KEY TAKEAWAYS

1. Git lives locally, on your computer
2. GitHub lives remotely, on the Internet
3. You can store and access your work online, on GitHub, but only if you EXPLICITLY SEND IT THERE — i.e via a git push
4. What you do locally on your computer doesn’t just magically appear remotely online; you need to create the pathways and make the explicit commands

I completed day two at the Flatiron School today. My head is spinning with all the new concepts and terminology I’ve been trying to absorb from the last 48 hours — deploying, raking, branching, rebasing, adding, committing, and merging. Everything is sort of merging into git-soup, at the moment.

But I learned some handy keyboard shortcuts that I can wrap my head… err, fingers around. Like command + tab to navigate around my open applications. And command + space to summon Spotlight. It sounds silly, but I didn’t used to know these things. I’ve learned more about my computer in the last two days than I ever have.

Goodbye, track pad?

Hello world.