DEV Community: Donna Hogan

Reading The Fancy Manual: Documentation in Bash

Donna Hogan — Sun, 03 May 2020 16:40:51 +0000

Good afternoon quaranteam! I have a Sunday afternoon coffee question:

To read documentation for a command, such as ls in Bash in macOS, we use man ls, but in Linux we use ls --help (or ls -h).
Both macOS and Linux are built on Unix, so...

What accounts for this difference in the way we access documentation?
What other subtle differences do you think a beginner should be aware of?

My first year as a dev

Donna Hogan — Wed, 04 Mar 2020 18:55:30 +0000

I recently remembered that my work-aversary was about a month ago.

The general advice is that junior devs shouldn't start out working remotely. Not only are most companies not eager to hire for that level in the first place, juniors need mentorship, which can be challenging in a distributed team.
And so while I was thrilled to be hired with my team as a remote contributor, I kept that lurking fear all year (I'm sure impostor syndrome contributed to this too).
The work anniversary lead me to reflect on the year that had past, so I conducted my own sort of informal retrospective on what I've learned and accomplished, where I'd like to improve, and goals.
This would have been a great exercise to do at the 6-month point, and I definitely encourage all new devs to do the same.
While I'm here recommending things, this Coursera course "Learning How To Learn" has taught me a few new things that are already changing the way I learn - which, as we know, is crucial for being a successful dev.

Wins

Learned how to write browser automation tests, including one involving a tricky race-condition that I wrote about in a pretentiously-titled blog post.
- Ironically, I feel more comfortable writing these kinds of tests than writing unit tests. I would like to improve on this in the coming year.
Further developed my React/Router/Redux skills.
- Even started ejecting React apps that were initialized with Create React App in order to customize webpack.
I got a little better at manipulating the contents of a webpack config, but I'm still nervous about it, and would like to be better at this in the future. And perhaps make my own React boilerplate rather than using CRA.
Became more fluent in Git/Github and integration with VSCode.
Dabbled in Kibana and PowerBI
Learned what AWS Lambdas are, and wrote my first!
- Related to this, learned about virtual environments for Python projects.
My first Docker-ized web app!
Asked for something, and it was fine!
Wrote my first, very basic chatbot (using Botkit, that uses some simple NLP to make searches for you and reports back some answers.
- Made a tiny contribution to its library.💛
Made use of continuing education resources like egghead.io, Udemy, YouTube, PluralSight, FreeCodeCamp, books, Slack/Discourse communities, Coursera, and lots of Podcasts.
Picked up a spot of Sass. It's not so scary! Since my CSS needs are usually very simple, and variables are available in plain CSS now, I might not use Sass very often, but I often run into it when working with other devs so this was important to learn.
Started picking up a new JS framework: Vue.js!
Learned a lot about a11y/accessibility. Running audits with aXe, Lighthouse, WAVE, and some basics about aria attributes, contrast and colors, and semantic HTML. Tried a screen reader (gonna leave that to the pros)
Learned about static site generators, including Jekyll and eleventy, and spun up a simple one for a work assignment and wrote about how to publish it on GitHub Pages.

Room for improvement

My anxiety slows me down. So, I've re-started therapy, and am re-visiting some old tools to help me cope (like mindfulness practices and rescue medications). It also prevents me from asking for help in a timely manner (like, asking a human is absolute last resort), but perhaps with practice this will improve.
Writing tests is still a challenge for me, particularly unit and functional tests.
Webpack is still mysterious and scary. I can debug sorta (because the error messages are actually very good), and make certain edits, but would like to do better here.
I've neglected my old portfolio projects. This means my resume is woefully out of date. I need to either move them off, or update them. I could also postpone this until I plan to start looking for another job.
I haven't attended any meetups. Just been too busy or out of energy.
- But, I did buy tickets for CodeLand 2020, and am am keeping an eye on some local (+/-) meetups.
While I keep good personal notes in markdown format, I haven't really been keeping up with blogging or any kind of communication about my learning progress (aside from daily stand-ups, but that's not really about my own development).
- I want to re-visit my personal blog/page, and start writing in a more formal way and sharing it. This post is part of that, like a tiny bit of accountability.
Piles of learning fantasies: In Todoist, the "backlog" and "lookit" things are overflowing, and I have a bookmark folder called "learn" and "current learning", and haven't touched them in some time (because I'm learning other things, of course!), and then there's Pocket and the dozens of newsletters and Slack/Discord groups, ahhhh
- Am I ever going to rescue the old Rails projects from Heroku? Before the stack's EOL ends???

On balance, I'm basically satisfied with my progress! It can be done! And while becoming a member of the chronic condition community/disabled may have prompted me to consider this as a career initially, even if I miraculously was all better tomorrow I'd still want to do the same work, I just might be more inclined to consider working on-site (for some portion of the week), or would attend meetups or tackle a more ambitious side-project.
Here's to another year! 👩‍💻

Publishing an Eleventy site to Github Pages

Donna Hogan — Tue, 03 Mar 2020 20:37:28 +0000

Eleventy is a relatively new static site generator. I've heard it's "almost fascinatingly simple", and I have a situation at work that is perfect for this tool.

My situation

I have a small collection of one-off "posts" that are hosted on the repo's Github Pages site, almost like a blog, sort of. Some posts have a template that I just shamelessly lifted from some of the org's other communications for visual continuity.

The problem, of course, is that this is repetitive: if I ever have to make a change to that template (and I have) it must be made on each post.

Additionally, I want to continue to host it on gh-pages (to avoid making this a whole huge thing by changing), so I made an extremely minimal silly little test case to see how Eleventy plays with Github Pages.
I'm sure Netlify is amazing, but I really want to change only one thing at a time (and I also just want to see if this will work 😁)

Initializing

I started by following along with their getting started guide in the docs.
I added a single HTML template (just an <h1> element, basically), and two posts: one in Markdown and the other in HTML (since my use-case involves both). Just some text and a little image in each. I put the posts in the src directory and the template in the _includes directory, just following along with the gorgeously easy to understand docs. So far easy-peasy!

Bringing it to GitHub Pages

'0.' After pushing to Github, make a branch called gh-pages (or whatever you'd like) and go into the settings and enable Github Pages.

'1.' Then, back in your terminal, install the gh-pages package: npm install gh-pages --save-dev.

'2.' Because of this package's command line utility, we can add this item to package.json:

"scripts": {
    "deploy": "gh-pages -d _site"
},
"homepage": "/silly-eleventy-demo",

This allows us to use the command npm run deploy to push to our gh-pages branch from our _site directory (which is effectively the build/dist), and, if our account is already mapped to a custom domain, add the repo name to the url so we still land on the correct index.html.

'3.' Add this to .eleventy.js:

return {
    pathPrefix: "/silly-eleventy-demo/"
}

Because we're aiming to publish to a sub-directory (namely, the specific repo in our domain, as described here), this enables the use of Eleventy's built-in URL filter to prefix all urls with this path.

'4.' Then, assuming you have a permalink (like "myFirstPost/") in the front matter of the md or html content, make your links to it look like this:

<a href="{{ '/myFirstPost' | url }}">First Post</a>
or
<a href="{{ '/'  | url }}">Home</a>

where the | is the nunjucks pipe operator (this is also built-in to eleventy) and says to use the url filter on the string to the left of the pipe.

And finally, run npx @11ty/eleventy if you haven't already since your last edits (you can add the --serve if you want to see it live, as described in the docs) to generate the _site directory, and then run npm run deploy. The page is ready to go at "https://yourGitHubName.github.io/theRepoName"
🎊

Puppeteer stochasticity and timely pauses

Donna Hogan — Thu, 21 Feb 2019 14:23:47 +0000

When only the watched tests are passing...

I'd written a few tests with Jest and Puppeteer for my SPA built with React. Very simple stuff: launch the browser, navigate to the page at localhost, enter some text and click a button, then wait for the next page to load and find a particular selector, that kinda thing.

I added a small feature to one of the views that caused some unexpected chaos with my tests. I hadn't even written any new tests to cover the new component, but I noticed that my tests were suddenly only passing if ran with {headless: false}. Like it needed me to be watching in order for it to work.

I assumed it was a timing issue (and I was close!) so I kept bumping the timeout ever higher on different waitForSelectors and on the suite as a whole, and throwing pauses in there (I was getting so close!), still no luck. When it ran in headless mode, it would fail inconsistently - not in the same place each time, but rather one of a few different places randomly.

I googled (one of my searches yielded only 9 hits!), frantically read the docs, joined the Puppeteer slack community (which is actually very quiet), read all (like, 3) questions in the GitHub forum from people who were seeing similar results, and they all seemed to be running into issues with headless browsers being blocked by some websites. Interesting, but definitely not the issue I was having. I'd hoped to find something like a {stochastic: false} mode 😆

Reflecting on what I had to change to bring in that extra little component, I remembered I had needed to add a lifecycle method (componentDidUpdate) to the same view where the tests tended to start failing.

So, in the tests, after landing on that page/view and identifying all the selectors and whatever (I had confirmed with screenshots that the page had sufficient time to load already), but before simulating the click event on one of the links, I added a 3 second pause for both instances where it occurred... and suddenly the tests were passing consistently! In only 9 seconds!

I know pauses aren't best practice in tests, and if I was writing these tests with Enzyme instead I would probably not need to worry about this, but in this case it seems to be the best way to let that lifecycle method resolve before interacting with the links on the page. And indeed, this more closely emulates the user's experience, since every time it was working with {headless: false} I also had {SloMo: 250} which was incidentally just enough time for the lifecycle method to resolve. This means I could probably safely decrease those pauses to a half-second or less (but this builds in plenty of margin for slowness on Travis CI's end).

What seemed like chaotic behavior of the tests was really a much simpler process (that I wasn't seeing) resolving just a bit slower than the observation period.

Maybe this blog post will be search result No. 10 and save someone else a little time debugging tests!

Starship LCARS!

Donna Hogan — Wed, 03 Oct 2018 22:53:04 +0000

For my Sinatra portfolio project, I made an app for the various ficticious intelligence agencies in the Star Trek universe, based on the database they often use, called LCARS (Library Computer Access/Retrieval System).

In my little non-canonical version of this world, all the intelligence agencies share information =] But of course, each agent has control over their own record (editing and deleting). This app is devoted to keeping records of all warp-capable vessels, including sub-class, top speeds, and crew complement.

Some small things I’m proud of in this project:

I experimented with flash messages! Everywhere!
Used conditional formatting in a view so that logged in users don’t see the login and sign up buttons
I made a custom 404 page (as a bonus it kept my own morale up as I worked on the app! No more of that “Sinatra doesn’t know this ditty…”
Custom favicon
consulted with my resident expert for the theme and terminology throughout

And remember: infinite diversity in infinite combinations ❤

Check out the repo on GitHub

Try it out, here Deploying to Heroku is another part that I’m pleased to have accomplished, with the help of another blog post

Or watch the tour

Originally published at donnacodes.com on October 12, 2017.

Rails Portfolio Project

Donna Hogan — Wed, 03 Oct 2018 22:33:05 +0000

This Rails portfolio project borrows the theme from my Sinatra project, but is rebuilt from scratch to have nested resources, more complex relationships, and more features. My Sinatra project was only for CRUDing starships. This project has two models (Crew and Ships) that have a bi-directional has_many_through association via Assignments, which acts as the join table, and can be thought of as one particular crew person’s role on one particular ship. This schema gives us easy access to listing all the crew member’s assigned to a ship, or where are crew member is currently assigned. Sounds so reasonable!

Quick tip: when generating seed data for users with has_secure_password through BCrypt, make the password_digest attribute equal to BCrypt::Password.create('someString'), and then you can use someString to log in when you’re testing your app!

Also, forms are more than just a pretty face! Rails form helpers sometimes makes me forget that the form dictates the structure of the params hash. At first I had checkboxes for crew people in the new assignments form, but kept getting an error message about the crew_id not existing (which it totally did), but as soon as I switched to a drop down menu the problem was solved. Makes sense in retrospect since an assignment only has room for one crew_id, so checkboxes make no sense in that context, and set the params hash up incorrectly.

Check out the GitHub repo, or my video walk-through !

Originally published at donnacodes.com on December 2, 2017.

Thoughts on my JS-Rails project

Donna Hogan — Wed, 03 Oct 2018 22:26:30 +0000

Completing this was kind of a big deal for me. I had been away from the curriculum for a few months. I found the courage to face this project (and the lab/lesson immediately preceding it) by starting from scratch. After completing the JS and jQuery sections in Codecademy, and faithfully following along with Gordon Zhu’s Watch & Code (which, literally changed my life!) I finally started to feel comfortable enough to start thinking in JS.

For some reason, I decided it would be a good learning experience for me to complete all the requirements for this project without jQuery, and use only vanilla JS. My AJAX functions are a little verbose, as a result, but at this stage, it helps me conceptualize what’s happening at a more granular level to have to manage things like attaching CFRS tokens to a ‘post’ request.

And, since December of 2017 (when I completed the Rails version of this project), my Twitter OmniAuth strategy broke. Their implementation became more complex since I was away, so for now I’m making due with Facebook (I resented a little bit having to sign in and get dragged down that rabbit-hole), but, it was important to get it working again for morale purposes.

Checkout the:

Originally published at donnacodes.com on August 5, 2018.

Scope and Hoisting of variables, functions, and `this` in JavaScript

Donna Hogan — Wed, 03 Oct 2018 18:03:47 +0000

Blog posts and articles abound for this topic (a reference list follows) so I will attempt to highlight common pitfalls for beginner-intermediate web development students learning JavaScript.

Although JavaScript is an interpreted language, implementation in a web development setting involves a step immediately prior to execution called lexical scoping (tokenizing), in which the interpreter skims through your code and identifies all the variables you’ve declared, makes a note of when they’re reassigned, and delineates chunks of code into scopes in three levels: block, function, and global.

// Example 1 (credit MDN)

function exampleFunction() { 
 var x = "declared inside function"; // x can only be used in exampleFunction 
 console.log("Inside function"); 
 console.log(x);
}

console.log(x); // Causes Reference Error

The function’s scope includes the variable x, so that variable is only known within that function. Trying to access it out in the global scope will throw an error because x is not a declared variable (it’s not even undefined).

If we move that var declaration outside the function, it’ll be in the global scope, everyone knows about it, and we can access it within and outside of the function:

// Example 2 (credit MDN)

var x = "declared outside function";

exampleFunction();

function exampleFunction() { 
 console.log("Inside function");
 console.log(x);
}

console.log("Outside function");
console.log(x);

With the advent of ECMAScript2015 (aka “ES6”), two new ways to declare variables were introduced: let and const, which are significant because they enable more granular control over the scope in which a variable is available. Both let and const define local variables which are available only in the level in which they’re defined (whether a code block or function, and any contained sub-blocks).

Hoisting

In the following example, x is declared with var, and that same variable called x is known throughout the function (even on lines which precede it!) and in sub-blocks. If x is declared with the newer let or const, then outer scopes don’t have access to it, and if we “let x;” again in a sub-block, it’s effectively a different variable (like how human twins separated at birth, but given the same name, are not the same person).

// Example 3 (credit MDN) 
function varTest() { 
 var x = 1; 
 if (true) { 
   var x = 2; // same variable! 
   console.log(x); // 2 
 }
 console.log(x); // 2 
}

function letTest() {
 let x = 1; 
 if (true) {
   let x = 2; // different variable
   console.log(x); // 2
 }
 console.log(x); // 1
}

This is relevant because of the lexing step that happens immediately prior to executing the code, and the fact that this:

var x = 5;

is two steps listed on one line: the declaration of the variable x, and the assignment of the integer 5 to that variable. We could also write it like this:

var x;  // declaration
x = 5;  // assignment

When the variable is declared with var, its value is undefined, but it is known to be a variable. Then the next line makes x’s value equal to 5. But, this isn’t the case with let and const. Welcome to the Temporal Dead Zone.

// Example 4 (credit MDN)
function doSomething() {
 console.log(bar); // undefined
 console.log(foo); // ReferenceError
 var bar = 1; 
 let foo = 2;
}

Within this function, the declaration of bar is hoisted to the top of the scope, in this case, the code contained within the function doSomething(). So, effectively, it’s executed like this:

// Example 5 
function doSomething() {
 var bar;
 console.log(bar); // undefined
 console.log(foo); // ReferenceError
 bar = 1; 
 let foo = 2;
}

which is why trying to console.log(bar) yields undefined (we know it’s a variable, it just has no value), while console.log(foo) throws a reference error (“a variable called ‘foo’? what are you even talking about, human?”)

This makes things like this possible:

// Example 6 (credit MDN)
num = 6;
console.log(num); // returns 6
var num;

and:

// Example 7 (credit MDN) 
dogName("Watson");

function dogName(name) {
 console.log("My dog's name is " + name);
}
// "My dog's name is Watson"

In the first example, even though it looks like var num is declared after we assign it, from the computer’s perspective, it noticed that we’ve declared it in the relevant scope (global), pins that to the top, and then proceeds with executing the rest of the code. In the second example, even though we invoke/call the function before we’ve defined it, that definition is hoisted to the top of the scope, so by the time we actually start executing the code, the interpreter already knows what dogName() is.

For var variables, note that only the declaration gets hoisted, not the assignment. So, in Example 6, writing it like this:

console.log(num); // returns undefined 
var num = 6;

returns undefined. For this reason, it’s often suggested to always declare variables at the top of the scope they’re in, so you remember the order in which the interpreter will execute your code. Alternatively, using let and const offer some protection against this behavior, since variables declared this way are not initialized with a value of undefined. So even though they’re hoisted, you’ll still get a reference error because they won’t be initialized until they’re assigned. It’s almost like they’re not being hoisted at all. const has an added advantage of protecting against unexpected reassignment (although an object declared this way may still have its properties modified), like so:

// Example 8 (credit Digital Ocean)
// Create a CAR object with two properties
const CAR = {
 color: "blue", 
 price: 15000 
}

// Modify a property of CAR
CAR.price = 20000;

console.log(CAR);

// Output
// { color: 'blue', price: 20000 }

Similarly, functions follow similar rules. Function declarations are hoisted:

// Example 9 (credit Elizabeth Mabishi at Scotch.io)

hoisted(); // Output: "This function has been hoisted."

function hoisted() {
 console.log('This function has been hoisted.');
};

… while function expressions are not:

// Example 10 (credit Elizabeth Mabishi at Scotch.io)

expression(); //Output: "TypeError: expression is not a function

var expression = function() {
  console.log('Will this work?');
};

How `this` fits into this

A related topic, which I will discuss as it relates to scope and hoisting, is this. Gordon Zhu created a nice cheatsheet which summarizes the corresponding lesson in his life-changing curriculum on Watch & Code. Essentially this is scope dependent (context). If it’s called within a regular function or just out in the wild, this points to window. If you’re in a function being called as a method, this points to the object being acted upon (whatever’s just to the left of the dot).

// Example 11 (credit Gordon Zhu)
var myObject = {
  myMethod: function() { 
    console.log(this); 
  } 
};

myObject.myMethod(); // --\> myObject

An extension of this is the case where this is used in a constructor as in Example 12, in which this refers to the instance of the class Person:

// Example 12 (credit MDN) 
function Person(name, age) {
  this.name = name; 
  this.age = age;
}

Explicitly setting the value of this using call, bind, and apply is outside the scope (haha!) of this blog post.

And in a callback function, it depends on where (what scope) this is being called in, in accordance with the previous examples.

References

Originally published at donnacodes.com on August 18, 2018

On the React-on-Rails portfolio project

Donna Hogan — Wed, 03 Oct 2018 17:30:43 +0000

It’s always kinda bothered me that one can’t edit tweets on Twitter.

Naturally, my React-on-Rails portfolio project is yet another little Twitter clone (called Butter Emails). I spent almost as much time on implementing the edit/update actions as I did on everything else. I almost left it for version 2, but the completionist in me just couldn’t it it go (it’s C-R-U-D not C-R-D!) So, I’m disproportionately proud of that.

One of the things that makes it tricky is how the state tree is structured. Currently, it has a branch for auth (which includes information about the current user and where they’re logged in), and one for posts (posts are fetched as an array of objects in state.posts). This choice meant I didn’t easily have access to setting an inital state (from Redux’s perspective) of editing: false for individual posts. I resorted to having a nested return statement in the postsReducer, which, for now, works just as well, though isn’t as elegant.

The next biggest effort on this project was the JWT/authentication strategy. Since I was designing my own API I didn’t want to use an OmniAuth provider, and instead chose to use the ‘Knock’ gem. I discovered how quietly opinionated this system is. It works, but it seems to lock you into using email addresses for login, which was something I was hoping to avoid. I want to collect as little information as possible from the user (I know, crazy, right?!) but still only have the user’s display name listed next to their posts. Still, it was nice to not need to re-invent the wheel on this part.

Lastly, getting the two servers to work together was the next largest effort. I followed a couple good tutorials, but still couldn’t get the API server and client server to be managed by Foreman, and that ended up just being solved by specifying a more recent version of the gem. (Update your dependencies, kids!)

Originally published at donnacodes.com on Sept 30, 2018.

Quick reference for ruby array methods: push/pop vs. shift/unshift

Donna Hogan — Mon, 11 Sep 2017 00:00:00 +0000

I love to make tables to help me integrate ideas or objects and how they relate to each other.

When I was learning how to work with arrays in Ruby, the words for functions .push, .pop, .shift, and .unshift, didn’t carry any intrinsic meaning or distinction to me in terms of working with an array (unlike .collect, and .size, which do). I kept getting confused about which thing returns an element, and which one returns the rest of the array, and whether it acts on the beginning or the end. So, here’s my table!

	beginning	end
adding, returns array	.unshift	.push
returns removed element	.shift	.pop

and of course, << (shovel) is syntactic sugar for .push

Originally published at donnacodes.com on September 11, 2017.

Origin story: why am I doing this?

Donna Hogan — Tue, 05 Sep 2017 00:00:00 +0000

Origin story: why am I doing this?

In middle school (sometime in the mid 90s), I was so good at what would later be known as googling that I participated in a competitive online scavenger hunt called “Cyber Surfari” (I know…) You could say I was enthusiastic about computers as a kid, and in particular the ✨internet✨.

And yet for some reason, I never even considered taking the elective CS course in high school; it just never felt like a possibility for me specifically. I believed I lacked a certain innate, prerequisite skill, like maybe being amazing at math (when I was only just ok).

It seemed like it wasn’t meant for someone like me, whatever that was.

And anyway, by the time I got to college I already had a hard enough time choosing between physics and biology (spoiler: I’d eventually end up doing both). During my second undergrad degree I had to take an introductory programming course for science and engineering majors, which was taught with MATLAB, and I absolutely ~loved~ it. I started using MATLAB whenever I could for other coursework, got the (second) highest grade in the class, and finished the final coding project in just a couple hours. By this time (preparing for my master’s in biochem), I believed that since I’d already invested so much time and resources towards trying to become a scientist that it was too late to think about switching again.

I love science (and still do). I puttered about with other resources to pick up some R and Python to help with data analysis during my thesis research, but never found the time to devote to getting past the “advanced beginner” stage.

Plot twist!

Acquiring a disability or chronic illness as a grown up has a way of forcing a new perspective on you.

You have to see the world differently in order to cope and adapt. I had to take stock of where I was, what I could do, and what I really wanted, and what was worth buying with my newly limited “good days”. Previous assumptions about yourself, the world, and how you fit into it become open to examination. Suddenly, the idea of me really learning software development no longer sounded so silly. One paradigm shift ushered in another.

Coincidentally, this occurred at the same time that MOOCs had matured, coding bootcamps were abundant, and the barriers to entry were getting lower all the time. Culturally, too, CS was beginning to become a much more inclusive space, and perceptions about who “belonged” were dissolving.

Essentially, my new situation catalyzed the shift I’d gradually been making anyway.

The future!

One advantage of my path is that I gained a whole field of domain experience that I sincerely hope will be useful someday combined with my new web development skills. Perhaps someday I can help build applications to wrangle the copious amounts of data generated by geneticists or biochemists, or work with an organization like Code For America or 18F and help to make government services more efficient and accessible. (Just think of all the blog posts I could write!)

Originally published at donnacodes.com on September 5, 2017.

On creating my first CLI Gem

Donna Hogan — Thu, 31 Aug 2017 00:00:00 +0000

You code the way you do anything else in life. So for me, that means spending roughly three times as long agonizing over the thing than actually doing the thing. However, I’m not too sad, as learning to code has brought that factor down (you should have seen me in grad school…)

Often, I spend so long in the planning phase trying to decide which idea is “best”, that I lose sight of the objective. My Flatiron classmates have been enormously helpful in this process, reminding me that for this, my first project as a web software developer, I’m not expected to re-create Google (or even Altavista). And that as a beginner, I won’t be able to make anything useful until I can make something usable. Sometimes it’s easy for me to get discouraged when something I make isn’t immediate useful or novel, and this gets in the way of even starting.

But, one evening I made the initial commit, and had a functioning CLI gem the next evening. It was a puny little thing, and I still had a “To Do” list and “should maybe do” and “would be nice” lists. But I was surprised, all the same. Avi’s walk-through videos proved very useful, and even through I had watched them through at least once before, following along with my content helped me learn even more still.

Into the weeds…

For example, all this time I thought I had to stay with Ruby 2.3.1 for the labs because most gems didn’t work with later versions. But, in going “off-road”, I ran into a similar problem with Nokogiri, despite uninstalling and reinstalling, . Several dives into Stackoverflow and Github forums later, I found this gem (pardon the pun, I’ll see myself out): gem install –user-install nokogiri. Gems were being installed in a place ruby wasn’t expecting (or rather, rvm wasn’t expecting)

The product (approximately)

My gem, called Pharmacy-Finder, accepts a user’s zipcode and tells you the single closest location from each of two different popular drugstore chains in the US. Obviously, this forces the user to willfully suspend disbelief for a few minutes and forget that the rest of the internet doesn’t exist and search engines aren’t a thing. But I can already see how these smaller gears can fit into a larger machine with access to databases, a more intuitive UI, and more complex object models.

Originally published at donnacodes.com on August 31, 2017.

DEV Community: Donna Hogan

Reading The Fancy Manual: Documentation in Bash

My first year as a dev

Wins

Room for improvement

Publishing an Eleventy site to Github Pages

My situation

Initializing

Bringing it to GitHub Pages

Puppeteer stochasticity and timely pauses

When only the watched tests are passing...

Starship LCARS!

Some small things I’m proud of in this project:

Rails Portfolio Project

Thoughts on my JS-Rails project

Scope and Hoisting of variables, functions, and `this` in JavaScript

Hoisting

How this fits into this

References

On the React-on-Rails portfolio project

Quick reference for ruby array methods: push/pop vs. shift/unshift

Origin story: why am I doing this?

Origin story: why am I doing this?

Plot twist!

The future!

On creating my first CLI Gem

Into the weeds…

The product (approximately)

How `this` fits into this