Forem: Eric Crooks

Bonfire Sessions: Snuky's New Application Details Page

Eric Crooks — Tue, 28 Apr 2026 22:38:23 +0000

Summary

I have a ton of scrap wood (woodworking is my hobby) and time to spare in my job search. So here I am coding Snuky by the bonfire—finishing a new feature that enables me to take control of each job opportunity and refine my process for other job opportunities.

Issues Encountered

Drizzle ORM

I chose Drizzle ORM for Snuky because I like exploring new technologies. I've used Prisma, Sequelize, and Postgres.js for most of my JavaScript career and don't have issues with them, but I prefer not to rely on the same tools repeatedly. Drizzle is new to me and I want to see how intuitive it is and how it compares to what I've already used.

Interoperability

When I migrated the project from using SQLite to Postgres, I had to change my Drizzle ORM queries. For example, here's some code showing how to get my resumes using SQLite and Postgres implementations. I'm using drizzle-orm@~0.45.2 here btw.

const db = drizzle(/* configs */)

// SQLite impl
const result = await db
  .select()
  .from(resumes)
  .where(eq(resumes.id, Number(id)))
  .get();

// Postgres impl
const results = await db
  .select()
  .from(resumes)
  .where(eq(resumes.id, Number(id)))

const result = results?.[0]

As you can above, the SQLite implementation can return a result in a single chained call. The Postgres implementation does not have a .get() method, so I had to figure out how to get a single result from the query—make the query and get the first element of the possibly returned array.

My expectation with interoperable code here is: devs should be able to switch their database without having to modify their code. Granted, the code is not far off from being able to do this, but being a little off can degrade the developer experience (if you add missing documentation to this, then it's degraded a bit more).

Being on drizzle-orm v0.x, I did try using drizzle-orm v1.x and it didn't make a difference with interoperability. I still had to change my code.

Migrations

I had a difficult time trying to get migrations to work. The error outputs aren't clear and sometimes there are no errors. Sometimes drizzle-kit just fails silently, and I'm not the only one experiencing these issues. See the related issue and pull request below.

I spent about 4 hours trying to get migrations to work for me. I even tried using the internal migrate() function and couldn't get that to work for me (still encountered silent failures).

Documentation

There's a documentation-driven article on GitHub somewhere that states (words to this effect), "If it's not documented, it doesn't exist. If it's documented incorrectly, it's broken." In Drizzle ORM's case, there are many things undocumented, yet the product seems feature-rich. I do wish their documentation was more verbose and broken down Barney style like Team Treehouse videos because I feel this product can be very intuitive. I did fork the repo with plans to write some documentation for them, but that's a low priority for me right now.

Originally published at https://www.crookse.com.

AI vs. AI: Snuky’s New Look

Eric Crooks — Tue, 28 Apr 2026 22:36:30 +0000

Snuky in a Nutshell

I started working on Snuky a week or two ago. I mentioned it in my last article (How AI Is Driving Your Job Search Without You Knowing) where I discussed using AI tools to "beat the system" (the system being any AI-driven ATS).

Snuky is my AI-driven platform for automating job searches and applications. Tracking them in Google Sheets was burning me out, so I decided to code something to solve that pain point in my job search. As of today, Snuky is tracking my applications, monitoring job postings, and notifying me of changes to job postings. So far it's made job searching easier for me—especially when it comes to notifying me about job postings being removed.

Looking Forward

Job Description Matching

By reverse-engineering AI models and ATS keyword matching (NLP-driven), I think I've figured out how they score resumes against job descriptions—they (or recruiters themselves) reject candidates that don't meet a specific threshold match (e.g., 50%). Snuky does well with extracting job description keywords, but calculating my resume's exact match score is iffy since AI models define "matches" differently. Using this knowledge, I'll combine the results of different AI models and use the average match score.

More Automation

This is just the beginning of my automated job search process. I'm planning to automate it to the point I don't have to search for jobs. My plan is to have Snuky search for jobs (specifically job descriptions on job boards) that match my resume or could match my resume (based on keyword matching). From there it will take my resume and tailor it to the job description. Currently, that's a manual process for me and it's tedious AF.

Originally published at https://www.crookse.com.

Why we created Rhum for testing Deno projects

Eric Crooks — Wed, 24 Jun 2020 12:31:28 +0000

Rhum is a lightweight testing framework for Deno. It uses zero dependencies outside of Deno's Standard Modules and works with deno test under the hood.

This article dives deeper into the "why" we created Rhum and for what purpose.

An article written by @craigmorten dives deeper into using Rhum. Link is here https://dev.to/craigmorten/how-to-write-spec-tests-in-deno-55e8.

The Problem

The Drash Land team and I noticed that testing Drash was starting to become unwieldy. Drash has many unit tests and the output was something like:

test parseBodyAsJson: can parse JSON bodies... ok (2ms)
test setHeaders(): attaches headers the request ... ok (2ms)
test getMimeType(): file is not a URL ... ok (3ms)
test getMimeType(): file is a URL ... ok (4ms)

While testing, we noticed that the output was not as descriptive as we wanted/needed it to be to help us debug failing tests. Failing tests were not easily noticeable through the output. So next we tried to be more descriptive with the tests to get the following output:

test http_service_test.ts | parseBodyAsJson: can parse JSON bodies... ok (2ms)
test http_service_test.ts | setHeaders(): attaches headers the request ... ok (2ms)
test http_service_test.ts | getMimeType(): file is not a URL ... ok (3ms)
test http_service_test.ts | getMimeType(): file is a URL ... ok (4ms)

With this setup, a failing test would show us what test file to look in and what test to look for. This worked for a while, but then the output grew and it became a bit hard to read. See the screenshot below:

Not only that, our tests files became hard to read because we did not have a syntax like Mocha's nested describe and it syntax.

The Solution

To make things easier for us, we decided to work on a module (which later became Rhum) to help us write tests like Mocha and Baretest. We also wanted the output to be nice. Our thoughts on the syntax were something like the following:

testPlan("the_test_file.ts", () => {
  testSuite("methodOne()", () => {
    testCase("returns true when it does the thing", () => { ... });
    testCase("returns false if it can't do the thing", () => { ... });
  });
  testSuite("methodTwo()", () => {
    testCase("returns true when it does the thing", () => { ... });
    testCase("returns false if it can't do the thing", () => { ... });
  });
});

We used testPlan, testSuite, and testCase to follow QA practices. This is testing after all.

Our thoughts on the resulting output were something like the following:

the_test_file.ts
    methodOne()
        returns true when it does the thing
        returns false if it can't do the thing
    methodTwo()
        returns true when it does the thing
        returns false if it can't do the thing

With some very helpful guidance from @bartlomieju from the Deno team, we were able to build Rhum and have it work for us in a way that makes writing tests easier and reading output easier.

Before Rhum, we had the following output in Drash:

test services/http_request_service_test.ts | accepts() | Asserting: accepts the single type if it is present in the header ... ok (1ms)
test services/http_request_service_test.ts | accepts() | Asserting: rejects the single type if it is not present in the header ... ok (1ms)
test services/http_request_service_test.ts | accepts() | Asserting: accepts the first of multiple types if it is present in the header ... ok (1ms)
test services/http_request_service_test.ts | accepts() | Asserting: accepts the second of multiple types if it is present in the header ... ok (1ms)
test services/http_request_service_test.ts | accepts() | Asserting: rejects the multiple types if none are present in the header ... ok (0ms)
test services/http_request_service_test.ts | getCookie() | Asserting: Returns the cookie value if it exists ... ok (1ms)
test services/http_request_service_test.ts | getCookie() | Asserting: Returns undefined if the cookie does not exist ... ok (0ms)
test services/http_service_test.ts | Asserting: getMimeType(): file is not a URL ... ok (3ms)
test services/http_service_test.ts | Asserting: getMimeType(): file is a URL ... ok (4ms)

test result: ok. 116 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (839ms)

Now we have the following:

services/http_request_service_test.ts
    accepts()
        accepts the single type if it is present in the header ... ok (1ms)
        rejects the single type if it is not present in the header ... ok (1ms)
        accepts the first of multiple types if it is present in the header ... ok (1ms)
        accepts the second of multiple types if it is present in the header ... ok (1ms)
        rejects the multiple types if none are present in the header ... ok (1ms)
    getCookie()
        Returns the cookie value if it exists ... ok (1ms)
        Returns undefined if the cookie does not exist ... ok (1ms)

services/http_service_test.ts
    getMimeType()
        file is not a URL ... ok (3ms)
        file is a URL ... ok (3ms)

test result: ok. 116 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (770ms)

Not only that, the test files in Drash are much cleaner with nested test suites and test cases.

If you are testing your Deno project and running into the issues we came across, I recommend you give Rhum a shot. It may solve your problems as it did for us.

Thanks for reading!

Eric

Special Thanks

@bartlomieju for showing us the following issue to base our development on: https://github.com/denoland/deno/issues/4092

All who participated in the poll for the name. It was tied between Rhum and Bourbon. We decided to close the poll and have Alexa flip a coin for us. Rhum won.

@melhirech for suggesting Rhum in the polls.

Drash - A REST microframework for Deno

Eric Crooks — Thu, 27 Feb 2020 03:40:45 +0000

As Deno's visibility grows, I'm seeing more and more people who are interested in creating Deno HTTP servers so they can build applications. About a year ago I was in the same position and then came Drash. Drash is a REST microframework for Deno. It's loaded with documentation and tutorials and covers many use cases. I recommend (if you're interested) you check it out!

https://drash.land