Burrowing

I’m always worried that when the time comes to type, I won’t be able to summon the right incantation. I think this fear goes all the way back to being 8 years old and sitting down in front of my dad’s computer running MS-DOS, trying desperately to remember what words would bring Mario Teaches Typing onto the screen.

Today, intent on incrementally improving my programming skills, I decided to try just recording obstacles as they cropped up and then documenting the ways I got around them. This was good because it gave me an outlet for frustration while also encouraging me to verbalize exactly what was going wrong. And by putting the problem into words, promising search terms suddenly started materializing before my eyes. “I’ve already forked the project, so how to sync?” became “github fork out of sync,” which led me to GitHub’s Fork a Repo help page…which was exactly what I needed.

So, for posterity and perhaps your curiosity, here are two of the hurdles I ran into today and how I eventually got over them.

My plan for the afternoon was to poke around Erik’s Twitter Command-Line Interface project. After a few hours looking over his shoulder as he worked on it, I felt like I had a good grasp of its basic structure and capabilities—plus, it’s always more fun to poke around projects when you get the point.

What I’d forgotten was I’d already forked the project on GitHub in order to make a few copy-edits to the README. Okay, wait up, what do all the words in that sentence mean?

  • GitHub is a wonderful website geared toward “social coding.” On it, you can publicly post code you’ve written and solicit input and feedback from other people who’d like to use that code.
  • Forking according to GitHub: “At some point you may find yourself wanting to contribute to someone else’s project, or would like to use someone’s project as the starting point for your own. This is known as ‘forking.’”
  • A README file is kind of like the “about” page for a piece of software. On GitHub, the README automatically shows up on the project’s profile page. It’s a file in the project’s directory (or “folder”) like all the rest, and can therefore be forked.

When Erik asked in November if I’d be willing to copy-edit an early version of the README for the project, instead of just copy-pasting the words into an email and editing them from there, I forked the whole project and then made edits to the README file itself. Then, I submitted a pull request to Erik, which he was able to review and then automatically integrate (or “merge”) into his original version of the project. You can see the edits I suggested here.

What did this mean for me today? Well, step one in my original plan for the day was “fork the project so you can poke around and make changes to your heart’s content.” Except it was already forked, but also desperately out of date: my copy dated back to November, and Erik’s been steadily improving the project ever since—he’s committed changes to the project almost every day in December so far.

So the first hurdle I faced was: “pull in Erik’s latest changes so that you’re working on an up-to-date copy of the project.” This sent me down the path of posing the problem to myself, surfacing the keywords I needed, searching Google, and finding the right GitHub help page, Fork a Repo. There I learned that I would need to identify Erik’s original project as the parent of my forked version, fetch the changes he’d made, and then merge them into my fork.

Those commands may look hopelessly mysterious or pleasantly familiar to you. Every one of them was news to me a few hours ago, but now I feel some affection toward the curt, finicky phrases because they so compactly helped me solve a seemingly formidable task.

My next hurdle felt more manageable. Playing around with the the Twitter Command-Line interface, I found what I thought were two bugs. I wanted to give Erik a heads-up about them using GitHub’s built-in issue tracker, but in order to document the bugs, I needed to include code snippets in the bug descriptions. For those code snippets to actually resemble code, I’d need to format them specially.

When you type descriptions into GitHub’s issue tracker, you’re writing in what appears to be a regular old text input box. Yet it has secret powers: the text field automatically understands and displays text formatted with GitHub-Flavored Markdown! According to John Gruber’s explanation of regular-old Markdown, Markdown is “a plain-text formatting syntax…the idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.” GitHub-Flavored Markdown adds some GitHub pizzazz to Gruber’s original project. But in both, the way to format code is the same: you surround the code snippet with backticks. (AKA grave accents, found on the same key as the tilde, right below the escape key.) So typing `t timeline sferik` in the GitHub issue tracker input field will display the text instead as t timeline sferik. It’s very handy.

Writing this post, I’ve realized that every sentence is a rabbit-hole. If you’re willing to take the plunge, you can excavate layer after layer of meaning, which brings its own kind of satisfaction. But if you try to stay above-ground, steadily progressing on the task at hand, you may reach your surface goal without understanding how you got there—short-circuiting the larger goal of learning. I’m grateful for this break between semesters, the chance to burrow in.

  1. hoover-waschmaschine-mk-7160 reblogged this from dianakimball
  2. bandschleifer-black-decker reblogged this from dianakimball and added:
    m
  3. sony-ericsson-w995-prix reblogged this from dianakimball
  4. trova-prezzi-samsung-galaxy-s reblogged this from dianakimball
  5. wie-wird-man-hundetrainer reblogged this from dianakimball
  6. staubsauger-testsieger-2012 reblogged this from dianakimball
  7. druckerpatronen-epson-t0715 reblogged this from dianakimball
  8. bisceglie said: reading these notes is so delightful.
  9. dianakimball posted this