A couple of weeks ago I decided to redo my Neovim configuration and lean into Lua. The goal was to optimize startup performance and improve usability.

Follow along with my neovim dotfiles repo

For years, I used Plug to manage my vim plugins, but after seeing TJ DeVries experiment with lazy.nvim, I decided to go all in!

By far, the biggest challenge was learning Lua 5.1. All the scripting languages I’ve used in the past (Ruby, Perl, Python) emphasize a “batteries included” approach. Lua, in contrast, felt like I had to assemble everything from tiny parts.

Once I got past the Lua hurdle, the rest of the conversion was straightforward. Most of the time I could swap out Vimscript with neovim Lua API methods via a regexp.

I’m pleased with the results. Startup time is faster, there are fewer weird bugs, and I understand all the configurations.

I was looking at my old development projects recently when I noticed that all of them predate 2005. In 2005, I started work at ePublishing as a Perl developer. In the past 17 years I’ve been:

• a Ruby and Rails developer
• VP of Software Engineering
• Chief Software Architect

In all that time, I’ve written hundreds of thousands of lines of code (maybe more than a million), but it’s locked away.

It’s a bit depressing that almost two-decades of creativity is forever hidden from view. It’s the curse of corporate development: we can write blogs, give talks, and prepare papers, but we can’t show the code itself. All anyone sees are shadows on the wall.

More companies should release their source code. Most of what we write is not the company’s crown jewels. Let people see how you solved that weird 3rd-party integration! Or how you monitor some obscure open-source service.

Every company is standing on a mountain of open-source code. Give back and let your developers have the opportunity to show off!

In a recent twitch stream, Gary Bernhardt showed a bit of behind-the-scenes in how he prepares his development environment for recording a screencast.

One of the tools he showed in passing was gem_home by Hal Brodigan.

gem_home is a simple script that manipulates Ruby’s GEM_HOME and GEM_PATH environmental variables in order to keep separate ruby gem locations.

By using gem_home, there is no longer a requirement to prefix all ruby commands with bundle exec. All the gems for a project are local to the project, which eliminates conflicts that might arise when gems for multiple projects are mixed together in one location.

Eliminating the need for bundle exec allows commands such as rspec to execute much quicker!

Unfortunately for me, I recently switched over to using fish shell from ZSH. Hal’s gem_home only supports Bash and ZSH. 🙁

One nice thing about gem_home is how simple and straightforward it is. In a few hours I was able to replicate its functionality as a fish shell compatible script!

• https://github.com/rjkaes/gem_home

If you’re using ruby and fish shell, I would highly recommend using my implementation of gem_home along with Jean Mertz’s wrapper around chruby. Both of these play well together.

As a remote worker in a rural community, I’ve found it difficult to find other technology workers in the area. After speaking with Brett, we decided to start the Norfolk Techies Slack group.

If you’re a technology worker in the Norfolk County area please contact Brett or myself for an invitation link.

Today I needed to prove that my Rails controller method deleted a cookie. After Googling for the answer (without success), I came up with the following.

Within your controller:

cookies.delete('cookie-to-delete')

In your controller spec you can check that the cookie was deleted with:

expect(response.cookies).to include('cookie-to-delete' => nil)

Rails sets the cookies to be deleted to a value of nil. By checking for the presence of both the cookie name with a value of nil, you can ensure your controller code deleted the cookie.