Elise Shaffer

I Don’t Like Shoulda Matchers

2024-01-29T00:00:00+00:00

There’s a lot of testing tools for Ruby on Rails. Ruby started life with a strong testing culture. The ecosystem is brimming with tools. But not all of those tools spark joy. I love a lot of them. I’ve written about my nostalgia for Cucumber. But one tool that always makes me feel weird is Shoulda matchers.

Shoulda matchers are a tool written by thoughtbot that gives you one line tests for various Rails features:

RSpec.describe MenuItem, type: :model do
  describe 'associations' do
    it { should belong_to(:category).class_name('MenuCategory') }
  end

  describe 'validations' do
    it { should validate_presence_of(:name) }
    it { should validate_uniqueness_of(:name).scoped_to(:category_id) }
  end
end

This can seem like a great idea, but I can’t help feel that this style of testing breaks the boundary for Rails. The example above tests that the MenuItem model has particular associations and validations. I firmly believe that tests should act as a collaborator with the code under test. None of the collaborating modules or classes cares that a MenuItem belongs_to a category. The collaborator cares that when it calls menu_item.category it gets the appropriate MenuCategory record back.

This kind of test isn’t acting like a collaborator. It’s acting like a developer. A better test would be some thing like this:

RSpec.describe MenuItem, type: :model do
  describe '#category' do
    it "returns a category record" do
      menu_item = menu_items(:split_pea)
      category = menu_categories(:soup)
      expect(menu_item.category).to eq category  
    end
  end
end

This example uses fixtures, but you could imagine using FactoryBot as well. This test is longer. But, it’s much more specific and tests the expected return value of the association.

It could be more acceptable to use some of the controller matchers, but even there I would choose to write more coarse tests that act like a user. For example, the set_flash matcher will check that the flash contains a particular message. But, from the customer perspective that doesn’t matter. What matters is that the flash is rendered on the page and is visible.

Both of these examples feel a bit too clever to me. That’s how all of the shoulda matchers feel.

Write tests that act like real collaborators. Make them use the same methods a real collaborator would and assert on the return value. For your models, call the association the way you would in a controller. For your views, assert that the proper text is rendered in a response. It will give you a real test of what the code is supposed to do.

Do you use shoulda matchers? Send me a email with your thoughts.

Why I Write My Tests First

2024-01-22T00:00:00+00:00

I am a pretty outspoken Test Driven Development advocate. I’ve recently appeared on a few podcasts talking about how I love TDD and why I think it’s the best way to write software. Test driven development advocates not only believe that automated software testing is necessary, they believe that the best way to develop software is to start with the tests. When I advocate test driven development, I sometimes get some understandable pushback. When you are new to testing, it can be hard to imagine how you could start with the tests. But, after some practice, it becomes second nature and you reap huge benefits.

I follow the test driven development workflow most of the time. The workflow goes like this: you write a failing test that should pass when you’ve completed work, then you run the test to see that it fails. After you see the failure, you write only the code that will fix the current failure or error. This is important. You aren’t writing all the code to pass the test. You’re writing only the code that moves you past the current error message. You repeat this step, working from error to error, until the test passes. Then with working code and a test for safety, you refactor and clean up the code while making sure the test still passes.

This approach grants me so many advantages.

First, it ensures that my tests fail for the correct reasons. Sometimes a test could pass even if the code doesn’t work. When this happens, I start to lose trust in the tests. If I write the test first, I see it fail appropriately. The process of TDD helps me gain confidence that the tests will catch me if I break something in the future. This is one of the biggest strengths of TDD and a big factor in why I love it so much.

Second, test driven development makes sure that every line of code has a specific purpose. Because I’m only writing the code that I need to move past the current error, each line of code has earned its place. I know that everything in the codebase is necessary. I think many of us agree that less code is better. There’s tons of memes about how satisfying it is to delete code. TDD lets me know that all that code has a purpose.

The confidence means I can move more quickly. Because I know all the code is necessary and the tests fail appropriately, I can develop way more quickly. One of the biggest problems with big complex codebases is the need to hold the whole system in your head. When I know that I have comprehensive test coverage and I trust those tests, I can offload some of that mental work to the computer. I can start programming the software necessary for the current ticket. If I break anything, the test’s I’ve written in the past will catch the breakage and surface it to me.

A problem arises if I don’t have enough tests to be able to do that. If only some cases are covered, then even with the tests, I need to think about all the edges and collaborations happening in the codebase. I almost dislike this more than having no tests. Either I don’t trust the tests and do all the mental work anyway. Or I do trust the tests and get burned by a testing gap.

Test driven development also helps guide my software design. Because the tests are written first, I can think about what the hypothetical API of the thing I’m building should be. In the end, I will end up with an API that makes more sense to the collaborate because I have lived in the shoes of the collaborator. The test itself is a collaborator.

That might be controversial. I know some people think that TDD actually damages the design of software. I strongly disagree. While TDD is not a panacea for poor code, it encourages writing good code. The best code bases I’ve worked in have been the ones where the team practiced test driven development. The worst have been the ones with tests that were written after the fact, in unreliable ways that damaged trust in them.

Test driven development leads to better on call shifts. When I write the test first, I know that I’ve covered all of the important code paths. This doesn’t mean that I’ll never have errors. But, I know that the things I care about work. Errors that do crop up will most likely not be catastrophic. This lessens the on call burden and reduces stress for the team.

It helps me think about the boundaries of the problem. The discreet steps of TDD have conditioned my brain to be a little modal. When I’m in testing mode, I think about what the software has to do. While I work on writing one test, I might have a thought or insight about another test case. So I write that test. Or maybe I add an empty test that covers that case. In RSpec, skipped tests print a warning when you run the tests. I get a great reminder of the cases that I care about.

Test driven development is a huge part of my workflow. It has so many benefits. I tried to talk about the ones I find most useful. But, there are others. For example, TDD is the easiest way I’ve found to enter a flow state while coding. I really take a lot of pride from test driven development. It helps me write better code, more quickly, and with less stress.

Do you use test driven development? Send me an email and tell me your test driven development experiences.

On Code Quality

2024-01-15T00:00:00+00:00

There’s a quote that’s been nagging at me for the last month. I recently watched a talk from Allen Holub. In it, he says, “You can’t be agile when you’re fighting your code.” That line has been stuck on repeat inside my brain ever since.

I’ve worked at many companies in my fourteen years of being a software engineer. I’ve seen quite a few codebases. Some of them were really easy to work in and others were quite challenging. The easiest codebases to work in were the ones that were well factored, using consistent patterns, with clear responsibilities and architectures, and comprehensive testing. The ones that were difficult to work in were the ones with tightly coupled code, models that made excessive use of callbacks, and dozens of layers of indirection with no testing or testing that was unreliable.

Good quality code allows you to move so quickly. It’s easy to change, extend, and refactor. You can look at its structure and syntax and easily understand it. Poor code quality is complicated. It’s a tangled mess of interlocking method calls, objects, and concepts. It’s hard to read and reason about. Moreover, it’s probably untested because poorly written code is hard to test (This is one of the reasons that TDD advocates want to write the test first), making it less reliable.

Poorly written code makes programmers anxious and leads to longer development times. When you have a bug, it will be more difficult to find and fix. When a new feature is requested, it will be more difficult to integrate with the poor codebase. When something goes wrong, it will be more stressful on the team. So why do we let our codebases get so bad? Why do we write poor quality code?

In my experience, it has many causes(most things do). Teams are under a lot of pressure. Tight deadlines lead to cut corners. Poor code leads to more poor code. If you don’t have time to clean up the existing code, it’s hard to write good new code that interacts with it. Micromanagement can hurt your motivation. If you aren’t allowed to clean things up, or if you get significant pushback when you do, then you’re less incentivized to write good code. Poor test coverage increases this problem. Tests are a safety net. If you aren’t automating them, then that creates a larger manual testing burden when you need to refactor or clean code up. A lower appetite for experimentation means that if the first thing you try solves the problem, but in a clunky way, you’re stuck with it.

All of these issues impede our ability to write good quality code.

Well written code is a superpower. Code that is well factored has so many advantages. It reduces your stress. It makes your software predictable. You’re less likely to have unforeseen errors. When you do, they’ll likely be easy to fix. On call shifts and incidents will be less frequent and easier to manage when they do emerge. New features are easier and faster to develop.

A venture capital consultant once told me that code quality didn’t matter because you could always pay someone to deal with it. Or, you’d sell your company and it wouldn’t be your problem anymore. That felt so short sighted to me. What if you didn’t sell your company? What if the quality problems led to so many defects thats customer left before anyone was willing to buy your company?

It’s tempting to just push something out as fast as possible without regard to code quality. It’s tempting to think that it’s removed from the customer. Or that it doesn’t matter. Or that it will be someone else’s problem. But everything the customer experiences is downstream from how well we write code. We should take that seriously. In this way, writing code well is a customer concern.

As programmers we have to stand up for our craft. We need to make code quality a priority. We need to push back against the idea that code quality doesn’t matter. We need to stop cutting corners and mend the corners we’ve already cut. If we can’t move the quality needle in our current teams, we need to find teams where we can.

Well written code will make you love your job. Poorly written code will make you hate it.

I want to always get better at software development. I want the code I write today to be better than the code I wrote yesterday and tomorrow’s code to better than today’s. Well written code helps me get better. When I was a child, I did martial arts. My instructor had a saying, “Practice doesn’t make perfect. Perfect practice makes perfect.” There’s no such thing as perfect software, but that doesn’t mean we should stop caring about doing the best work we can. When code is well written, we all get better. It frees our minds from stress and lets us experiment more on solutions. That makes us better developers.

If I can’t write good code, either because it’s hard within the current codebase, or because I’m not given the time or freedom, I am not getting better at my craft, I’m becoming stagnant.

Code quality is one of my strong values. Well written code sparks joy, reduces stress, and improves productivity. Allen Holub made a quippy remark about code quality. And we should all take it to heart.

I Love Ruby

2023-12-18T00:00:00+00:00

I’ve done a lot in my career. From working on business support software to big backend systems and even robotics. If there’s been a consistent through-line to my career, it’s the Ruby programming language.

In recent years, Ruby has fallen out of favor with the tech industry, but I still love it. It’s a great language with so many strengths that it hurts when I see people trash Ruby or say its time is over. Thankfully, I’m not alone. There are so many Ruby devs still out here. The community is niche, but thriving. People are puzzled by this sometimes. Once, a colleague once said “rubyists really love ruby,” with an air of surprise. I’ve heard others trash ruby for not having types. One person laughed at me when I said Ruby was an “expressive language” and said, “it doesn’t express anything about the implementation.”

So why do myself and others love Ruby so much? I thought I’d explore this a bit.

Fostering Programmer Happiness

First and foremost, Ruby is a language that strives to make programmers happy. This is an underrated value and one that often gets our community mocked by our peers within other communities. The language is meant be joyful to use. This is a value and an ethos that permeates the language, the ecosystem of gems, and the community. Everything else that Ruby is stems from this value.

When I write Ruby, I take so much joy out of the process. Even the bad parts. In the middle of a high stress incident, Ruby still sparks joy. In fact, the only time I don’t enjoy Ruby is when I’m working on a piece of code that doesn’t follow Ruby practices, patterns, and idioms. Which brings me to the next topic

Expressiveness Encouraged

Ruby is probably the most expressive programming language on Earth. Between its metaprogramming features and cultural idioms, Ruby allows programmers to write code that clearly expresses its intent. Well written ruby code can often read like natural language. Features like predicate methods even give up punctuation. So you can easily write something like:

if @subscription.supports_feature?(:feature_a)
  ...
else
  ...
end

This is often why ruby programmers don’t like comments. In most cases, the language makes comments unnecessary. And when you do need them, it’s often when you’re doing a very specific or obscure thing that requires context to understand. It’s clear from the code why you need a comment in that case.

Tied into this is the ecosystems embrace of domain specific languages(DSLs), which give us the power to write incredibly expressive code that reads like what it’s doing. For example, RSpec’s DSL reads exactly like how a person might talk about what they want to test:

RSpec.describe Ticket do
  context 'when the ticket is closed' do
    it 'emails the requestor with a confirmation' do
      ...
    end
  end
end

~~Methods~~, sorry “approaches,” like this have made Ruby so joyful to use.

A Language Made Just For Me

Many rubyists, myself included, recount stories of how Ruby and Rails just fit their brain. I recently told this story on Remote Ruby about learning ruby. I said that when I was learning Ruby it felt like it was made just for me. I could guess method names and signatures and I would be right most of the time. When I was wrong, I could switch the order of arguments. This was so true that quickly I learned to just try something based on intuition before reading the docs. I know so many rubyists who have similar stories.

Feeling recognition in the language you’re programming is so powerful.

Community And Values

It’s so hard to talk about Ruby without talking about how the community shapes what Ruby is and how it feels to use the language. Ruby is a great language with so many benefits. There’s lots of features and values built into its core that make it a joy to use.

But as Kent Beck said at RailsConf in 2020, “Software design is an exercise in human relationships.” He was talking about how we think about designing software. But I think this quote applies to our community and our values as well. If you’ve followed this blog or listened to The Ruby on Rails Podcast since I took over, you know that community is a big part of my value system. That value is shared by other rubyists.

I attended RubyConf in San Diego this year. These conferences are always a blast. It feels like I’m coming home to see old friends. The community building that happens at these conferences makes lifelong colleagues and friends. There a spirit of learning, and cooperation. We want to help each other, teach each other, learn from each other. The Ruby community is an incredible group of people of welcoming, kind, and supportive peers. Without the community, Ruby couldn’t be what it is.

There’s a lot of reasons to like ruby. And there’s so many things that rubyists love. I haven’t covered everything. But Ruby’s primary features are joy and community. That’s hard to beat.

Do you love Ruby? Tell me what you love about it

The Technical Decisions Behind My Website Redesign

2023-12-11T00:00:00+00:00

Last week, I deployed a complete redesign of my personal website. I wrote briefly about the design decisions and iterations that went into the redesign. But, I also wanted to talk about the technical decisions of this redesign.

I took this as an opportunity to explore some new technologies and methodologies in web development. I really enjoyed the process. I started this work by bringing all my dependencies up to date. Then I started switching various gems out. Let’s talk about my tech stack:

Bridgetown

My website is built using Bridgetown. Bridgetown is a static site generator written in Ruby. It started as a fork of Jekyll, but has since been updated with modern features and tools. I really enjoy it. It’s really familiar if you are an experienced Ruby programmer. For this redesign, I started by bringing Bridgetown up to date with the latest version.

I changed some of the default configurations. I chose to switch from the default Liquid templates to Embedded Ruby(ERB). When I used Jekyll, I used Liquid templates extensively. But, one of the big decisions I made last year was to switch to ERB. I was already using ERB in Rails apps and i thought it made the switch between the two easier.

Vanilla CSS

For some time now, I’ve been wondering if the marginal utility of Sass is worth it. A lot of the features that made Sass(and SCSS) so great are now part of the CSS specification. And in a lot of cases, they’re better natively. For example, One of the big features of Sass early on was support for variables. but Sass variables are procedural. They are calculated at compile time, which means they can’t be changed or modified at runtime.

In contrast, CSS custom properties are part of the standard. They can have different values at different scopes. They can be accessed and manipulated by Javascript in the browser and they are more declarative. They have so much more power than Sass variables. One of the big concerns with them used to be browser compatibility. But, all the big browsers have supported it for years now.

CSS Custom properties also make things like dark mode a cinch to implement. You can decide your palettes and switch them redefining the variables. After deploying the redesign, I decided to add dark mode and it was incredibly easy thanks to CSS custom properties. All I had to do was change the variable declarations within the scope of dark mode.

Other feature, like nesting are also supported by CSS natively now. This one has less browser support, but since I’m using PostCSS for compilation, I can use it and then it will get compiled down to a format that is supported browsers.

With all of this in mind, I decided to remove Sass from my personal website and use vanilla CSS. This decision turned out to be great from both a dependency and developer experience perspective.

CUBE CSS and Open Props

When I start new projects, I like to pick something that I want to get better at. This time, it was CSS. There are so many methodologies for how CSS should be organized and written. From design methodologies like Block-Element-Modifier to full blown utility first frameworks. There’s no shortage of ideas about how best to style HTML.

For my personal website, I chose to pair Andy Bell’s CUBE CSS methodoloy with Open Props.

CUBE CSS is a CSS methodology that aims to be progressive and scalable. It focuses on starting with good HTML styling. Then, it organizes the rest of your styles into Composition, Utilities, Blocks, and Exception. One of the big benefits of it is that you can write much less CSS. It sorta feels like getting the best of everyone’s ideas. Starting with HTML styling is like starting with class-less CSS. It gives you a great starting point for your site. Then you layer on Composition. The composition is the set of styles that determine how content flows on the page. Bell even calls this section .flow in his examples. CUBE also advocates utilities. Utilities are one-off classes that do one thing really well. Blocks are what you think of when you think of the block in BEM. And then you have Exceptions. One thing I like about the exceptions of CUBE is that they use data attribute selectors, which facilitates the use of state machines in your CSS.

I coupled CUBE CSS with Open Props, a framework(might be a strong word) of custom properties with standardized colors, sizes, typography, animations, and much more. They fancy themselves a “sub-atomic” CSS framework, which I think is clever. Open Props dramatically sped up my development. It was also such a joy to use. I like the way the custom properties are defined. It’s easy to use them in your styles.

These two things led me to write much less CSS in what I hope will be a more maintainable codebase.

Joy

One of the biggest things I wanted with this redesign was to find joy in building my personal website. I picked things that were interesting to me, and also matched a lot of my web and software design philosophy. There’s a lot of joy in this redesign.

One of the biggest strengths of the Ruby community is that we strive for programmer happiness. It’s an underrated value and one that often gets us mocked by our peers in other communities. This redesign was so much fun and I loved working on it. That’s perhaps the most important choice I made for this project.

Have any questions or want to share your website design story? Drop me a line

Redesigning My Website

2023-12-04T00:00:00+00:00

Yesterday, I merged a redesign of my website and so far, people seem to really like it. This was a multi-week project to bring some new life to my website and fix some accessibility and technical issues. I also wanted to explore some modern CSS features. This was a really fun project and I think the new site is much better than the old one.

I started by bringing the code as up to date as I could. I was a version behind of Bridgetown’s latest release. Thankfully, the upgrade process was painless. 😊 I also took the time to upgrade all of the node modules I was using before evaluating the technical choices for the site going forward.

I like to start projects like this by asking people for feedback on what I already have. One piece of feedback I got on the previous version of the site is that people really enjoyed the simplicity of it. It was the thing everyone I asked told me not to change with the redesign. I got many compliments on how good it was on phones.

So I wanted to make sure I kept that simplicity as I worked through the new design. I removed the list of blog posts from the main page and made it a simple landing page where I introduce myself to the reader.

I experimented with quite a few things while working on the redesign. Originally, I was going to leave the blog posts, but just have it be a list of links. I also wasn’t sure about the color scheme. I tried several things before landing on the subtle mix of purples that ended up on the site. I tried building a job for the contact form that would create an email thread with both myself and the submitter. Then, I abandoned that for the much simpler solution of including a mailto link.

There was a lot of that kind of exploration. One thing that never ceases to amaze me is how much work simplicity is. There are so many simple elements of my new website, but landing on those elements took quite a few revisions and feedback cycles from friends.

There’s still a few things I want to do. Dark mode had been on my list, but I ended up putting it off for a bit. I also have some cool ideas about how I’d like to present my Resume page, but I’m still working through them.

Overall, I’m very happy with how things turned out. It feels so much more alive now. I fixed a bunched of accessibility issues and got to exercise my CSS skills. I hope you enjoy the new site. Feel free to drop me a line with feedback.

Dotbot Is Really Nice

2023-08-23T00:00:00+00:00

I LOVE looking at other people’s dotfiles. There’s something great about looking at how someone has set up their development environment, taking inspiration from them and learning new things. For example, I recently learned that in Neovim there’s a setting for using the system clipboard for yank and paste. I’ve been using a separate keymap for interacting with the system clipboard for years. I enabled this setting and it’s amazing. Now, when I yank text in Neovim, I can paste is into a slack channel and it just works!

I also love tinkering with my own dotfiles. Every so often I’ll look over things and add some conveniences like new aliases, or keymaps for Neovim. I’ve also created functions to make certain things easier(like automatically cd-ing into a git repo after cloning it).

Over the years, I’ve added various scripts to handle installing, linking, and setting up my dotfiles. These are mostly hand rolled shell scripts that link my dotfiles, install the applications I use, and configure git and Neovim on a new machine. My goal is to be able to run a single command, walk away, and come back to a fully set up machine.

It’s never quite worked that way, however. I’ve run into issues with the installer many times. These small quirks sent me debugging the scripts on every new machine setup.

I’ve written before about how I don’t consider myself a power user. While making a series of changes to my dotfiles this weekend, I decided to retire my aging install scripts in favor of using a ready made dotfiles manager. I chose to use Dotbot. Reader, let me tell you: Dotbot is really nice!

Dotbot is a little bit like ansible, but way lighter weight. It uses a YAML file to configure how your dotfiles should be linked in your home folder.

You install in into your dotfiles repo as a git submodule:

git submodule add https://github.com/anishathalye/dotbot
git config -f .gitmodules submodule.dotbot.ignore dirty

And copy the install script into your dotfiles root folder:

cp dotbot/tools/git-submodule/install .
touch install.conf.yaml

Since everything is configured using a YAML file, it makes understanding all your linked files really simple. For example, this is one of my configuration files:

- defaults:
    link:
        relink: true

- clean: ['~']

- link:
    ~/.aliases: aliases
    ~/.config/nvim: nvim
    ~/.gitignore_global: gitignore_global
    ~/.nvmrc: nvmrc
    ~/.ruby-version: ruby-version
    ~/.zsh_functions: zsh_functions
    ~/.zshenv: zshenv
    ~/.zshrc: zshrc

The link section sets up symlinks to various files and folders. The key is the target location and the value is where the link points to.

I’m also using a plugin called dotbot-brew that handles Homebrew packages as part of the Dotbot configuration. This is what my configuration for Homebrew looks like:

- install-brew: true

- tap:
    - homebrew/cask-fonts

- brew: 
    - neovim

- cask:
    - font-fira-code-nerd-font

- brewfile:
    - brew/home.brewfile

I set up my taps, packages and the brewfile from my previous dotfiles setup. This lets me have a single command to install all the packages I need.

So far, everything is working really well. I like Dotbot. It’s really simple to set up and it just works the way I expect. Sometimes you have to discard your custom stuff and use something off the shelf. I’m glad I could do that for my dotfiles setup.

I Miss Cucumber

2023-08-08T00:00:00+00:00

I might be getting old. The other day, I was chatting with a coworker and waxing nostalgic about various tools and methods that I miss. The conversation had a whole “back in my day” vibe. Which, you know, I think I should just lean into at this point. Anyway, we started talking about Cucumber and it made me a little sad that the community had moved on from it.

Cucumber is a Behavior Driven Development framework that lets you write acceptance style tests in the form of a user story. You might write the following test for what happens when a user logs in:

Feature: Sign In
  Background:
    Given a user exists

  Scenario: a user signs in successfully
    When the user visits the sign in page
    And the user enters their username
    And the user enters their password
    And the user clicks submit
    Then the user is routed to the dashboard

Each step in that example would be defined like this:

module SignInSteps
  step "a user exists" do
    @user = User.create(
      username: 'alice',
      password: 'password'
    )
  end

  step "the user enters their username" do
    fill_in 'Username', with: @user.username
  end
end

Cucumber has a few advantages. The syntax reads like a user story. It puts you in the mind of the user and that’s a powerful framework to think in. This can help you codify your requirements in the same language as the customer who will use and talk about your product.

Having that language helps you build a shared understanding of your software. What do we mean when we say “the user fills in their username?” Using a tool like cucumber, you can write that step in code, run it in a browser and make sure the whole team agrees that you accurately captured the behavior.

So what happened to cucumber?

Cucumber was sold in part based on its human readable nature. The promise was that lay people could write acceptance tests. You could give a product manager or a customer service representative a list of steps and they could assemble them, filling in steps for missing functionality that would then be fleshed out by developers.

That didn’t happen. Instead, developers wrote all the code. Since developers were used to writing and understanding code, the extra tooling to make BDD style frameworks possible seemed like unnecessary overhead. It was just as simple to write all the same acceptance style code without the fancy domain specific language.

Cucumber is still around. It’s still being worked on and developed. But, the industry has moved on. That makes me sad. I really do miss it. I think we gave up something great when we stopped using Cucumber.

I miss how it forced me to think in real world terms. It forced me to put myself in the customer’s shoes and write down how the system should work from their perspective.

I miss how easy it was to write new acceptance tests. Over time, you build a library of steps and then composing new tests is like writing a story out of precomposed sentences.

I think Cucumber sparks joy. At least it did for me. And I miss using it.

Joining The Linear Side

2023-07-04T00:00:00+00:00

I’m standing at my desk writing this blog post and all I can think about is how great this keyboard feels. I’m falling in love with this keyboard: the buttery smooth travel of the keys, the satisfying thock as my fingers hit the end of travel. For the first time, I enjoy typing on a linear switch. This keyboard is using the Gateron Milky Yellow Pro switches and they feel so nice. I just want to keep using it.

Let’s back up.

Back in 2016, I joined Sphero. Everyone there had mechanical keyboards, while I was used to the Apple Magic Keyboard. On my first day, the Director of Engineering asked what kind of keyboard I’d like to use. I didn’t know anything about mechanical keyboard, so I told him I wasn’t sure. He invited me into his office to pick one out from our vendor. This was my first introduction to mechanical keyboards. Prior to this I didn’t know what “linear,” “tactile,” and “clicky” meant. I asked him for advice and he said, “a lot of us are using linears.” So, I picked the Cherry MX Red and we placed the order.

I worked at Sphero for 18 months and in that time, I came to hate that keyboard. It was so hard to type on. I missed letters and typed gibberish accidentally. The big problem for me was that I was never sure if I’d actually hit the key. I left that job with a strong aversion to linear switches.

When I purchased my next mechanical keyboard, I picked a strong tactile switch, the Cherry MX Clear. This keyboard was much better. It had a noticeable bump and that meant that I typed much more confidently. I very rarely had typos and I was more accurate in hitting the keys.

Prebuilt mechanical keyboards can only take you so far. I started to want things that I couldn’t get buying off the shelf. I wanted a quieter keyboard. I wanted to try something other than a Cherry switch. Most of all, I wanted a project. Something I could pour myself into. So, I decided to build my own keyboard. I chose to again go with tactile switches. This time, silent switches: the Zilent 67g switches. These switches also had a noticeable bump and I could feel when the switch actuated. But, I made several mistakes with that first build. I spent significant money on the switches, but spent no money on stabilizers, opting to use the ones that came with my kit. On top of that, I didn’t mod or lube the stabilizers. So while my keys were whisper quiet, the space bar, return, and shift keys were rattly and annoying. To make matters worse, I had opted to buy a solder kit instead of a hot swap kit. So fixing this would be a huge endeavor.

Enter my second(and current) build.

For this build, I opted for a hot swap board. And I bought the Durock V2 Stabilizers. I was looking for a lighter switch and opted for the Zilent 62gs. But, they weren’t in stock. So, I bought a temporary switch, the Halo Drop Clears with the intention to swap them out when the Zilents were back in stock(spoiler alert: I’m not doing that).

When I assembled the board, I was surprised at the feel. I couldn’t feel the bump at all. I was sure they’d sent me the wrong switch. So, I decided to take one of the switches apart. There was a bump. I just couldn’t feel it while typing. Over the next week, I was able to pick up the bump. But, it was so much softer than I was used to.

I decided to buy a different switch and figured I’d give linear another shot. After all, this was all a stopgap until I could get the real switch I wanted. I was looking for a budget friendly linear and I picked up the Gateron Milky Yellow Pro. They were pretty cheap at 23 cents per switch and they came pre-lubed so I didn’t need to make a big time investment to lube them myself.

Over a month later, I’ve really come to love this switch. It’s smoother than any switch I’ve ever used. It’s also really comfortable to type on. I find myself wanting to sit at my desk a lot more because the typing experience is borderline addictive. The sound of the keyboard is also really pleasing.

While typing on it, I’m’ ever presently aware of how good the keys feel, how satisfying the sound is and how smooth the travel is. And what’s more, these switches are really reasonably priced. I’ve even been researching other linear switches. After the last six weeks, it’s safe to say I’ve finally joined the dark, buttery smooth side that is linears.

I can’t say that I’ll never go back to tactile switches, but I think I finally gained an appreciation for the smoothness of linear switches. What switches are you using?

Introducing Darklight.nvim

2023-05-22T00:00:00+00:00

I made my first lua plugin for Neovim! It’s called Darklight.nvim and it makes it super simple to switch between dark mode and light mode colorschemes in Neovim.

About a year ago, I switched my whole Neovim setup to Lua and stopped sharing the same configuration with Vim. This was such a breath of fresh air. Lua is a fun little scripting language and it made configuring Neovim a delight. But I haven’t created any plugins with it until now.

Darklight is an extraction of some setup that I’d had in my own Neovim config for a while. When a friend asked me how I’d done the color switching, I decided to extract the relevant code into a plugin and add some configuration around it.

The bulk of the work in making it a plugin was setting up the Config object. There was some validation that was necessary as well as figuring out how to gracefully fallback in situations where the configuration was invalid. I added a Lua table for the Config object and made a function that validated the passed in configuration.

With that, Darklight was born.

Darklight has three different modes, background, colorscheme, and custom. Background is the simplest mode. In this mode, Darklight will chang the background setting in vim between “dark” and “light.” Because many themes already support light and dark modes, this is the simplest way to use Darklight.

In colorscheme mode, Darklight will switch between two completely different colorschemes. And in custom mode, you can provide callbacks that will let you completely control the switching behavior. You can learn more on GitHub

This was a fun little project and I’m happy to share this with the Neovim community. I have a few ideas for others features that I want to add, but the core pieces of functionality are pretty solid. After this experience, I look forward to making other plugins in the future.