Week One: Trials and Tech-bulations

Let summer classes begin! What better things do I have to do when the whole world is in lockdown? As a university student studying both history and computer science, I chose to take this course as digital history— a field I’ve only recently discovered in the past year— seems to encompass all of my interests. I’ve always been interested in digitization and how what I’ve learned studying computer science could be applied to my primary passion of history.

This first week of the course has been eventful for me, but in perhaps unanticipated ways. As someone who is relatively tech literate, I went through this unit’s “to-do list” relatively quick. I’ve never heard of Hypothes.is— I’m most excited to learn to work with this because it seems super useful for academic writing— but installation and use is very straightforward (despite me not having had a chance to properly use it as I haven’t felt the need to annotate anything… yet). Zotero is a tool I’ve added to my essay-writing-arsenal recently, at the beginning of the Fall 2019 semester! It’s easy to use with the UI acting and looking like a basic file manager (albeit, also looking a bit dated) and has proven to be most useful for in-class collaboration with friends; plus, the citation creation feature is such a timesaver! The greatest challenge that this week’s course content presented me with was creating a help request for a forced git error. What should be a simple task had me stumped, genuinely, because I fully understood the error message and couldn’t fathom how to fake ignorance for what, to me, was an obvious problem with a simple fix. I wrote the help request by attempting to separate myself from my previous knowledge of computer errors, pretending the words were gibberish and my mind was totally blank.

I ended up not being able to do that, so I tacked on a sentence at the end of the question that sort of reveals I know what’s wrong, but I’m not sure of how to find the resources to learn how to fix it.

Now, as you may have gathered, I’m fairly familiar with GitHub and by extension Git. From first year onward, version control is emphasized by professors in the computer science department, and the use of Git is taught as it’s the industry standard. Even beyond the classroom, both the Science Student Success Centre and Carleton Computer Science Society hold near weekly introductory workshops on the topic, the latter of which I often help organize as the Administrator for the CCSS. HOWEVER… I’ve always felt like a bit of a sham. I know how to use GitHub— sure, I can upload files using the UI, modify them, etc— but Git has always confused me. If I wanted to use it, I’ve always had to ask friends for help due to the amount of online information on it being immense and overwhelming. Because I had yet to be challenged by this week’s course work, I decided that my struggle shall be no more! And so this motivation led to my two self-imposed challenges of the week.

GitHub: Straight from the Command Line

My first self-imposed challenge for this course is one that will span the length of these next 6 weeks. Rather than using GitHub to create my repositories and files, I will only use it to create my initial repository, and from there exclusively add and update via the command line (or rather, terminal for me because I’m using macOS). I started this venture by creating my week-one repo, and then attempting to add my notes file that was stored in a local folder, which would be the remote source for this repo. Luckily, if you create a repository that is NOT initialized with a README, GitHub immediately shows you a nifty guide on how to do that via your command line. I, of course, initialized with a README and thus did not get said nifty guide convineiently presented to me. On my mission towards Git-independence, I performed a quick Google search, sifted through all of the excess, and sure enough found exactly what I needed! My repo was now one with my local folder, and with this success under my belt, I quickly went on to do the rest of this week’s work so I had actually had something to put in my notes file. Once finished, it was finally time to face the primary reason I’m afraid of Git: updating the repository. I again turned to Google, and was subjected to all my usual confusions; do I use git add? or git merge? What and where am I git push -ing?! For a popular system with so much documentation, there are so few simple, ordered guides that explain both the commands AND give order— even the common “quick guides” only give context to one individual command at a time, or if a guide does give step-by-step instruction, it often contradicts another available guide on how to do the same action! Google gave me many, many results, but for the direct explanation I sought, I caved and hopped into a Discord call with a friend who studies computer science and regularly uses Git; though, unlike previous times Git has been explained to me, this time I made step by step notes on the instruction I received, and in the end successfully updated my file! This got me confident, and wanting to know even more. The reason I wanted to learn to use Git is because of how useful it is for version control, which is arguably more important for programming-type projects over the markdown texts that I’m primarily doing for this course. So I thought to myself, could I integrate some kind of larger coding project with this course that would force me to consistently update using Git? And that’s when I decided to build a website.

This Website: The One You’re on Right Now.

On my first run of reading this week’s lesson on Setting up your GitHub I disregarded the “Going Further” section. I didn’t know how long the other lessons would take and thought I should complete those first, so in that moment I had no desire to “go further”. But once I quickly finished the rest of the work and thought of my second self-imposed challenge, building a simple website to host my course reflections and perhaps other similar activities that may come up later, I went back to see what going further meant, and sure enough, it was pointer I needed to start creating. With the initial direction of Dr. Graham, I began to further look into static site frameworks.

I knew I wanted to use GitHub Pages to host over Netlify; controversial, I know, but I’m already dedicated to working from the command line so I don’t need the drag/drop capabilities of Netlify, and I didn’t feel a need for a custom domain so it was simply most convenient to just go into the site’s repo and select the single option that immediately enables GitHub Pages and deploys the project. The necessity for effort came when I began building the website itself— the static site framework that works best with GitHub Pages is Jekyll, a Ruby-based static site generator. I had never worked with Ruby before, and Jekyll being a Ruby gem meant that I needed to install Ruby. I used Homebrew to install Ruby, and apparently it was good to go, great! But I was wrong. The version installed was a version from 2013 that would not support Jekyll, but in thinking about it, the command brew install ruby would only install the latest version of Ruby that was stable for one’s OS. I was still running macOS Sierra, meaning I was behind three major macOS updates, so in that moment this was the obvious solution to my problem— it was finally time for me update.

I puttered around the house while the new OS installed for an hour, and once my computer was freshly up-to-date and alive again, I typed the command to install Ruby. It still gave me the 2013 version. Huh. Cut to me googling my issues and I discover this is a common issue with macOS, and that I needed to download a separate manager, RVM, just for Ruby installs in order to download and set the latest version. Despite its somewhat crypt install process, I get everything set up with RVM, go to install the latest version of Ruby through it, but right at the end of the process the install crashes with an error indicating it could not run the configuration file. I skipped the very first step in Jekyll’s guide, xcode-select --install, which I assumed was just to install Xcode, the dedicated macOS IDE, and I just use Atom so why would I need Xcode? Turns out that install is actually to install the command line tools needed to run Ruby-based programs. I ran the command and every step after worked perfectly, my own hubris in assuming I understood the command line became my fatal flaw. At least it forced me to update my computer?

Despite this tragedy, using Jekyll to build my website after went swimmingly, with its excellent documentation and specified code structure. I wanted to ensure I didn’t design anything too complex, so I used this theme by Paul Le as a base for my site and heavily modified it to my liking from there. I decided to try using Sass where I would typically use CSS just to try something new, and then created a basic 5-colour palette that I could consistently follow throughout the website. Now all I have to do is push this post to my repo and I can submit my work!

The Historian’s Digital Experience

Working in GitHub, in the command line, on building a website, with all the gradual successes and numerous failures, has really made me reflect on the trials that a present day digital historian may face. Prior to all of this, having only vague knowledge on both this course and the field itself, digital history was what I perceived to be a movement towards digitizing history and its associated physical documents, thus removing it from its exclusive, archival-centric past and opening access for all to study and reinterpret the past. After reading the suggested material for this week, I found I was correct in guessing the intention of digital history but not the end result. Of course, nothing works out perfectly, and what began as an open source movement was hampered by established systems within publishing, law, and academia. For example, journals and articles are now mostly digital publications, yet still either behind a paywall or restricted to those who are members of an academic institution. Those who can’t afford either option are prevented from accessing this valuable information they could use to further educate themselves.

Yet as discussed in the article published by AHR Open Review, what is digitized and made accessible is a powerful tool for voices traditionally silenced by the archive, generating numerous online, curated archives bringing the histories of the marginalized into view. But in spite of this, I feel there’s another layer of inaccessibility to digital history, and that is the fact that it is digital. Tech literacy is prevalent in the present, but at a basic level— many know how to navigate a computer, search the web, and use GUI based applications, but few a familiar with the command line or simple programming. Anecdotally, based on my experiences interacting with my history professors and many peers who also study history in university, when the topic of computers or technology comes up, friends will balk at the concept of learning even basic programming, ask me if I’m hacking when I navigate files via the command line (and if I try to explain insist that there’s no point because they’ll never understand what I’m doing), and many of my lectures have begun with a professor stating that technology is something of evil, jokingly berating their computer as it behaves in a way that is unexpected. While light-hearted on the surface, there seems to be this mentality that persists in the field of history in which those who study it are not or cannot be knowledgable in something as modern as the digital. Historians go to the archives or read books for knowledge; they deal in the physical, not with something as unreliable or intangible as technology. Digital history cannot be fully realized in all of its potential until this mindset is gone, as this mindset undermines digital resources and pushes those with the potential to create them away from the web as a platform for their research. A major block in generating open access history is the academia, with a default categorization of the historian as technologically illiterate that is continously perpetuated in this environment. This limits the field of history fundamentally, as digitization is slowed and the study of history is dated in our modern, tech-based world. Once the field of history can move past this “I can’t” frame of mind, the digital history can fully be embraced, taught, and revolutionize how the field is studied and publically presented.

This element of digital history excites me, because it’s a field that creates historians who do interact with the digital in a meaningful way— but I want all history to have an accessible, digital form, to the point where digital history is essentially just, history. No historian is truly incapable of understanding technology, and all can harness it to their advantage in some way. No one just “understands” technology, just like no one immediately understand historical theory; we all start learning somewhere, and in terms of a basic skill like learning to create a simple static site like this one that could enrich and disseminate the research a person has dedicated their life to to a wider audience, google (not google scholar) or an open access course like this one is a great place to start.