Learning to Accept It
Considering that the main hurdle I had to surpass before I could get to work on CSA work was related to tools, I wasn’t very inclined to say I love my tools during the first few days. I couldn’t get my local server up and, since I had forked the repository without creating a separate repo to host the GitHub Pages domain through, I basically had a nonexistent page. When I went on the search for solutions, though, I began to see the light.
bundler: command not found: 'jekyll'
My personal experience with the errors was most often related to my system’s attempts to track down locations of gems in different places at the same time. After searching around on the internet, I found that I could get started using rbenv.
Finding Success
I researched how to use rbenv to manage my Ruby environment. Since jekyll was having a bundler problem because it somehow ended up in Ruby 2.7.0, I tried shifting to Ruby 2.7.0 locally with rbenv local 2.7.0. Most often, however, even after once again running ruby -v, it would still say I was in the wrong environment. At some point, running rbenv rehash and reopening the terminal did the trick, but that wasn’t the end.
I ended up using bundle list to see which files I had. After running bundle install, I was repeatedly told that I was missing commonmarker, racc and something else, so it claimed to download it before saying the task was finished. I figured that they must not be downloading properly for some reason so I tried installing them individually, which revealed that the problem may have been with my Bundler version.
Long story short, by learning to understand the versions and locations of the various tools we used for setup, I came to love them. Now, here’s a whole section dedicated to why I loved all of these different tools.
Love Stories
I discuss the many things I’ve worked with so far and why I love them so dearly below.
GitHub
GitHub is arguably the best thing that ever happened to coders. Not specifically to computer science, but to the people behind it. I can’t imagine how difficult it would be to work together with people on shared projects or store my progress on a bulky, complicated repository without the extremely easy-to-use and effective systems of GitHub. Collaboration has been the cornerstone of each trimester, and without GitHub, we would really be at a loss.
GitHub Pages
This is sort of a subset of GitHub itself, but GitHub pages has been such a boon because, the moment I create the repository, there’s a runtime link ready for me to look at. It coming styled and everything made the idea of creating things on it more inviting, since you have things to work with, but also a framework that could be drastically altered for your own personal interests. That’s basically what I’m in the process of doing with this site now.
Homebrew
Homebrew is the MVP G.O.A.T. of MacOS package and software installation. I’ve hardly ever had a problem with brew installations aside from the occasional brew update or brew uninstall -> reinstall [thing]. It also lets me actively manage packages and environments without much hassle, too.
Docker
When I was having trouble with Ruby last week, I kept thinking about how I could figure out how to make a Dockerfile and just run it through Docker. It makes deployment so much more manageable, and messing with the Dockerfile when we were working with AWS made solving errors so much more efficient. And speaking of AWS…
AWS
I won’t go on a whole rant about it, but we couldn’t have deployed without it. AWS was the backbone of all of my previous projects.
Python
Python was the perfect start to learning code for me. Lacking the syntactical asks of even easy languages like JavaScript, it was super easy to jump right into and made me eager to learn more. For a class dedicated to teaching the principles of computer science, it certainly help illustrate the foundations of what carries over between languages.
Ruby, Bundler and Jekyll
These have worked hand-in-hand, especially just in the last week, to put together and run sites like this. I struggled at first, but I soon came to realize that, as long as I properly managed my versions and environments, all of the errors that came up were manageable. Bundler is such an incredible help in that it installs all of the gems you could need in just one command, no confusion or anything. I’ve also found myself using --verbose with bundle install to solve problems I was having with Jekyll. And speaking of Jekyll, it’s been pretty much inseparable from all of the projects I’ve done in computer science here.
rbenv
I think I owe rbenv money. It saved my site (and my grades, if you think about it) by making it so easy to manage my horribly messy web of Ruby versions and environments. It let me change the local and global ruby environments to those that will make my life a whole lot easier in the future, and even when they continue to give me trouble (which they did recently), rbenv is so easy to use.
Honorable Mention: Postman
I see Postman whenever I restart my computer and it always reminds me of how helpful it was when I was first dealing with APIs and backend databases. I look forward to making more use of it this year.
Installation Hacks
I answered the Installation Hacks questions below.
- Take note and describe the type of shell commands that you are using through Terminal in this installation procedure.
- wsl, cd, git, apt, brew, …
See Bash Kernel work for all sorts of stuff like that, below this in the Week 0 notebook or on the separate lesson notes.
- In the Development process, developers use Version control. Annotate in notes what you have learned about Version Control while doing this setup process.
Version control is tracking changes to code and documents over time. This is how coders (like us :D) avoid losing data or writing over each others’ work. Dependency management is a cornerstone of version control that is very present throughout the tools setup process.
- Where are the files from GitHub placed on your local machine? How do you navigate to those files?
GitHub files are stored in my VSCode directory under their own subdirectories. I’m able to navigate those files by looking at what I have in my VSCode directory and selecting (by name) which GitHub project I’d like to work on with code [name]. I could use ls to list out all of the repositories in the VSCode directory.
- Where are the files placed in the GitHub Cloud? How do you navigate to those files?
On the GitHub servers, you can find files by searching for them if you have their name of the username of the person who created it (assuming it isn’t a private project). You can navigate these files by clicking through the repository’s file tree or by searching for individual files using the site’s build-in search features.
- Put into words the difference between viewing GitHub Pages running on localhost machine versus running on a deployed server.
- What is the localhost URL for your distribution? Can anyone else see it?
- What is the GitHub Pages URL for your distribution? Can anyone else see it?
When you’re viewing GitHub Pages on a localhost machine, you’re seeing the present, working state of the site as it is reflected in VSCode. Only you can see it, since it’s local only to your device (0.0.0.0:4200/drewtwo/). The GitHub Pages URL, on the other hand, specifically sees what has been committed and synced to the GitHub Pages repository on the GitHub servers (drewreed2005.github.io/drewtwo).