For my CLI project, I drew inspiration from my DC surroundings to make CongressCLI, a simple command line program that scrapes senators’ names from senate.gov and displays them by state. It also gives users the option to display contact information for their senators. Below are the hardest four things about the project.
My recommendation: do it the way the Learn curriculum teaches, in pry:
- load your webpage with open-url
- make a new nokogiri object
- place a binding.pry after to play around with .css
liberally to avoid dealing with loooong strings of XML
Git seemed abstract and hard to grasp to me at first.
I started thinking in analogy, comparing it to something I’m very familiar with - editing a Google Doc with multiple users.
- The master repository with committed changes is the original text of the Google Doc.
- You initialize this capability with
git init. To “turn on” tracked changes for all your doc(s), use
git add ..
- The changes you’re committing are the colorful font of your edits. (
Git commit -am “string”commits all changes with message - kind of like a Google Doc edit with a comment.)
- The underlying document has not changed when you track your changes - you have to accept the edits to make them permanent. Pushing is the equivalent of accepting those changes (
git push -u origin master).
Having a cheat sheet of helpful commands while using Git was very helpful. Some of the commands I saved from the lessons for quick reference are below:
git clone your-copied-github-url- creates local copy of forked GitHub repo
mkdir- new directory
touch- new file
echo “string” > file- adds string to file (useful for readme/logs)
ls- lists all files
git init- initializes new git repository in current directory
git status– shows status of commits (if everything is committed & pushed to master repo, it will be ‘clean’)
git add- tells git to track file
git add .- tells git to track entire current directory
git commit -m “string”- commits one change with a message
git commit -am “string”- commits all changes with a message
git rm -r filename- delete file
git push -u origin master- push code to repository
Listening to my own voice on the recording
If you’re using a Mac, it turns out recording a voiceover + walkthrough of your gem is incredibly easy! But listening to your own voice can be harder…
Simple screen recording with voice:
- Open QuickTime Player
- Click File > New Screen Recording
- Click the mini arrow in the menu that pops up to select your microphone input and mouse settings
So in addition to working on my coding, after watching my walkthrough, I’m going to work on removing “um” from my vocabulary.
Finding long blocks of time for in-depth projects like this was another hard part of the project. Although those blocks are scarce, using them is so effective – I did the bulk of my CLI in one focused day. I love this Cal Newport book on the importance of focused, deep work, and I’ve found it to apply to my programming process.
The biggest delay of the project was this blog post itself - there are no specs or suggestions, so it’s harder to get started! Test based development gives me a framework so that I rarely have long stalls during which I run out of ideas.