Dustin Blackman - Blog

Stop using PhantomJS

2023-11-29T00:00:00+00:00

Yesterday I archived a very old GitHub project of mine called phantomized</a>. If memory serves right, it was my lazy solution to being able to run PhantomJS (a scriptable browser) within an Alpine docker image that I had built for an old Discord bot, when Alpine was making it's way in to the Docker scene.

Every so often I look through my old projects, and anything I deem unmaintainable or no one uses it, I archive the repo. Good to keep things clean! When I reached phantomized, I looked and saw there has been no PhantomJS release since 2016</a>, all the projects are archived, the packages are deprecated. I thought "yep, it's dead, everyone's moved on to Puppeteer, let's wrap this up", and I hit the archive button thinking this is just cleaning up and nothing more.

Man, I was wrong.

I've received several messages across platforms I didn't even know had a chat that I've broken production builds of both newish and legacy applications. I'm sorry, I didn't mean to make your job today harder, I really thought this was long and dead.

If you're hitting my blog looking for answers, there are now a lot of forks</a> of people who've fixed up the repo and gotten the package available again that you can use. 

Before you do, it's important to point out that you really shouldn't be using PhantomJS anymore. SEVEN years of not receiving any patches for a web browser is long, like really long. If you're using it for things like CI of your web application you're probably fine, but if you're hitting the public internet then your app is susceptible to CVE-2019-17221</a>. That's scary, and this doesn't include any other WebKit</a> vulnerabilities that have popped up over the years.

If phantomized has helped you out in the past, I'm glad I could help! In return, do me a favour and have that likely difficult chat with your Boss on managing tech debt before some other open source maintainer hits archive on a repo. Better now than in a panic later.

Thanks for reading! Good luck.

Oatmeal

2023-11-27T00:00:00+00:00

I can't open HackerNews or GitHub Trending without seeing something around LLMs. The ecosystem is booming, there's always something new, and it's been pretty fun to watch! Recently I had a buddy show off Continue.dev</a>, a tool that seamlessly integrates an LLM of your choosing into your daily workflows. Its capabilities extend beyond mere code building; it simplifies mundane tasks, enhances test writing, and aids in debugging. Not to mention, it's fun. 
While Continue.dev is impressive, my preference for the terminal, and specifically Neovim led me to seek an alternative. My goal was to build a solution that mirrored the interactivity of a Discord conversation, complete with slash commands like my old bot from a few years back, yet capable of integrating with Neovim for a broad range of topics and problems.
One weekend morning over breakfast I put together the first commit for Oatmeal. Despite the whimsical name, this project quickly transformed into a comprehensive tool that I'd find myself reaching for while working. It's been my first attempt in the world of TUI's, and thankfully there are fantastic libraries in the Rust ecosystem like Ratatui</a>. 
I've definitely 2xed what I had initially intended as a first set of features, but I suppose all projects start off like that. Either way, it's looking great so far:

Agnostic Backends: Choose between ChatGPT for expansive knowledge or Ollama for privacy concerns.</li>
Integration with Editors: When using it in an editor like Neovim, it's gotta feel like it's part of the editor.</li>
Fancy Chat Bubbles: It looks like a chat app! Less IRC, more iMessage.</li>
Slash Commands: Simplifies actions with intuitive commands, from sending data back and forth between an editor, coping to clipboard, or changing models on the fly!</li>
Hotkeys: A mix of both what Neovim and Discord users would expect such as CTRL+U/D for page up and down.</li>
Syntax Highlighting: When using it for code, it's gotta have the same look and feel as my editor, including the correct colours.</li>
Session Management: Being able to look back on old convos, or reopen ones that I fit fingered closed by accident.</li> </ol>
Oatmeal is not just another chat application; it's a tool that caters to the needs of modern tech enthusiasts, developers, and anyone who loves a good terminal interface. It blends traditional UI elements with modern functionalities. Whether you're looking to interact with LLMs, finding a new daily workflow, or simply enjoy a sleek terminal chat, I hope you find Oatmeal worth exploring.
Check it out on Github</a>, and the quick Neovim integration demo below! Thanks for reading!


Why does everyone install crates globally?

2023-11-27T00:00:00+00:00

Unless I'm missing some big piece in the Rust ecosystem (which could totally be true), is everyone just ignoring the pains of managing teams working in Rust, and the global dependencies were all asked to install? Is that really the right way to do things?
Hear me out.
Take the fictional scenario that I'm a new guy joining a team of five working on a Rust project. I'm introduced to cargo-awesometestrunner</code> as they all use it to run the test suite of the app. So I head over to the docs, and I see cargo install cargo-awesometestrunner --locked</code>, paste it in my terminal, and bam I'm ready to go.
But wait... 
Jane on the team says, "wait a sec, let's be sure were using the same version so we can repro any problems together". Sure, that makes sense. So I run cargo install cargo-awesometestrunner --version 0.5.23 --locked</code> because that's what she's got installed. 
Bob a desk over is like "Hang on Jane, why is your version so old? Didn't you upgrade to version X to fix the bug Y we saw last week?"
Jane is now confused. "What bug? Did I miss the Slack message sent to @channel to upgrade to latest?". 
Bob looks, realizing he forgot to send it.
Lizzy at the end of the table heard the discussion through her headphones and brings up "We can't install the new version yet, project ABC isn't compatible. We gotta stay on the old version".
Jane is now frustrated, Lizzy is distracted, Bob is annoyed.
And then there's me, wondering why we all install things globally.
I've touched a bunch of languages and tool sets over the years. Professionally I've mainly done Typescript/Javascript, Python, and Go. In the JS world, npm+friends scopes all binary dependencies within node_modules</code>, allowing them to be accessed by running something like npm run eslint --help</code>. Python does something similar where all dependencies are inside a virtual environment (.venv</code>) that you activate to update your shells paths.
As part of the official tooling, Rust is missing that at the moment. That's totally fine, they're busy building the really important stuff. However, when I'm onboarding new people, or full teams on to the Rust language coming from ecosystems like JS and Python, this can be hard to manage. CI is another story. It's frustrating when something unique is breaking your CI workflows, only to find it's because some global dependency updated that you forgot to pin.
That's where cargo-run-bin</code></a> comes in. Instead of installing all the additional Rust CLIs and Cargo extensions globally, you just install cargo-run-bin, and it scopes all your tooling to each project.
It works by adding a block in your Cargo.toml specifying all the tooling and versions you'd like attached and available to the developers working on your project. For example, cargo-run-bin has the following tools</a>:
[package.metadata.bin] cargo-binstall = { version = "1.4.4" } cargo-cmd = { version = "0.3.1" } cargo-deny = { version = "0.13.5" } cargo-insta = { version = "1.31.0", locked = true } cargo-llvm-cov = { version = "0.5.25" } cargo-nextest = { version = "0.9.57", locked = true } cargo-release = { version = "0.24.11" } cargo-watch = { version = "8.4.0" } committed = { version = "1.0.20" } dprint = { version = "0.40.2" } git-cliff = { version = "1.3.1" } </code></pre> Now, for something like dprint</code>, I can run cargo bin dprint</code> and it'll run the exact version that's specified in Cargo.toml. Any local or CI script that is executing dprint</code>, I can go and update with the new cargo bin</code> prefix, and I'll for sure have all versions are locked in. If you don't want to wait to every dependency to build, run-bin can be paired with cargo-binstall</code></a> where it'll look to download precompiled releases before attempting to build from source simply by adding it to [package.metadata.bin]</code>. The real killer feature that cargo-run-bin has is the capability to assigning Cargo aliases for any of the cargo-*</code> tools by running cargo bin --sync-aliases</code>, where it adds lines to .cargo/config.toml</code></a>. With this, the conversation between my fictional team and I never happen. By running cargo nextest run</code>, run-bin will download, cache, and execute version 0.9.57</code>. This is not the first time I've solved this issue. Every time I pick up a new language, I look for what may be missing in my development experience, and build that first! Go has the same problem, and I solved for my own apps a couple of years back with gomodrun</a>, which does close enough to the same thing by producing a tools.go file for all binaries, and updating the lock file accordingly. If you're having the same kinda issues as my fictional team, or are preparing for the release of your new open source project, check out cargo-run-bin on GitHub</a>! If you're looking to scope binaries that live outside the Rust ecosystem, the sister project cargo-gha</code></a> gets the job done. Thanks for reading!