Forem: Ilai Fallach

A 60% keyboard is good for you

Ilai Fallach — Wed, 28 Sep 2022 12:14:50 +0000

(The cover photo was generated using MidJourney)

A few years ago, at one of the companies I've worked for, I came across a proliferation of mechanical keyboards and in particular, 60% keyboards, and I bought one for myself.

Since then, I've used that 60% mechanical keyboard, and I can't go back. However, I've noticed that like many other practices in software development, it's easy to stay in the comfort zone of what we already know, since there are so many things to learn.

As I wrote in my introductory blog post, developers are lifelong learners. Therefore, I hope that sharing my own experience will encourage you to try something completely different. This might seem difficult at first but will improve your typing experience and productivity over time.

Let's start with the basics.

What's a mechanical keyboard?

A physical keyboard that uses an individual spring and switch for each key (PCMac)

Wait, so what isn't a mechanical keyboard?

The most widely produced keyboard type is called Membrane (although there are other types as well):

A physical keyboard whose "keys" are not separate, but rather are pressure pads that have only outlines and symbols printed on a flat, flexible surface.

Some history

Initially, when keyboards were first produced, they were mechanical. As computers began getting cheaper, manufacturers looked for ways to make keyboards cheaper as well, and thus the membrane keyboard was created.

However, membrane keyboards have downsides to mechanical keyboards, and so in recent years, users with high requirements from keyboards (Gamers, Typers, Programmers, etc..) began using them again.

Here's a comparison by wepc.com:

Back to mechanical keyboards

The most important part of a mechanical keyboard is the switch type. There are 3 types: linear, tactile and clicky:

Linear (red, yellow, black) - are the quietest of all and the fastest to click on which makes them popular among gamers.
Tactile (brown, orange) - have a tactile bump that is felt on each key press.
Clicky (blue, green) - are the noisiest and produce a clicky sound when actuated.

(Source: steelseries.com)

Keycaps (the actual plastic above the switch), board type, and form (size) are also important factors of mechanical keyboards.

Let's talk about the form, then.

What's a 60% keyboard?

Keyboards have many custom forms as can be seen in the following graphic that shows some of them:

(Source and a great forms guide from keychron.com)

The full-sized is probably the "classic" keyboard, while a variation of 75% is roughly what we see on most laptops. From my personal experience, I'd say that most of us are comfortable with keyboards in the range of 75% to full-sized.

If we go down to 65%, usually the first thing that we lose is the function keys (F1, F2, ...).

But function keys are useful, and so an Fn key usually exists, that when held, will "switch" the functionality of the top row to the function keys:

ESC -> `
1 -> F1
2 -> F2
...

This is all still pretty sane since F keys are not very commonly used, so pressing an additional key from time to time to use the F keys is still within the "comfortable" zone.

When we go below 65%, though, things are starting to get "less comfortable" (and more interesting 😬). Perhaps the biggest change is the removal of arrow keys. These keys are so common, that it sounds insane to be able to work properly without them.

Today we're going to discuss the benefits of 60% keyboards, and why I think they are good for you :)

(My 60% keyboard)

Why is a 60% keyboard good for you?

TL;DR:

Faster switch from using the mouse to typing
For most people it's ergonomically better
Faster reach to all navigational keys
More compact
Cheaper

(1) Keyboard and mouse

Whenever we're typing, our neutral position of both hands is on what is called the home row keys, which are A, S, D, F for the right hand, and J, K, L, ; for the left.

Assuming you're right-handed, whenever you want to use your mouse, you need to move your hand from the home row keys to the mouse, as seen in the following graphic:

As we can, when working with a full-size keyboard, the distance is quite large. With a 60% keyboard, it looks like this:

This means that with a 60% keyboard, switching between 2-hand typing and the mouse is much faster (~half the distance!).

(2) Ergonomics

While it depends on your shoulder length, the average person needs to bend his hands outwards from their neutral resting position when using a full-size keyboard. A 60% or tenkeyless keyboard is almost always more ergonomic.

The following article seems to go really deep into choosing the right keyboard form for you: Keyboard Form Factor Guide / Ctrl.blog.

(3) Use navigational keys faster

A common feature in mechanical keyboards is the key mapping programmability. We can program keys to behave differently.

A specific capability is the "temporary layer switch", which allows a held key to change the entire keyboard's key mapping temporarily (as long as it's being held).

The following visualization shows my personal temporary layer key mapping. I chose the Caps Lock key as my layer switch key, as I rarely use this functionality anyway, and it's positioned nicely on the home row.

As you can see, all the navigational and Fn keys (+bonus media keys!) are now much closer to the home row, which keeps your hands in the same place even when using the arrow keys!

Note: It takes some time to get used to a new key mapping such as this. It took me 3 weeks to reach my regular working speed, and since then it had gotten better ^^

(4) More compact

Not much to add here really, it's just smaller, and therefore allows for more desk space and is much more portable.

(5) Cheaper

Fewer keys == Fewer materials == Cheaper (Assuming all the rest of the factors of the keyboard are the same).

When used at work

We've already covered that one of the characteristics of mechanical keyboards is that they are usually louder than their membrane counterparts.

While this can be considered an advantage if you like the sound of the typing, when working alongside others, it can become a life-threatening event (A few co-workers not-so-secretly expressed the desire to murder me when I used a clicky-switch keyboard for long enough periods).

However, there are insanely quiet switches that are even quieter than membrane keyboards.

We are now going to cover my current mechanical keyboard setup that I personally like (and is also very quiet).

My 60% keyboard setup

Prebuilt keyboard

My own keyboard setup is pretty simple. I originally bought a prebuilt budget keyboard that is quite customizable.

Let's breakdown the long title description of this keyboard:

60% - We know this one already ;)
RGB - Full Red-Green-Blue lighting on each of the keys, and is fully programmable with animations, etc...
hotswap switch - This means that the board allows you to pull out existing switches and replace them with others easily.
pbt keycaps - The type of the keycaps. This is a whole topic in and of itself, here's an overview.
programmable - There's software that allows configuring everything from keymapping and lighting to macros.
61 key poker layout - The keyboard has exactly 61 keys. "Poker" stands for an unofficial name of all 60% keyboards.
SmartMonkey iGK61 set2b - The exact model of the keyboard.

There are two customization options: the color of the keyboard and the switch model.

Purchase link

My first switches were the Kailh Box Whites. These switches are very clicky and while I absolutely loved the typing feeling they had (one of the best I ever tried), I needed something else for the office.

Silent Switches

After some research, I came across Gazzew's Boba U4 Silents switches.

It's magical how quiet these switches are!

I also really liked their typing feeling, and they are my current favorite switches for typing at the office.

GSA Keycaps

Next, I wanted to give some color to my keycaps. While I don't think they're the nicest looking keycaps out there, their "same-height" GSA profile (Yes, Keycaps layout is another thing you should be aware of 🙈) is really nice:

Purchase link

Programming the temporary layer

This keyboard has software that allows remapping the keys to enable the temporary layer as seen in the Use navigational keys faster section to improve productivity.

Download link

If you need any help with defining the mapping, then try this youtube video. Also, feel free to reach out!

That's it, folks! I hope that you've enjoyed this blog post. If you have any questions about mechanical keyboards or decided to learn more after reading this, please let me know by commenting here or reaching me directly at @ @ilai

Disclaimer: I'm a rather noob in the vast world of mechanical keyboards. There are awesome resources out there to further learn about mechanical keyboards. Youtube is a great starting point, just write "Getting started with mechanical keyboards" and get started (Just remember to open a stopwatch to stop you from a never-ending video wormhole 😉).

If you liked this content, consider signing up to my newsletter (it's free).

Originally published at https://buildstupidstuff.com.

One Config to Rule Them All

Ilai Fallach — Tue, 20 Sep 2022 19:52:04 +0000

So many configuration files

Every company I've worked for had dozens of repositories written in the same tech stack (either due to a micro-services architecture, or just many different types of projects, think a few backend applications, a CLI app, an open source project, etc...).

What all of these repositories had in common was a project-level configuration that was almost the same. Some examples are:

A CI/CD configuration: GitHub's .github/workflows/..., CircleCI's .circleci/config.yaml
An IDE configuration: VSCode's .vscode/ or Intellij IDEA's .idea/
A common linter/formatter configuration: .eslintrc, .prettierrc, .golangci.yaml, .pylintrc, ...
package.json scripts, .github/dependabot.yaml, .github/pull_request_template.md, Makefile

And the list goes on...

Whenever I wanted to make a change to such a configuration file, I had to open 10 or more pull requests in all of the different repositories, carefully copy-pasting the same changes, trying to stay focused (and sane) in the process to make sure I got everything changed correctly.

(Image created by this awesome bart chalkboard generator)

If we wanted to make 5 changes in 5 configuration files across 10 repositories, that would require 250 changes to be made just to update a configuration change!!!

Don't Repeat Yourself

One of the first principles we learn as programmers is Don't Repeat Yourself (DRY).

So how come we let ourselves rewrite the same configuration again and again in all of our projects?

Call me Sauron, but this drove me insane, and so I embarked on a quest to solve it.

Existing solutions

I'm not the first to tackle this problem and approach solving it. While looking for solutions, I found 2 interesting projects. Here are my opinionated thoughts on both of them:

mrm

A powerful tool that uses tasks written in javascript to maintain updates on shared config files intelligently.

👍🏼 Pros:

Powerful
Comes with predefined presets

👎🏼 Cons:

Complex and implicit (I don't want to write code if I don't have to)
Very oriented to the javascript ecosystem
Doesn't support syncing multiple repositories simultaneously
Doesn't support creating pull requests for the updates

cruft

A Cookiecutter compatible tool that supports initializing and updating project boilerplate.

A Cookie cutter is a tool that helps with creating new projects based on boilerplate templates.

👍🏼 Pros:

Builds on many good boilerplates (I personally don't like boilerplates, there usually isn't a one-size-fits-all and I like to get my hands dirty to make sure I understand the configuration)

👎🏼 Cons:

Doesn't support syncing multiple repositories simultaneously
Doesn't support creating pull requests for the updates
Has to be based on a cookie-cutter template

My requirements

When starting to think about a solution that would fit my needs, I had a couple of requirements in mind:

🌵 Stay DRY - Write a configuration once, and have it synced across many projects.
🤤 Keep It Simple Stupid (KISS) - Treat configuration snippets as simple text, not assuming anything about structure.
🙆🏻‍♀️ Allow flexibility, but not too much - Allow syncing whole files, or parts of them (currently, line-based).
🤖 Automate all the things - After an initial configuration, I want the solution to handle the rest.

Introducing Goplicate

Goplicate is a CLI tool that helps define common code or configuration snippets once and sync them to multiple projects.

(Made using https://gopherize.me)

It balances simplicity and flexibility by using comments to annotate blocks of configuration that we would like to sync. I've felt the 2 alternative solutions required too much of me to get started.

Disclaimer: I'm the author of Goplicate

Quick start in 4 simple steps

In the following simplified example, we'll sync an eslint configuration.

We'll end up having the following folder structure (full example here):

+ shared-configs-repo/
+   .eslintrc.js
  repo-1/
    .eslintrc.js
+   .goplicate.yaml
  repo-2/
    .eslintrc.js
+   .goplicate.yaml
  ...

Let's go!

1️⃣ Choose a config file that some of its contents are copied across multiple projects, and add goplicate block comments for the common-rules section of your desire:

repo-1/.eslintrc.js:

module.exports = {
    "extends": "eslint:recommended",
    "rules": {
+       // goplicate-start:common-rules
        // enable additional rules
        "indent": ["error", 2],
        "linebreak-style": ["error", "unix"],
        "quotes": ["error", "double"],
        "semi": ["error", "always"],
+       // goplicate-end:common-rules

        // override configuration set by extending "eslint:recommended"
        "no-empty": "warn",
        "no-cond-assign": ["error", "always"],
    }
}

2️⃣ Create a separate, centralized repository to manage all of the shared config files. We'll name it shared-configs-repo. Then, add a .eslintrc.js file with the common-rules snippet that we want to sync:

shared-configs-repo/.eslint.js:

module.exports = {
     "rules": {
          // goplicate-start:common-rules
          // enable additional rules
          "indent": ["error", 4],
          "linebreak-style": ["error", "unix"],
          "quotes": ["error", "double"],
          "semi": ["error", "always"],
          // goplicate-end:common-rules
    }
}

Goplicate snippets are simply the sections of the config file that we'd like to sync. In this example, we've also added the surrounding configuration to make it more readable, but it's not really needed.

3️⃣ Go back to the original project, and create a .goplicate.yaml file in your project root folder:

repo-1/.goplicate.yaml:

targets:
  - path: .eslintrc.js
    source: ../shared-configs-repo/.eslintrc.js

4️⃣ Finally, run goplicate on the repository to sync any updates:

This is only a simplified example. Let's see Goplicate's additional features.

Other supported features

A goplicate sync command to sync multiple repositories with a single command.
Support for checking out a new git branch, committing the changes, and opening a GitHub pull request (assuming GitHub CLI is installed and configured).
Template support using Go Templates with dynamic parameters.
Support for automatically running post hooks to validate that the updates worked well before opening a pull request.

Future Plans

Support for syncing from a remote source (a GitHub repository, etc...) to incorporate as part of a CI flow.
Support goplicating (😉) JSON files (they don't support comments so we'll have to do it another way).
Adding a documentation website with quick start examples for various use cases.
Adding CI integrations for the goplicate sync command to automate the opening of PRs for each update to the shared config repository.
Your next suggested feature 😁.

Goplicate is in the early stages of development - If you want to contribute, then feel free to open a PR or hit me up @ @Ilai Fallach

Conclusion

If you're maintaining many different projects with similar config files or a single project with many such repositories, then try Goplicate out - It literally takes 4 steps to integrate into your existing projects' setup!

What do you think about Goplicate? Leave a comment and share your feedback and thoughts 🙏

Originally published at https://buildstupidstuff.com

Building stupid stuff

Ilai Fallach — Tue, 13 Sep 2022 06:32:21 +0000

Building stupid stuff

Hi there, you yet non-existent readers 👋🏼

This is actually my 2nd attempt at starting a blog. The last time was over 7 years ago (If you want an intro to Neural Networks, then go ahead and visit my first and last post there).

A few questions I asked myself when writing this first post:

Why start a new blog instead of using the existing one?

I guess that it feels better to start with a clean slate. It's always easier when you have no history (Also, I don't really study or practice ML nowadays, so having my first blog post about Neural Networks feels weird to me, but maybe I'll re-post it here later).

Why write a blog at all?

I've read somewhere that, as developers, we are "life-long learners". Learning all of the time is great, and I feel that sometimes what I learn just piles up in my head and doesn't "process" well enough. I think that writing about things helps with that. I also figured that if I learn something that I didn't find answers to on our incredible Internet, then someone else might benefit from reading about it as well!

Another reason is to get more opinions about what I write and how I write about it; If I learn or build something, and someone has an opinion about it, then all I can do is learn from that and keep being challenged.

What is this blog even about?

I'm calling the blog "Build Stupid Stuff" since many of the things we all build are probably a bit "stupid", but for me, they all originated from some need and so I'm hopeful that the name will give me the motivation to share it.

So, I'll be writing about anything that I think might be useful, interesting or that I want feedback on.

To new beginnings! 🍾

(Hint: I really like Golang nowadays)