DEV Community: Nick Palenchar

goodtimer - a setTimeout for humans (+ timer functionality)

Nick Palenchar — Sat, 13 Mar 2021 17:09:22 +0000

This was my first npm package I ever published (originally "t-minus"). I only started revisiting it 4 years later and did some serious rewriting with the goal of making it very developer friendly.

I never felt setTimeout/setInterval alone made for more sophisticated timers. I hope this makes it easier

Thanks for checking out goodtimer!

[Realistically] Boosting Your Interview Chances with GitHub

Nick Palenchar — Sat, 06 Feb 2021 19:27:42 +0000

Canonical URL: https://nickpalenchar.com/github/

When my employer is hiring, I'm the first to want to refer a good person. I'll reach out to my network of bootcamp grads, asking for resumes, hoping I can get them a job at a great company.

I end up throwing out 99% of them every time.

The reason is always the same: their GitHub has half a year or much more of total radio silence.

If there's one piece of advice I could shout from the rooftops, especially to new devs, is that an active GitHub is probably your best competitive advantage to getting an interview or referral cold.

It's not a perfect system. But it's the system we have. And it never fully made sense to me until I found myself on the receiving end of resumes, with more to go through and time I had available.

Simply put, most resumes with equal experience look the same. New bootcamp grads went to a bootcamp and did a couple of projects (that may or may not be hosted). Those with two years of experience have a company they've worked for, maybe two. And everyone is listing similar languages and technologies they use.

It's a start, but then I'm left with 5-10 resumes and 1-3 referrals I can comfortably make. At this point I could paste them to a wall and throw a dart. Or I could look at their GitHub.

Getting your Github ready without loosing slee

You can easily increase your candidacy with an active GitHub but you don't need to go crazy either. Please don't Eat-Sleep-Code-Repeat. Conversely, you can get away with doing the bare minimum and be in a stratospherically better place. Here's some simple ways to do just that:

Set up some dotfiles - Effortlessly save your configuration. And whenever you add to it, you get a 🟩. I use dotbot.
Whenever you take a class, or code through a book, put that code on GitHub - You don't need to author an open source library. Simple code snippets or notes in markdown are great! Put your LeetCode solutions up there too while you're at it. Don't let all the stuff you're already doing collect dust. Get those 🟩s!
Host your website statically on GitHub. - If you have a portfolio, every new thing you add is a 🟩. If you host a blog, new posts are new 🟩. My website/blog is hosted this way with hugo.

It will be very, very unlikely a hiring manager will look at your actual commits. Simply having anything up there is what matters. It shows you walk the walk and talk the talk. It immediately proves you have basic knowledge of the same version control they are definitely using at work.

And again you don't even need to go overboard in frequency. Your 🟩s can be sprinkled like cayenne on a dish that shouldn't be too spicy. But it should not look completely and totally abandoned for the year.

Reversal

I think an active GitHub is the easiest way to give you a competitive advantage, but there are alternatives if they are your thing. Among them, you could:

Be an active blogger - Personally, I don't like doing this. I'd rather showcase my GitHub.
If you're more media oriented, create a YouTube channel - Live coding? Put the recording on your YouTube. Do any talks? Get them on YouTube (if you have permission). Or link all your media on a portfolio page (guess where you should host it).
And none of the GitHub nonsense applies whenever you're referred by a person who knows you well, or even someone you've met at an event and had a good conversation with.

Just remember, if you do have an alternate to GitHub established, do not include a link to an empty GitHub in your resume. You might want to delete your account altogether, if you really never ever use it. Would a photographer link-drop a portfolio with no photos?

But whyyyyyy does it have to be this way?

Yes there are totally flaws in the system. The hiring process has a lot of room for improvement (some companies are trying). You could be a great programmer without doing any of these. But right now, there is no way I can know this by looking at just your resume, and my company will not let me spend 80% of my time talking to candidates to get to know them better.

I totally welcome the conversation to improve the hiring process, from interview to whiteboarding to everything in between. So please write about how it's broken and how we can fix it. I would love to read that. Just make sure it gets committed and hosted on GitHub when you do.

The Worst Blogging Advice I Ever Received

Nick Palenchar — Sat, 16 Jan 2021 18:56:26 +0000

Canonical URL: https://nickpalenchar.com/worst-blogging-advice/

No annoying intro here. This is it:

"When starting a blog, be sure to update it regularly"

I've actually heard or read this general "nugget" many times. It is as ubiquitous as it is terrible. One reason is that it's only applicable to one type of blog. The kind that is monetized, relying on a large group of subscribers, with aspirations of generating a livable wage for the author. Obviously, there are many types of blogs.

Back in 2018 I had set a goal to publish one post a month. I thought it was modest at the time (some authors seem to post weekly at least), but it turned out to be GRUELING. It also didn't produce work I was most proud of. The result of this goal is most of the 2018 posts on this site (you might notice there's less than 12).

The fact that I couldn't commit made me question if I should even host a blog at all. I felt like a blog with large gaps in the timeline would give the same impression a "streaky" resume gives off. As a matter-of-fact, the aforementioned terrible advice is often paired with a warning that you will look like you lack a drive for commitment, which could turn off recruiters during the job search, if you don't post regularly.

This is equally misguided. When I look at my blog, I see a collection of articles that generally represents my thoughts on coding, and general values in the industry. These are topics that are valuable to me, the topics I want to talk about. I don't want it cluttered with noise that is less helpful to readers or myself. Form the viewpoint of a recruiter, wouldn't they rather find content that supports the author's expertise in the field?

I'm not really sure what my blog is. Heck why does it matter? I just enjoy my tiny space on the corner of the internet I can call my own! Maybe it's a subtle rebellion against larger platforms (blog and social media based). But the autonomy makes me feel warm and fuzzy inside.

For me, it's helpful to write my thoughts whenever I'm moved to do so. And I hope the result is a collection of genuine thoughts and advice that others might find helpful, too.

The Whale, the Container, and the Ocean - A Docker Tale with Nick Palenchar

Nick Palenchar — Thu, 23 Jul 2020 11:51:10 +0000

Nick is a former Actor/Director turned coder who has been working as a software engineer for 4 years. With particular interest in DevOps tools and Automation, he has worked in large corporations and small startups alike, and maintains open source projects and teaches coding in his spare time.

Click to download as PDF

I. Intro - Defining Docker

A. Imagine a new engineer asks you, ""What is Docker?"". How would you answer
B. For any engineer in the stack, Docker can be powerful, simplifying development setup and ensuring higher deployment confidence.
C. But there's not many clear resources to help understand the eco-system and what it means for running, building, and debugging.
D. Today we will examine the subtle ways Docker goes about building and running containers.
E. Docker is more than a container. There is a Docker daemon (the ""whale"") which assembles the container, and it lives in your computer ""the ocean"", which is the environment it has to work with. Let's explore how these areas relate to each other.

II. From the Computer to the Docker Daemon.

A. (Visual: A ""box"" (the container) sits on top of the ""whale"" (docker daemon), who floats above an ""ocean"" (computer (filesystem)).
B. !Important distinction! Docker daemon does not see your filesystem. It only sees the context that you the developer sets for it (commonly ""."").
C. That dot is small but important. It's the common unix character for the current directory. When running docker build, you often use this to set the context to the location where you're runinng the cli from.
D. Specifying a directory (""."") copies everything within it to the Docker Daemon (""whale""). The only thing it sees is the subset of your file system.
i. (image of an abridged filesystem in a tree layout, with a section selected in red that corrosponds to the terminal command. That section is copied to the whale. The result is the whale has a smaller file system, and the ""root"" of it is ""."")
ii. from here a few examples how things work:
a. A Dockerfile ""COPY .. /someplace"" doesn't work. While the computer has a parent directory from its working directory, the daemon is already at the top level directory, and directories above it weren't copied to the daemon. Take away is: wherever you set the build context, you can't go higher than it during buildtime.
b A `docker build ./project-with-tons-of-node_modules in it, to show that builds can significantly slow down if your context is too large (reminding that everything first needs to be copied to the daemon before even starting the build process).
E. Overview of dockerignore
i. (visual, demonstrating the same thing as above but with some diretories ""redacted"" out, as specified by the .dockerignore file, leaving a leaner filesystem for the docker daemon's context)
ii. More than size, it would be a mistake to copy node_modules or generated builds into the container.
iii. Your computer might be running a different version of a process than the container might have, introducing inconsistency with builds. We'll talk about RUN commands to better handle this next.

III. From the Docker Daemon to the Container.

A. Section title: You've sent things to the Docker Daemon, but where it's going looks different still.
B. Isolated visual of the box, this time with the lid open and a disk hovering over (the ""image"")
C. Points on how during buildtime (going through the Dockerfile), is the only time content can be added to a container to get it working (footnote that this is oversimplification)
D. A look at some Dockerfile commands and how they relate between the docker context and the container.
i. WORKDIR - setting the working directory in the container (just like how there's a default working directory on your computer's shell)
ii. COPY - again, this is sourcing from the Docker Daemon and moving to the container
a. Important to note, there is no access to your computers files at this point.
iii. RUN - executes commands inside the container.
a. Important note is not the context (The run command ""already doesn't"" run on your computer
iv. ENTRYPOINT/CMD - these are ""saved"" rather than ran, as defaults, and can be overridden for customization or debugging.
E. Final tips for successful building and debugging.
i. Selecting the right amount of ""context"" can speed up build time, but be sure it encompasses all files you need.
ii. Files generated from build processes or installs (npm) should happen in the container (rather than your computer) to ensure consistency.
iii. Errors around files not found (common) is because the file wasnt copied or copied to the wrong place. Identify where in the container the process is starting from, and try to connect it to where the file may be.

This talk will be presented as part of CodeLand:Distributed on July 23. After the talk is streamed as part of the conference, it will be added to this post as a recorded video.

An interactive CLI that updates the default branch name in any/all your GitHub repositories.

Nick Palenchar — Tue, 07 Jul 2020 23:56:53 +0000

Technically, this is in preview stability.. but wouldn't it be nice if some great members of Dev previewed it?? :D

$ npm i -g flipswitch
$ flipswitch

Here's the npm page
Here's the github page

t-minus v2.0 - timers/setTimeout with superpowers (a rewrite of my oldest side-project)

Nick Palenchar — Mon, 06 Jul 2020 00:12:28 +0000

Earlier this year I decided to take my oldest side project and rewrite it with what I know now.

t-minus v1.0 was written in 2015 as an easy way to set timers, with some emphasis on use in a browser UI.

Specifically, it was born out of an even larger side project that uses pomodoro timers (eattomatoes.herokuapp.com - unmaintained but still somewhat functional)

It utilized callback functions to control what happens as seconds pass, as well as when the timer hits 0.

var timer = new Timer('1:30', {
  onInterval: function() {
    this.getTimerUI(); // human readable string!
  },
  onTimeout: function() {
    // times up!
    this.restart(); // `this` refers to its own timer + handy methods!
  }
});

It had all the methods you'd expect on a timer.

timer.pause
timer.resume
timer.reset
timer.clear

and it was written as a single vanilla JavaScript file

The 2.0 rewrite

const { Timer } = require('t-minus');

I rewrote the entire module from scratch, taking into account v1's README to preserve the interface. I wanted a better written package that's more optimal, but had the same basic API and usage as its original.

The end result has some new features for use:

Support for milliseconds (v1's smallest unit was essentially the second)
UI/timer setting units up to years (v1's largest unit was the hour)
More accurate pausing (v1's pause would stop at the last full second)
More memory efficient (v1 would keep setIntervals when a timer is paused; not in v2)

...and new features for development.

Unit test coverage 🙌
Written in TypeScript 👨‍💻
Overall better documented.

If you need timer functions or want a better way to handle countdowns in the browser (or node). Consider giving t-minus an install 😁

If this project gets even one contribution from someone other than me, I would have exceeded my goals with it. Check out the repo if you feel so inclined

Life-changing git Commands you probably aren't using

Nick Palenchar — Sat, 11 Apr 2020 16:45:50 +0000

This article was published May 26 2018 on my own site, nickpalenchar.com. The original post is maintained here, but I thought I'd share it with the broader community on dev 💌

Every developer uses some kind of version-control system (sometimes called VCS). It a fail-safe to losing work, allowing you to jump back in time and reference files as they once were. Because branching is supported, so much more than linearly stepping back in time is possible. VCS is the backbone for agile collaboration, allowing each developer to have their own copy of some codebase, where they can work at their own pace and merge changes back into a master copy when ready.

Enter `git`

If you or your company uses GitHub, you're probably very familiar with git. Depending on how well you can wrangle the CLI, git can be amazingly useful or incredibly infuriating. And like everyone else using git, I've ran into numerous problems and found my own various ways out of them. As my experience grew I began to keep a log of "git solutions", which in turn revealed a few useful commands I commonly employ. While simple, they've come in handy time and again. Maybe they'll come in handy for you as well!

I call these commands "life-changing" because they are so simple yet pretty unknown. But most importantly, after adopting them you will probably find notable differences in your workflow. You'll (hopefully) spend less time on git and more time on what matters--pushing that code!

`git remote -v`

The -v option stands for "verbose". Many people use git remote to verify a remote (usually named origin) was added to a repo. Fine for that single case, but we don't get much more information. Especially since most repos have only one remote, frequently with the same origin name. If you want a bit more info, -v gives you the URL to which those generic origin remotes are actually pointing too. I like to think of it as knowing what the value of a variable is in a certain instance, which is often helpful in debugging situations.

Why it's life-changing: Ever have a directory you think linked to a certain remote repo but wasn't sure? A directory holding a git project does not have to have the same name as the repo on, say, GitHub, so it could be a similar or vastly outdated repo. Out of caution, some developers might just delete the directory and re-clone the repo, ensuring it is the project they want. But git remote -v can validate the remote repo in one step. Observe this sample output:

$ git remote -v
origin  https://github.com/nickpalenchar/nickpalenchar.git (fetch)
origin  https://github.com/nickpalenchar/nickpalenchar.git (push)

The location of where I ran this command is a repo that is linked to my nickpalenchar repository under my username (nickpalenchar). No recloning needed!

`git commit --allow-empty -m 'your message...'`

Generally, when you try to commit when nothing is staged for doing so, you'll get a nothing to commit, working tree clean response, with no commit made. The --allow-empty flag bypasses this saftey check, allowing (you guessed it) an empty commit. So even when nothing is staged or changed, a commit will be written to the git log.

Why it's life-changing: (I love showing off this one.) There are lots of situations where you need to test doing something with a new commit in order to verify some sort of workflow. A common scenario in my work is verifying a webhook in Continuous Integration will pick up a newly pushed branch. I could touch yet_another_new_file, then add it, then commit it. Or I could git commit --allow-empty -m 'empty commit for debugging' and push that. So convenient. Just one word of warning: you probably don't want this in a more formal codebase; but it's great for a prototyping/testing repo that you will dispose of.

`git stash` / `git stash pop`

Admittedly a little more well-known, but if you weren't aware of stash, I'm glad I can take this opportunity to enlighten you. git stash sets all your working changes aside (on a stack) and gives you a clean working directory. You can git stash multiple times, and the most recent stash will be at the top if the stack that git has been adding them too. As it goes with stacks, git stash pop will pop the top-most set of working changes and add them back to the branch you're currently on, ready to be modified or committed.

Why it's life-changing: The most common use for a quick git stash/git stash pop is to move the working changes you've made from one branch to another. Say you've started working on some changes, only to realize you're on the master branch! Depending on your repo setup (and if you're in a team), you probably can't push changes from your master branch. You're stuck! This is the classic opportunity for the stash command. Simply git stash to set those changes aside, restoring your master branch to good-standing cleanness. Then git checkout the branch you intended to use and git stash pop. All your new work has been seamlessly moved from one branch to another!

`git rm --cached`

Another one that's a bit well known, but not known enough in my opinion (or I wouldn't still be removing files that were considered removed). git rm can remove a file that has previously been committed, but adding --cached will better ensure it does not come back.

Why it's life-changing: It's life changing when trying to update a .gitingore file. Life gets tough when you git add . and commit before you remember to add a certain file to a .gitignore. Now you have a file tracked that you did not want. To fix this problem in a fool-proof way, you can git rm --cached name_of_file (for directory use git rm --cached -r name_of_dir), add the file to .gitignore and commit all changes. You won't find that file ever showing up in that repo's tracking again. Another word of caution: this is NOT a solution for removing secrets that were accidentally committed, as they will still exist in the git log! But for something like say, removing node_modules, this would be the perfect solution.

Bonus: git auto-complete

Not an actual command but I had to include as it's probably the biggest life-changing thing you can do with git! Git autocomplete will save you a LOT of time (both in typing and fixing typos). Once set up, you'll be able to start typing a few characters of a name, then tab to auto-complete or see all possibilities of the current name fragment. It can autocomplete names of git subcommands, remotes, and branches. You can find steps to set this up here or here in my bash profile.

I love these commands. They've solved common problems quickly, and have largley improved my overall git competency. Do you have any git commands/tricks you've found to be time-saving? fool-proofing? life-changing!? I'd love for you to share your common git commands in the comments. Thanks for reading!

Did you loose faith in the tech industry at some point in your career? How did you bounce back?

Nick Palenchar — Fri, 10 Apr 2020 13:02:49 +0000

Non-CS degree devs: How has your non-traditional background shaped your perspective on coding?

Nick Palenchar — Thu, 09 Apr 2020 22:06:46 +0000

Do you feel it has had a positive impact? Maybe it hass given you a unique perspective, allowing you to see things many others don't.

Or maybe a negative one? Separating you from the rest of your team.

Or maybe its neutral 🤔?

What git strategies does your company use?

Nick Palenchar — Mon, 06 Apr 2020 19:42:53 +0000

There's general best practices of working with git on a team (such as the popular gitflow), but things are always more complicated in practice! Let's talk about how our git workflow is designed in our workplace or team, including but not limited to:

Branching strategies used
How mistakes in git are addressed
How commit messages are formatted
Any advanced concepts employed (configs, hooks, submodules, trees)
Anything else!

Feel free to add how your experience has been with your company's workflow. What have you learned? Anything you would change?