
The world of software engineering is expansive and constantly growing. Trying to keep up with changes to hardware, software, languages, frameworks, etc. can be exhausting. For this reason it may seem like our best option as developers is to specialize and focus on a particular area. For some, this may mean focusing on frontend or backend technologies and for others the specialization make come in the build and deployment processes or cloud architecture and infrastructure. No matter the area of specialization the end result is a more fine-grained focus on a smaller surface area of topics.

Specialization is surely a great option, but we can also aim to be generalists as well. Having a general knowledge on multiple areas or domains can be a huge asset for an individual or team. The ability to tackle any problem that is thrown at you is invaluable. The "jack of all trades" developer may not have a deep understanding or expertise in a single area, but that is overcome by having a broad knowledge of multiple areas.

In my opinion it is best to try to sit somewhere in between a specialist and a generalist. In my career I have found that periods of specialization can be very rewarding, while also leading to a bit of burnout if done for too long. When periods of generalization have been sprinkled in over time, I've found myself being reinvigorated to solve a new set of problems and challenges that I wasn't facing during times of specialization.

No matter what category you fall in always remember that there is more to be learned and new challenges to be solved one way or the other. Getting bogged down in specializing on a specific technology? Look for opportunities to take on new problems in a different area. Feel like you are being spread to thin working on too many different areas? Aim to focus on a subset of those areas to really deepen your knowledge without worrying about all the extra stuff. Who knows maybe what we learned while specializing in one area will have a profound impact on the way we approach problems in a completely different technology.


These days software developers are categorized into two common buckets, generalists and specialists. Neither category has an inherent advantage over the other and often times the pros and cons of a categories are contextual. In this post, I'm going to share my current thoughts on these categories and how floating between them has impacted my career.

Some Thoughts on Specialization


Over the past few months, Neovim has become my go-to editor for all of my free time/side project coding needs. There have certainly been hurdles to overcome, but I enjoy the experience and coding environment that Neovim provides. As I've continued to expand my Neovim understanding and environment configuration, I've been looking for more and more ways to integrate Neovim into my .NET development workflow. I've written a couple of posts about .NET development in Neovim. One for [general environment setup](https://aaronbos.dev/posts/csharp-dotnet-neovim) and another for [Roslyn/.editorconfig](https://aaronbos.dev/posts/dotnet-roslyn-editorconfig-neovim) integration. If you don't have your local development environment for Neovim setup yet, I would highly recommend checking out those posts. With all of that in place, we should be ready to configure Neovim for the ability to run our application with a debugger.

First, I think it's valuable to talk about the plugin that makes this all possible. The only plugin that we need to install for debugging in Neovim is nvim-dap. I would highly recommend reading more about nvim-dap in the GitHub [repo](https://github.com/mfussenegger/nvim-dap), but at a very high-level nvim-dap is a debug adapter protocol client implementation for Neovim. Nvim-dap provides the ability to run an application with a debugger, add breakpoints, step through code, inspect scopes, and much more. Neovim 0.8.0 is the recommended version for using nvim-dap, but the nightly build and 0.7.2 are also supported. Nvim-dap is a generic implementation than can plug into almost any debugger that follows the standard protocol. For this post, we are going to be focused on the use of nvim-dap for debugging .NET applications. Let's start with a list of steps that need we'll be going through.

1. Install nvim-dap plugin
1. Install netcoredbg adapter
1. Configure nvim-dap to use netcoredbg
1. Install and configure dapui
1. Debug our apps 😎

## Install nvim-dap

Nvim-dap can be installed just like any other Neovim plugin. I use Packer for plugin management so the install command looks like this. For the full installation, documentation check out the README [here](https://github.com/mfussenegger/nvim-dap#installation)

```
mfussenegger/nvim-dap'
```

## Install netcoredbg

We now have nvim-dap installed, but to make it useful for .NET development we need to install a debug adapter. In this case, the adapter is [netcoredbg](https://github.com/Samsung/netcoredbg). For installation, we can go to the releases page and download the latest release. At the time of writing the latest release is 2.2.0-947.

![netcoredbg-releases](https://res.cloudinary.com/aaron-bos/image/upload/v1667357011/SCR-20221031-upu_j88sos.png)

Once downloaded we need to unzip and move the netcoredbg executable and dependencies to a permanent location. I'm currently developing on a Mac and I chose `/usr/local/bin/netcoredbg`. Now we need to do a few things to make sure we can run the executable. First, we can run `chmod 744 /usr/local/bin/netcoredbg/*` to allow the current user to execute the files inside of `netcoredbg`. We also need to remove the quarantine label from the files since they were downloaded from the internet and Apple will not allow them to be run by default. I did this by running `find /usr/local/bin/netcoredbg/* | xargs xattr -r -d com.apple.quarantine`.

![netcoredbg-location](https://res.cloudinary.com/aaron-bos/image/upload/v1667357200/SCR-20221101-u89_ltd8ux.png)

## Configure nvim-dap

We now have nvim-dap and netcoredbg installed and are ready to configure nvim-dap to use netcoredbg. This step is very straightforward. The following code can be added to a lua block in `init.vim` or directly in a lua file that is part of the Neovim runtime path. I think the only dynamic piece of the code is to make sure the `command` field is referencing the correct location for the netcoredbg executable.

```lua
local dap = require('dap')

dap.adapters.coreclr = {
  type = 'executable',
  command = '/usr/local/bin/netcoredbg/netcoredbg',
  args = {'--interpreter=vscode'}
}

dap.configurations.cs = {
  {
    type = "coreclr",
    name = "launch - netcoredbg",
    request = "launch",
    program = function()
        return vim.fn.input('Path to dll', vim.fn.getcwd() .. '/bin/Debug/', 'file')
    end,
  },
}
```

With all of this done we now have a functioning debugging adapter for .NET Core applications in Neovim. With that being said the developer experience in the current state is a little clunky. We haven't set up any keymaps to perform actions like starting the debugger and setting breakpoints. We will go through that next, but if you'd like to give debugging a shot you should be able to run `:lua require'dap'.continue()`, which will prompt for the path to the `.dll` file to debug. Before going any further let's set up the keymaps for nvim-dap.

```
nnoremap <silent> <F5> <Cmd>lua require'dap'.continue()<CR>
nnoremap <silent> <F10> <Cmd>lua require'dap'.step_over()<CR>
nnoremap <silent> <F11> <Cmd>lua require'dap'.step_into()<CR>
nnoremap <silent> <F12> <Cmd>lua require'dap'.step_out()<CR>
nnoremap <silent> <Leader>b <Cmd>lua require'dap'.toggle_breakpoint()<CR>
nnoremap <silent> <Leader>B <Cmd>lua require'dap'.set_breakpoint(vim.fn.input('Breakpoint condition: '))<CR>
nnoremap <silent> <Leader>lp <Cmd>lua require'dap'.set_breakpoint(nil, nil, vim.fn.input('Log point message: '))<CR>
nnoremap <silent> <Leader>dr <Cmd>lua require'dap'.repl.open()<CR>
nnoremap <silent> <Leader>dl <Cmd>lua require'dap'.run_last()<CR>
```

As you can see from the remapping `<leader>b` is used to toggle breakpoints and `F5` is used to launch the debugger. In the screenshot below you can see there is a breakpoint denoted by the `B` in the lefthand gutter as well as the path to `EplStats.dll` in the status bar at the bottom of the window.

![debug-setup](https://res.cloudinary.com/aaron-bos/image/upload/v1667357011/SCR-20221101-sqs_hmeiao.png)

We are now at a point where the debugging experience is fully-featured, but maybe a little raw still. Next, we're going to configure the `dapui` plugin which will provide a more familiar debugging experience from a UI perspective.

## Install and configure dapui

The dapui plugin is installed like any other Neovim plugin, but it is dependent on nvim-dap being installed as well.

```
use { "rcarriga/nvim-dap-ui", requires = {"mfussenegger/nvim-dap"} }
```

I think the default setup for dapui is a great starting point for a familiar debugging UI in Neovim with a couple of caveats. In the configuration below there are a few lines at the end that make sure the dapui windows are open and closed when the debugger is launched and terminated. The following snippet can be added to the init.lua, a lua section in init.vim, or another lua file in the runtime path.

```lua
local dap, dapui = require("dap"), require("dapui")

dapui.setup({
  icons = { expanded = "▾", collapsed = "▸", current_frame = "▸" },
  mappings = {
    -- Use a table to apply multiple mappings
    expand = { "<CR>", "<2-LeftMouse>" },
    open = "o",
    remove = "d",
    edit = "e",
    repl = "r",
    toggle = "t",
  },
  -- Use this to override mappings for specific elements
  element_mappings = {
    -- Example:
    -- stacks = {
    --   open = "<CR>",
    --   expand = "o",
    -- }
  },
  -- Expand lines larger than the window
  -- Requires >= 0.7
  expand_lines = vim.fn.has("nvim-0.7") == 1,
  -- Layouts define sections of the screen to place windows.
  -- The position can be "left", "right", "top" or "bottom".
  -- The size specifies the height/width depending on position. It can be an Int
  -- or a Float. Integer specifies height/width directly (i.e. 20 lines/columns) while
  -- Float value specifies percentage (i.e. 0.3 - 30% of available lines/columns)
  -- Elements are the elements shown in the layout (in order).
  -- Layouts are opened in order so that earlier layouts take priority in window sizing.
  layouts = {
    {
      elements = {
      -- Elements can be strings or table with id and size keys.
        { id = "scopes", size = 0.25 },
        "breakpoints",
        "stacks",
        "watches",
      },
      size = 40, -- 40 columns
      position = "left",
    },
    {
      elements = {
        "repl",
        "console",
      },
      size = 0.25, -- 25% of total lines
      position = "bottom",
    },
  },
  controls = {
    -- Requires Neovim nightly (or 0.8 when released)
    enabled = true,
    -- Display controls in this element
    element = "repl",
    icons = {
      pause = "",
      play = "",
      step_into = "",
      step_over = "",
      step_out = "",
      step_back = "",
      run_last = "↻",
      terminate = "□",
    },
  },
  floating = {
    max_height = nil, -- These can be integers or a float between 0 and 1.
    max_width = nil, -- Floats will be treated as percentage of your screen.
    border = "single", -- Border style. Can be "single", "double" or "rounded"
    mappings = {
      close = { "q", "<Esc>" },
    },
  },
  windows = { indent = 1 },
  render = {
    max_type_length = nil, -- Can be integer or nil.
    max_value_lines = 100, -- Can be integer or nil.
  }
})


dap.listeners.after.event_initialized["dapui_config"] = function()
  dapui.open()
end
dap.listeners.before.event_terminated["dapui_config"] = function()
  dapui.close()
end
dap.listeners.before.event_exited["dapui_config"] = function()
  dapui.close()
end
```

With this configuration in place, when the debugger launches we should see a UI that looks something like this. The default dapui configuration is equipped with call stacks, local scopes, console output, and active breakpoints.

![ui-example](https://res.cloudinary.com/aaron-bos/image/upload/v1667357011/SCR-20221101-txh_ka7b4k.png)

## Debugging demo

If you've made it to this point, congratulations! Configuring a debugging environment in this way can be a long process and it's not always straightforward. In the gif below you'll see the debugging experience in action. Notice the arrow in the lefthand gutter, which indicates the current line that the debugger is paused. As you can see from the button press hints, `F10` is used to step over and `F11` is used to step inside of methods.

![debug-demo](https://res.cloudinary.com/aaron-bos/image/upload/v1667357215/csharp-neovim-debugging_hxrjed.gif)

This post is a quick and simple introduction to this debugging configuration, but I would highly recommend checking out the documentation for nvim-dap and dapui for more advanced configuration and customization.


As a software developer debugging skills are invaluable. Over the years debugging tools have evolved to become an integral part of the development toolbox. In this post, we are going to look at how we can configure a debugging experience for .NET code in Neovim. Let's dive in!

Debugging C# in Neovim with nvim-dap


## How GitHub keeps tokens safe

There are several measures that GitHub takes to keep tokens safe in repositories. This blog post is going to be focused mainly on GitHub API access tokens and storing them in our source code. If you'd like to take a look at the full documentation on GitHub API token security, you can check it out [here](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation). I'd like to start by saying that it is almost always best to err on the side of caution when dealing with any sort of tokens or secrets in code. This means keeping the tokens out of code that gets committed to source control and instead using environment variables and/or key vaults.

With that being said this post is going to be focused on the scenario of committing a GitHub API token to a public repository and pushing the commit up to GitHub. I was recently playing around with GitHub's GraphQL API, which requires a token for access. For my purposes, I was only concerned with **reading public data** via queries provided by the GitHub GraphQL API. Based on the documentation **at the time**, it was my understanding that an access token that is granted no scopes could be freely committed and pushed to a public repository because it only provided read access to public data.

As I began testing and using the GraphQL API in a test app, I noticed that every time I pushed code to the remote on GitHub that the GraphQL requests would begin to fail. After each push, I didn't receive any sort of notification or email about a token being revoked, but I did notice the token was being deleted from my account. After doing some research, I finally found the token security article I linked to before, which laid out the behavior that I was expecting. Public access tokens with no granted scopes should not be automatically revoked.

> OAuth tokens and personal access tokens pushed to public repositories and public gists will only be revoked if the token has scopes.

I was able to confirm the deletion of the API tokens by GitHub via the Security Log page, which is kind of hidden away unless you know where to find it. If you are logged into GitHub, you should be able to access it via [https://github.com/settings/security-log](https://github.com/settings/security-log). If the GitHub system revoked a token due to it being pushed to a public repo, you would see a log by "GitHub System" of the type `oauth_authorization.destroy`. This is the only indication of a token being removed by the system.

![security-log](https://res.cloudinary.com/aaron-bos/image/upload/v1666313877/Screen_Shot_2022-10-20_at_7.40.08_PM_lkbatc.png)

At the time this behavior was inconsistent with the documentation provided by GitHub, so I reached out via their support channel which led to them updating the documentation to its current state indicating that ALL GitHub access tokens, regardless of granted scopes, will be deleted when pushed to public repositories. The reason for this **updated** behavior is that classic Personal Access Tokens can be updated with scopes after they have been created. This is not the case with current access tokens. If scope changes are needed, a new token needs to be created.

So with all this being said, I was surprised initially by GitHub's behavior and its contradiction of the documentation, but after reaching out to support and the documentation being updated I completely understand the reasoning for this security. More than anything this was probably just another reminder to avoid taking shortcuts, even in little test apps because a simple mistake can lead to private tokens being leaked and used for unintended purposes.


I recently stumbled across some behavior by GitHub that was surprising at first, then reassuring once I understood the root cause. In this post, we are going to discuss a particular aspect of GitHub's security around keeping GitHub API tokens out of public repositories. Let's dive in!

GitHub Has Our Back With Token Security


## The Value of Being Uncomfortable

As I have progressed through my career there are definitely moments or periods when I could feel myself growing and learning. I have made a concerted effort at pushing myself beyond my comfort zone as much as possible because I truly believe it leads to more growth and learning at a faster pace. For example, I have volunteered to look into problems that I wasn't sure I could solve at the time, which can be an uncomfortable feeling. The problems have ranged from high-priority issues to long-standing bugs that required another set of eyes. Ultimately I don't think I gained the most from actually solving the problems themselves, more so from the journey to the solution. Putting myself outside of my comfort zone and committing to solving a problem that I needed to learn about to solve has led to two outcomes in my experience.

1. I'm surprised by my ability to solve the problem successfully
1. I learn a lot along the way

Let's talk about each of these outcomes in a little more detail. The first outcome of being surprised by one's ability occurs in situations where previous experience or knowledge contributes to developing a solution. This may not be direct experience or knowledge and instead the ability to effectively piece adjacent tidbits together to form a solution to a completely new problem. I can't say this outcome is the most common, but it has happened to me on several occasions.

The second outcome of simply learning a lot along the way is a little open-ended. In this outcome, a solution isn't guaranteed. We may come up against a problem that is out of our reach or requires contextual domain knowledge that we don't have yet. Even in cases where the problem isn't solved, so much can be learned along the way if approached with the right mindset. Getting outside of our comfort zone and into a situation where challenges are being faced at every step will inherently lead to learning new things. This new knowledge and skill can then be applied to the next problem and so on.

The main point I'd like to call out here is that neither of these outcomes is negative. Feeling uncomfortable isn't always fun and it can be challenging at the moment, but no matter the outcome we should be equipped with additional knowledge or skills that we didn't have before stepping out of our comfort zone.

A lot of this may seem obvious so far, but I can tell you that it is easy to get overly comfortable in a role to the point where challenges seem like roadblocks instead of hurdles to be overcome. With that being said, I think there are times when stepping out of your comfort zone may not be the best idea for the given situation. For example, in times when tight external deadlines or pressure are being placed on the team or individual. While I think there is still a lot of room for growth in this situation, it may be best to take a supporting role especially if there are others who are well-positioned to tackle the problem. In a case where others are well suited to take on the project, it may be best to view it as a learning opportunity. How does this experienced engineer approach these problems and what leads to their success and failure? These can all be learned along the way in a supportive role. In cases when there aren't others well suited to take on the problem, that is when we can step up and take the risk. As I said there are likely two outcomes with this risk-taking and neither of them is negative.

The world of software and technology is expansive and offers endless opportunities for us to learn and grow. This is what I love about my career and the best way that I have found to take advantage of this fact is by operating at the edges of my ability. Continually be willing to feel uncomfortable to grow personally and help the teams that I work with achieve success in whatever challenges we are facing.


In my opinion, the ability to learn and to continue to learn is one of the most important skills for software engineers to have. In this post, we're going to talk about the value of living outside of our comfort zone to positively impact growth and learning. Let's dive in!

Get Comfortable Being Uncomfortable


## What are Keycodes?

I've adopted Vim (Neovim and other Vim editor plugins for VS Code and JetBrains) within the past year and the most challenging aspect was learning all of the different keymaps and motions. I will say that I am still learning but have become pretty efficient with the foundational keymaps and motions in Vim. In my opinion, one of Vim's greatest strengths is the robust documentation and manual pages. If you want to learn to do something in Vim, I guarantee it is documented somewhere in the help documentation. I'm not going to say the information is always easy to find, but it is available if you're patient enough to search.

The power of Vim comes from the keyboard. The navigation and editing experience in Vim is different from almost all modern editors in that it prefers the use of the keyboard over the mouse. This difference in style can lead to a pretty steep learning curve and frustration. For me, the frustration early on came from not being able to understand the different keycodes listed in the documentation. For example, when the documentation for performing a specific action references the `<Leader>` or `<C-j>` key, what exactly does this mean? Understanding what these keycodes mean, will allow us to gain more knowledge from the Vim documentation.

## Keycode Reference

In this section, we're going to go through several keycodes that aren't immediately obvious (at least to me). Some of the keycodes are pretty self-explanatory, like `<Esc>` represents the escape key and `<Space>` represents the space bar. In the examples, you may see characters followed by `...`, which means that the keycode can be combined with other keys to perform a specific action. For example, we might see something like `<Space>-...` which means that the combination of the space bar and some undetermined subsequent key(s) will define the action.

- <Leader>: The leader key isn't exactly a keycode, but it is often referred to in documentation and provides a lot of flexibility for creating very custom keymap shortcuts.
  - By defaut, the leader key is mapped to `\`
- `<CR>`, `<Enter>`, `<Return>`: The enter key (`CR` stands for carriage return)
- `<S-...>`: The shift key
- `<C-...>`: The control key
- `<M-...>`, `<A-...>`: The meta or alt key. On Windows, this is alt and on macOS this is option.
- `<D-...>`: The command key (macOS only)

This list may seem small and pretty meaningless, but I can assure you that you will come across these keycodes in Vim and Vim plugin documentation. The power of Vim lies in the use of keymaps and shortcuts, so if you can master the fundamentals and understand how to learn from the documentation Vim will be a joy to use.

In the next section, we'll take a look at some examples of these keycodes as they are used with certain keymaps and plugins. Since I use Neovim, I'll be providing examples in both Vimscript and Lua. If you're not familiar with Lua, it is a great scripting language and also the default plugin language for Neovim. Neovim still supports Vimscript, but I've seen more and more plugins created using Lua lately.

## Keycode Examples

The examples below will be focused mainly on how to interact with Neovim configuration. While Neovim is _essentially_ backward compatible with Vim, there may be some differences. To test these examples out they can be placed in your `init.lua`, `init.vim`, or another configuration file if your environment is set up differently.

**Setting the Leader key**

As I mentioned previously the leader key is defaulted to `\`, but it is common for people to want to change it to a different character. In the examples below we are going to map the leader key to the comma key. This means that any keymapping that involves the `<Leader>` keycode will involve the use of the comma key instead of the default backslash.

```
" Vimscript
let mapleader = ","

-- Lua
vim.g.mapleader = ','
```

Using the [NERDTree](https://github.com/preservim/nerdtree) plugin as an example. If we wanted to invoke the `:NERDTreeFocus` command, with a keymap that involves our newly mapped leader key that would look something like this.

```
" Vimscript
nnoremap <leader>n :NERDTreeFocus<CR>

-- Lua
vim.api.nvim_set_keymap('n', '<leader>n', ':NERDTreeFocus<CR>, { noremap = true, silent = true })
```

Both of the above commands will result in a keymap the invokes `:NERDTreeFocus` when the combination of the `, + n` is pressed. If you'd like to learn a bit more about the Lua function used here to set the keymap, check out the documentation [here](<https://neovim.io/doc/user/api.html#nvim_set_keymap()>).

At this point, you should have a pretty good idea of the fundamentals of Vim keycodes and how to apply them when reading the help documentation.


Since diving into the world of Vim and Neovim, I've felt myself become more comfortable with the tool and its idiosyncrasies. One of the hurdles I faced early on was understanding the documentation for different keycodes. In this post, we're going to cover the common keycodes and the concepts around them. Let's dive in!

Hey! 👋

My name is Aaron Bos and this is my blog.

Recent Posts