DEV Community: Jonathan Irvin

chore(dev.to): change to offendingcommit

Jonathan Irvin — Fri, 19 Apr 2024 17:16:38 +0000

Time to retire my old handle and continue with my new handle.

Transitioning from Frontend Engineer to DevOps Engineer: Four Questions to Streamline Processes

Jonathan Irvin — Thu, 16 Mar 2023 15:05:15 +0000

As a Frontend Engineer turned DevOps Engineer, I've learned the importance of optimizing team productivity and efficiency. But let's face it, DevOps is not just about mean time to recovery or continuous integration pipelines, it's about making work fun and playful. So, in collaboration with my colleague Karl Monney, we've come up with four simple questions that will help streamline processes and keep things playful.

The Four Questions

1. What's your endgame, and how does this task fit in?

Tell me what you want to achieve with this task and how it fits into your grand scheme of things. It's like playing a game of chess. We need to know your strategy so we can help you execute your moves.

2. What can you offer to speed things up?

We know you're busy, and so are we. So, let's make things more efficient. What do you have that can help us get the job done faster? Screenshots, links, or code snippets, you name it. If you want it fast, give us the tools to do it.

3. How is this affecting you right now, and how can it help us establish priorities with our own work?

We get it. You're under pressure, and we don't want to add to it. So, tell us how this task is impacting you right now, and we'll make sure it gets done with the urgency it deserves. Not only does this help us understand your pain points, but it also helps us establish priorities with our own work. We want to make sure that we're addressing the most critical issues first, so your feedback is critical.

4. How will you know when it's done?

It's all about setting clear expectations. So, let us know what "done" means to you, and we'll make sure to hit the mark. We want you to feel confident that when we say it's done, it's done.

Conclusion

These four questions are easy to use and will keep things playful while helping us streamline processes, establish priorities, and define completion criteria. Whether you're a designer, developer, or a DevOps engineer, these questions can be used by anyone, anytime, anywhere. So, let's get playful and make work fun again!

What kind of Git Workflow does an elephant use?

Jonathan Irvin — Thu, 09 Jun 2022 14:20:02 +0000

Trunk-based development

Removing Git Branch Bloat

Jonathan Irvin — Mon, 06 Jun 2022 16:01:14 +0000

If you have too many Git branches, bookmark and like this page.

Note: You'll see "(^*|master|main|develop|release)" a lot in the below scripts. This is a regular expression that excludes those long-lived branches so those won't be considered.

To list all local branches that have been merged into the current branch:

git branch --merged | egrep -v "(^*|master|main|develop|release)"

To list all branches that have been merged into the current branch:

git branch -r --merged | egrep -v "(^*|master|main|develop|release)"

To PURGE all local branches that have been merged into the current branch:

git branch --merged | egrep -v "(^*|master|main|develop|release)" | xargs git branch -d

STOP!

Be very, VERY certain you know what you are doing. This following command modifies the shared repo and unless there is a perfect clone, it has the potential to remove branches that people don’t have a reference to.

To PURGE all REMOTE branches that have been merged into the current branch:

git branch --merged | egrep -v "(^*|master|main|develop|release)" | xargs git push --delete origin

Git Anti-patterns

Jonathan Irvin — Mon, 06 Jun 2022 15:47:06 +0000

Git has ENORMOUS flexibility. It can sometimes (always) be intimidating. So much so, there are countless articles on "this is better than THAT". Don't worry, this won't be one of those articles.

I'm here to air out some dirty laundry. You know, the anti-patterns. The stuff that makes us cringe. The cautionary tales.

The Uncreative

Same Commit Message, Different Day

fb14c9 updates
1fcf56 updates
0e2506 updates
970bc6 updates
ae3aaf updates
2e3aa6 updates
e62616 updates
d5a520 updates
c3a77d updates
b9fba4 updates

The Deal With It Later

Branches for DAYS, weeks, ...months...years?

The Silo

One Commit To Rule Them All

You keep force pushing the same commit with different changes

Squashing is for posers

Don't like squashing your commits

fb14c9 it works
1fcf56 trying something else
0e2506 fixes
970bc6 reply to pr
ae3aaf it doesn't work
2e3aa6 it works again
e62616 something is broken

I’m on TikTok now

Jonathan Irvin — Mon, 30 May 2022 13:51:10 +0000

https://tiktok.com/@offendingcommit

I’m posting content related to git, adhd, programming, relatable, Q&A, tips and tricks, and some random stuff that gives me dopamine.

Let's get one thing straight: Code is read by humans, interpreted by machines

Jonathan Irvin — Fri, 20 May 2022 18:51:05 +0000

It doesn't matter how eloquent your code is or how you turned a bunch of code into a one-liner. If you are the only one who can read the code, have someone else go find a manager or executive...because it's their problem now.

Spell. Out. Your. Code.

Make it readable. Add comments, abstract it out into functions that read like a sentence.

Because at the end of the day, humans have to maintain it. Machines interpret it. So as long as the logic is sound, make it easy and pleasant to read.

It's OK To Be Replaceable

Jonathan Irvin — Thu, 19 May 2022 15:34:15 +0000

You might come across some articles on the web about how you should be "irreplaceable" to your team. We tend to put ourselves in positions where we are the only one who can do X, Y, or Z. The whole operation comes crashing down without us.

I'm here to tell you that is a big ol' lie.

The truth is this: your employer can drop you at the blink of an eye. Obviously, no one wants to lose their job and I'm not talking about the loss of gainful employment here. What I am talking about is being in a position where your team can pick up where you left off.

Silos happen purely out of convenience and herein lies the situation. Management tends to "stick with what works" and put the best people on the tasks that would be best suited for them. What people don't realize is you can gain more dividends by putting someone else on the task that would get you 85% of the way there and let the person who you would normally assign the task to provide some feedback. Now you have two people who can do the task.

So, what if you've dug yourself into the trench of reliability? Well, guess what? You're probably inundated with emails, IMs, meetings, Slack messages, PagerDuty ... the list goes on. Those are obviously plentiful, but what isn't is your mental health or your freedom to take PTO.

The answer? Knowledge management.

Write documentation, record videos, loop people in on what you know. Explain. Educate. Powerpoint. If you're the Primary on something, tag someone to be your padawan and show them the ways of the Force. You get the idea. Stop holding the cards close to your chest.

Trust me. You're valuable with what you already know. Sharing doesn't make you any less valuable or put you at any more risk of getting canned. If you're at risk of getting canned, I guarantee it wasn't this article and you likely deserve better employment anyway.

Think about it. We would never have the beautiful works of art from famous painters and sculptors if they never expressed what they know. The same applies to technology. Just because you know something and the other teammate doesn't, means that you have to be available more to do the same task.

Delegate. Educate. Disseminate.

What's your Git Personality?

Jonathan Irvin — Thu, 16 Dec 2021 15:56:31 +0000

The Git Slinger

You're the fastest committer this side of the stack. You are speed. You put forth Pull Requests with no less than 25 commits and it only took you a day. Who needs rules about formatting when you commit like it's a Yahoo chatroom in the 90s.

The Silo

MY PRECIOUS! You hoard your commits and only those that are worthy get pushed. No one sees your true commits, only the ones you absolutely have to let loose into the wild. Your local repo is filled with commits and branches that will never see the light of another repo.

The Re-Re-Rebaser

You like to play fast and loose with git commits. Who cares if they get rewritten. Merges are for losers and that's not you. You rebase everything, even your thoughts. Why merge when you can just replay 30 commits on top of master. Conflicts be damned.

The Ancient One

Your commits are based off of a release that no one has seen for months. You've been working off of the same branch and when you go to submit a pull request, you're shocked to learn you have so many merge conflicts. The team groans at sorting out the mess you've made.

The Go-With-The-Git-Flow

Ok, so bugfix branches are branched off of and merge into release branches. Feature branches get merged to develop. Releases di-merge into develop and master. Hotfix branches only branch off of master. The answer: MORE BRANCHES.

The Singularity

docs: git commits should be read by machines, not humans [skip-ci]
feat(dev.to): add emoji to commits to prove sentience :heart:

Slides into the CI/CD server's DMs

hey girl, heyyyyy!

Well, Actually...

Well, actually, git commits are like emails with a subject line and a body, but the subject line is most important.
Well, actually, git commits should be no more than 50 characters, any more than that is just wasteful
Well, actually, rebasing is better than merging...
Well, actually, the best git workflow is...

Choose your own!

Add your own personality in the comments!

If you're going to use a poor commit message, just git rebase -i instead

Jonathan Irvin — Thu, 16 Dec 2021 15:32:16 +0000

We've all been there.

Panic commits. You've spent HOURS on a problem only to solve it at the end of your day. The end of your sanity.

You know you want to save your work and commit it, but you've done so much brain-mashing that the eloquent commit message you had hours ago is lost to a sea of fog and quick-hacks.

it works.

Before you push, let's take a beat here.

Maybe you are trying some things and a rapid commit-cycle is more your style. You are a git-slinger. Pew pew pew!

You arrive at the same destination as above. Before you push, let's take a moment to reflect on your last N commits.

git commit rebase -i HEAD~{{number of commits you've done}}

As you know, I'm vehemently against rebasing public commits, but if it hasn't been pushed yet, the world is your oyster.

So, a rebase stacks the group of commits on top of your new "base" point, in which case, it's the commit you chose above.

HEAD is the latest commit and the number of commits before that selects the right ancestor. I know, it's some Marty McFly shit.

An interactive rebase gives you the ability to squash commits into each other (basically summating the changes into a single commit), reorder them, change their commit messages, and many more options.

In short, you can clean up that disaster you committed trying to solve that one thing by that one date.

Let me close by saying this one important thing:

Be careful.

Rebasing rewrites your git history. You can lose work if you aren't careful. When in doubt, just squash all of your commits instead of removing or reordering them until you get more comfortable with the operation.

For more about rebasing, check out:

https://git-scm.com/docs/git-rebase

If you like my git posts, check out https://dev.to/sublimegeek/git-staging-area-explained-like-im-five-1anh

Dynamically Create Jenkins Executors Using Docker

Jonathan Irvin — Wed, 15 Dec 2021 20:42:07 +0000

Jenkins is great until you run out of executors and are waiting on other jobs to finish before you get to run yours.

Inspired by and based off of https://devopscube.com/docker-containers-as-build-slaves-jenkins/ I created a simple docker image that uses Volta to install NodeJS so I can farm jobs to a pool of docker containers that dynamically provision and disappear as needed when jobs complete.

jonathan-irvin / jenkins-docker-nodejs

Run Jenkins jobs that require Node.js in a container using a Docker cloud so you can dynamically allocate executors instead of having to provision new ones each time

jenkins-docker-nodejs

Runs Jenkins agent in a docker container with different versions of NodeJS to easily build those projects you have in an ephemeral way instead of setting up individual jenkins executors. This allows you to run several jobs at once with minimal resources in a much more controlled way.

Job runs nightly and on pushes to main to refresh the packages.

Node LTS Docker Container:

Latest Node Version:

jenkins-docker-nodejs:latest

Inspired by and based off of https://devopscube.com/docker-containers-as-build-slaves-jenkins/

View on GitHub

Test Optimized Development

Jonathan Irvin — Tue, 05 Oct 2021 15:30:38 +0000

As devs, we’re taught to write tests first, then refactor until the tests pass. This is difficult if you don’t know your design first and frustrating if you have the functionality, but the tests aren’t passing.

Which is why, if you write your code to where it can be tested easily, everyone wins.

Using Functional Programming vs. Class-based components

The concept is not new. Writing functions vs. classes is much more efficient. While you can easily instantiate a class and have everything you need, they are hard to test when it comes to React. Breaking just about everything into functions and utilities allows your code to be tested with ease and code coverage is boiled up using abstract methods vs complex classes.

Maps, ForEach, other loopy things? Use a function for that, too.

Unless the operation is super simple, define a named function for what happens within a map() or forEach() loop which can be isolated and tested.

Quality over Quantity

It’s super easy to pad code coverage these days. Just test to see if something mounts without breaking and tada! You’ve got super high code coverage…but what did you test, really? TOD expects that your tests should be value over volume. If you have a lot of code that flows through a small area or maybe you already have methods that are shared throughout your code base. Start there. If there’s one small break in that code, it will wreck the most.

Quality Multiplied

Now that we a test that adds value over volume, what other scenarios can we throw at it. Don’t settle for just one scenario. Cover multiple. Got several test cases you want to iron out? Write a function for it and make your tests DRY.