DEV Community: Eric Jakobsen (he/they)

“What?” - The Duck

Eric Jakobsen (he/they) — Tue, 18 Oct 2022 00:58:04 +0000

If you are new to coding there are several things you might want to purchase - a good keyboard and mouse, the most ergonomic chair within your price range, and a rubber duck.

Yes, you read that last one correctly. A rubber duck is as vital to the coding process as a workable computer. Some might argue even more so.

“How does a bathtime toy help me improve my coding?” you might ask. It is a reasonable question.

You are going to talk to your rubber duck. Not only that, you are actually going to teach your rubber duck to code! As you learn new coding concepts, explain them to your duck.

As you write and work through code, explain that code to your duck. What does the code do? How do the different components work together? Why did you choose this way of doing something over other options? Your duck wants to know everything!

This process of “rubber ducking” has a long history in coding. It is a tried and true method that helps us externalize our thought processes and solidify concepts.

It is easy to read through an explanation of a coding concept and think we grasp it. But can you actually explain it in your own words? Is your explanation complete and still understandable? “Rubber ducking” puts these questions to a test.

One of the best ways to learn is to teach. Consciously and consistently building that process into your coding journey will help you succeed.

“Rubber ducking” is actually more helpful in learning than teaching another person. Why? Your rubber duck is always there! You don’t have to wait for a set time to explain the concepts you are learning but can do it while you learn.

I am a big of Barbara Oakley and her course, “Learning How to Learn”. In it she extolls the virtues of active recall - the act of retrieving information from your memory to deliberately strengthen the neural pathways to it.

In other words, you can strengthen your long term grasp of material by stopping periodically as you learn to remember what you learned. At the end of each page, what main points were covered in the paragraphs? At the end of the chapter, what were the main ideas the author was trying to get across?

Can you recall them? And can you explain them in your own words so your rubber duck can understand?

Rubber ducking also prepares you to excel at technical interviews. Interviewers don’t just want to watch you solve the coding challenges they present. They want to hear your thought process and see how you engage with others when solving a problem. All your “rubber ducking” is practice for doing exactly that!

These interviews are meant to assess how you will do on the job, so unsurprisingly “rubber ducking” will also help you prepare for that. All of us who have worked on teams can attest how nice it is to work with other devs who can communicate well. I will gladly take someone who can communicate processes and their perspective clearly over the most skilled coder who cannot. I promise I am not alone in that.

“Does it have to be a duck?”

No, not at all. You are welcome to use a rubber duck for tradition’s sake but any object will do. I happen to use Groot who is an expert software engineer by now:

I use Groot because he has those big kind eyes that just scream “I support you and am listening.” That is the energy I need, especially when I am stuck on a frustrating problem or concept. I recommend choosing a “rubber duck” you especially enjoy since you will be spending lots of time together.

I hope this gives you some insight into the world of “rubber ducking.” Please share your rubber ducks in the comments!

Final fun fact - Bob Fornal actually sent me his rubber duck, BatDuck, for a visit here in Tucson. BatDuck is still traveling around the world from one coder to another.

How to keep your secrets off GitHub

Eric Jakobsen (he/they) — Mon, 17 Oct 2022 02:01:19 +0000

GitHub makes a developer’s life so much easier - you can use it to collaborate, track changes, and backup your files securely with ease. If you are not careful you can also expose pieces of your code that could put all your work at risk.

For example, if you are using MongoDB as your database you will need to store your MongoDB access string in your code. If you push your code to GitHub with that access string visible any person who sees your project can then access your database and monkey with it.

“A better way”

The first step to keep your secrets safe is to use environment variables. Node supports these out of the box through the “env" object that is itself a property of the “process” global object. Environment variables are typically written in all caps. So an example would be:

DB_STRING = mongodb+srv://username:password@example.1iq6k8.mongodb.net/?retryWrites=true&w=majority

This allows us to include our secret information throughout our code without actually showing it.

“But the variable has to be declared somewhere, right?”

Correct, dear reader. The environment variables do have to be declared somewhere. We will do that in a special folder called “.env”. This folder will eventually load all environmental variables within it automatically into the “process.env” object. An npm package called “dotenv” drives that process so we need to install it.

You need to already have Node.js and npm installed for this to work. You can find downloads and instructions for those here.

Once you have Node and npm installed, simply use the following terminal command to install “dotenv”:

npm i dotenv

Then require and configure “dotenv” in your app as such:

require(‘dotenv’).

Once this is installed, go into your file structure and create a file called “.env” either at the top level or in your config folder (in which case you would need to set the appropriate path for its location in your code: "require(‘dotenv’).config()"). Open this file and plop in your environment variables.

Here we have the DB_STRING from earlier as well as the PORT our server is running on locally:

DB_STRING = mongodb+srv://username:password@example.1iq6k8.mongodb.net/?retryWrites=true&w=majority

PORT = 2121

You may notice there are no quotation marks - "dotenv" automatically takes care of those.

“One last step”

There is only one final step: set up a “.gitignore” folder. Like the name suggests, GitHub will ignore anything referenced in this folder and not upload it to your repo.

Go back to into your file structure and at the top level create a file called “.gitignore”. Then add in your “.env” folder like such:

.env

You can also add "node_modules" and any other large packages that can be reinstalled locally. That saves the time it takes to push your code to GitHub as well as your storage there.

“That’s it, folks!”

Thanks for spending a few minutes with me exploring this topic. I hope it was helpful and you now feel sure of how to guard your secrets. Feel free to ask any questions you have in the comments and I will do my best to address them!