DEV Community: Dillon Adams

Unable to find Ruby class that definitely exists

Dillon Adams — Sun, 12 Jan 2025 00:00:00 +0000

Recently I have been learning Ruby on Rails! With that learning comes a lot of lessons, and this one was both fun and frustrating for me. While working in the Ruby on Rails project, I created a new class and RSpec tests for that class.

/app/thing/thingy_doer.rb

class Thing::ThingDoer
# ...
end

/spec/thing/thing_doer_spec.rb

RSpec.describe Thing::ThingDoer do
# ...
end

I ran the tests and got the following error:

NameError:
  uninitialized constant Thing::ThingDoer

Crazy right? I specified the class name in the test exactly as it is spelled in the class, but the RSpec tests can’t find the class. Why?!

The issue is that Rails has a loading convention that matches the file name to the class name. Due to the mismatch between the name of the thingy_doer.rb file and the ThingDoer class, Rails can’t find the class.

The solution is is correct the typo in the file name. Once the file is renamed from thingy_doer.rb to thing_doer.rb, everything now works as expected!

5 examples, 0 failures

Git-ing Started

Dillon Adams — Mon, 22 Jan 2024 00:00:00 +0000

When starting to learn Git you will see a lot of people claiming that Git is complicated and hard to use. Mostly because Git is complicated and hard to use. You can do a lot of wild and crazy things with Git, but to function on a day to day basis only a few commands are needed to do the basic Git workflow.

The Basic Workflow

First we need to clone the repository. This can be an existing repository or a new one that was just created. This will copy the repository code down to your computer, and set you up with the latest that is on the default branch (typically named main or master)

git clone <RepositoryURL>

Most workflows won’t allow you to make changes directly to the default branch, so you will have to make your own branch. This is an area where you can make your changes.

git checkout -b <BranchName>

That command is shorthand for creating a branch and then switching to that branch. The long way around is these two commands.

git branch <BranchName>
git checkout <BranchName>

Once your changes are made, you will need to stage them to be committed/saved. You do this by adding the files directly, but I tend to just include everything. If you want to add specific directories or files, set the path to the file or directory instead of the . in the command.

git add .

Next we want to make our changes permanent. We do this by committing them with a hopefully meaningful commit message. If every commit message is the same generic message, it can create a terrible situation when you need to do more advanced things down the road.

git commit -m "<Message>"

Last, but certainly not least, we want to persist our changes outside of our computer. We need to push them up to the server that we initially cloned them from. For new branches, we will need to specify the target branch on the server.

git push --set-upstream origin <BranchName>

If the branch has already been pushed, we can use a simple push.

git push

Giving up

Every once in a while, you get to a point with a branch that you just want to reset everything back to where you started at the last commit. The specific motivations behind this are wide ranging, but each is valid and you deserve a solution.

git checkout .
git clean -fdx

The checkout command resets any existing files back to their original state. The clean command deletes any newly created files (f), directories (d), and any files that Git is set to ignore (x).

Conclusion

There are a lot more features in Git that people has literally written books about. Once you have mastered the basics, then I would recommend looking into the more advanced features. I have been using Git for almost about decade at this point and I rarely use the more advanced features of this tool so I highly recommend a focus on the things that you will actually use.

If you end up in a situation where you are stuck, there is a website called Oh Shit, Git!?! that is an excellent resource.

Hopefully this helps you Git going!

Versions Are For Humans

Dillon Adams — Fri, 07 Jul 2023 05:21:05 +0000

What does it mean to version a piece of software? I believe that it applies a meaningful label to indicate the capabilities of the software at that point in time. As software engineers, the most common method of doing this is semantic versioning. Each number in a semantic version conveys a meaning for a human to understand and use as a basis their decisions.

If these version numbers are meant for humans to derive meaning from, the incrementation of any part of the version should not be automated. Automatically incrementing a version strips the version of it's meaning. Let's say that we increment the patch version of a softare package each time we merge to the main branch. The issue is anyone consuming this software package has no clue whether there are breaking changes, new features, or just bug fixes in the new version.

Version numbers are meant for humans, and they should be set by humans. The engineers making changes to a software package should set the new version number as a part of their change. They are the ones that understand the change best and are the most suited to translate the effects of the change into a semantic version.

Original Post: https://codejanitor.dev/blog/2023/07/06/Versions-Are-For-Humans

How To Create A Memory Leak In Golang

Dillon Adams — Wed, 05 Jan 2022 00:00:00 +0000

A while ago I was monitoring a containerized application, and noticed an odd pattern in the graph for memory usage. The memory usage would climb steadily until reaching the memory limit set on the container and then precipitously drop to zero. This pattern would repeat as long as the application was running. I had a memory leak. Cue ominous music

The cause of the memory leak was a fairly simple thing, but due to multiple changes over time in this area of code I had completely missed it. Here is the relevant code:

package main

func main() {
    running := true

    for running {
        defer func() {}()
    }
}

Warning: If you execute this code on your machine, it will max out your CPU and eventually your memory

I had deferred a function inside of a long running loop. Each time a function is deferred, it gets added to a stack or stack-like data structure (last in, first out). Once the function containing the defer is completed the stack for that function is emptied one by one and executed. The issue here is that the loop completing an iteration does not trigger the execution of the deferred functions, nor does exiting the loop.

In my case, deferred functions would continue to be added to the deferred functions stack until the memory footprint finally exceeded what was allowed by the container causing the container to crash. A way around this issue, would be to wrap the defer statement in another function like this:

package main

func main() {
    running := true

    for running {
        func() {
            defer func() {}()
        }()
    }
}

Wrapping the defer in a function causes the secondary function’s deferred functions to be executed on every iteration instead of letting them accumulate indefinitely until the program finally finishes. That being said, the solution for my issue was to remove the deferred function from inside the loop.

package main

func main() {
    defer func() {}()

    running := true

    for running {}
}

Making Comments Count

Dillon Adams — Tue, 12 Oct 2021 00:00:00 +0000

A generally accepted practice for writing software is leaving comments. These comments will hopefully be helpful to the next person that reads through the code. My overall goal when I comment code is to either describe the purpose of a method/class/file or the reasoning behind a decision that was made in the code.

Some comments describe what the code is doing verbatim. These work really well in coding tutorials or when I’m learning a new language and I need to remind myself of the function of a particular operator. Outside of those scenario’s I haven’t found them as useful since they are telling me something I already know by reading the code.

// Post-increment x and assign to y
var y = x++;

An exception to my previous statement, is when I find myself using a more esoteric operator, but in that case it is also nice to leave an explanation why the task couldn’t be accomplished with a simpler approach.

My preferred type of comments provide context to future contributors (including myself once I’ve forgotten everything about that piece of code in about a week). These are the comments that save time down the road by helping future contributors avoid pitfalls that have already been found and remedied.

// Using a loop instead of recursion due to intermittent StackOverflowExceptions
// when processing deeply nested objects
while(condition)
{
    // ...
}

Happy commenting!

Testing GitHub Pages Locally

Dillon Adams — Fri, 06 Dec 2019 03:22:18 +0000

Something has always bothered me about deploying something that I haven't tested locally. A big manifestation of this is my blog. Since my blog is currently hosted on GitHub Pages, I needed Jekyll and all of its dependencies. Since those aren't things I typically have installed, so I decided to use a piece of software I always install: Docker.

The whole ordeal managed to come out to a single line:

Linux

docker run --rm -it -v $(pwd):/srv/jekyll -p 4000:4000 jekyll/jekyll jekyll serve --watch

Windows

docker run --rm -it -v "%cd%":/srv/jekyll -p 4000:4000 jekyll/jekyll jekyll serve --watch

Note the double quotes since Windows paths can have spaces

This command should be run in the root of your GitHub Pages project. It will create a Jekyll container that is listening to the current directory for changes and is exposed via port 4000. This way as you edit either blog content or site styling the changes appear as quickly as the site refreshes in your browser.

Build/Deploy from the Beginning

Dillon Adams — Tue, 19 Nov 2019 14:08:25 +0000

When I start a project, I like to follow a few steps to speed things along later. The first is to get the basic project compiling successfully and the next step is to set up the automated build and deployment infrastructure (bonus points if the build/release can be put into version control with the codebase). Some of the benefits of setting up the build/deploy infrastructure early on include automated feedback, easier deployment, and informed design choices.

Automated Feedback

Setting up an automated build/deploy provides an early feedback mechanism for those working on the codebase. This feedback provides extraordinarily valuable feedback to those working on the codebase. This feedback includes if the merged code builds and if all of the new and existing tests are passing. While this all should be confirmed locally, people make mistakes and sometimes things slip.

Easier Deployment

Building on the Automated Feedback, changes can be made to the codebase freely without impacting the ability to deliver the software. A symptom of spending excessive amounts of time developing code is a rough and lengthy process figuring out how to deploy that code. By allowing the build/deploy process to grow with the codebase, the necessary changes to build and deploy the product will be included as the codebase grows. This allows the person with the greatest understanding of the change to make the incremental changes to the build/release process.

Informed Design Choices

As the product's codebase grows, more and more design choices are made and each of those choices involves trade offs, incurring opportunity cost. The earlier these choices are made, the greater the impact is to the whole system. Having build and deployment infrastructure from the beginning forces decisions involving deployment to be considered as the changes are being made. This way changes that incur an unacceptable amount of deployment pain can be either avoided, or reverted with much less pain since there aren't any dependent changes yet.

Conclusion

In the end, the goal is to be able to produce and deliver excellent, quality software with as little pain as possible. Setting up build/deploy infrastructure early on can alleviate the pain of developing a product and then figuring out how to release it.