The Bug

The first bug I took on was Bug 1895394 - Remove dom.event.wheel-event-groups.enabled pref.

The bug contained sparse instructions. There was the title, “Remove dom.event.wheel-event-groups.enabled pref” and a single comment from the bug reporter:

It’s been enabled by default for about a year now (bug 1823700). Let’s remove this feature rollout pref

At this point I didn’t know what a pref was or what it would take to remove it.

Finding and understanding the relevant code

Initial Leads

There were a couple leads to follow: the pref name and the bug mentioned in the comment quoted above.

The text dom.event.wheel-event-groups.enabled in the title looked like code that might match exact text in a search of the codebase.

The bug mentioned in the comment was for enabling the pref by default in the main release rather than only on the nightly developer release. It was resolved by a patch changing a single line, in a file named modules/libpref/init/StaticPrefList.yaml.

Near the modified line, I found that string, dom.event.wheel-event-groups.enabled. Evidently, this was where the pref was defined and given a default value, true in this case.

Text search for the above string yielded results in other files. These included test configurations where the pref was forced to a certain value for test execution. It also occurred in comments across several files, in the context of stating that something would be the case if the pref was on or off.

Confusingly, this initial search did not yield any location where the pref was being read. So how was its value being used?

Moving beyond exact text search

The code matching an exact text search did not reveal how the pref was being read. To figure that out, I had to search for context in the surrounding code at a more zoomed out scale.

StaticPrefList.yaml is a very long file, but at the top it does contain some documentation in the form of explanatory comments. This yielded an answer, explaining getter functions that can be made available for prefs:

# The getter function's base name is the same as the pref's name, but with
# '.' or '-' chars converted to '_', to make a valid identifier. For example,
# the getter for `foo.bar_baz` is `foo_bar_baz()`. This is ugly but clear,
# and you can search for both the pref name and the getter using the regexp
# /foo.bar.baz/.

Aha! A search using the above regex formatting, dom.event.wheel.event.groups.enabled (- replaced with .) yielded what I was missing: the sites where the pref is accessed.

Zooming out again to find documentation

The bug description made it clear that the pref I was removing was a feature toggle. That was enough to work on the bug, but I was itching for a clearer general understanding of what a pref could be.

The comments at the top of StaticPrefList.yaml don’t really explain what a pref is in general, speaking of the specifics of static prefs. However, the presence of those detailed comments spoke to the level of documentation embedded in the Firefox code.

Hoping to find something to explain prefs in general, I poked around up the directory tree and found that the libpref module contained a folder named docs with a single index.md. Bingo!

That document began by summarising that prefs can be used as feature toggles, preferences, debugging flags, and more.

With an understanding of generally what prefs are, and specifically where the one at issue was defined and used, I was ready to begin a solution.

Removing the pref

Removing the pref involved a few tasks:

• removing its definition
• removing value overrides (as in test configs)
• removing any mentions of the pref in comments
• refactoring consumers to behave properly without accessing the pref value

Most changes were simple

Removing the definition was as simple as deleting that block of code.

In all cases where the pref was being forced to a value for a test, it was being set to true. Since this was becoming not just the default but the only behavior, these tests would continue to work the same way with the pref removed, so I was able to simply delete the code setting the pref to true for these tests.

Comments mentioning the pref would no longer make sense once it was removed. This required individual attention to each context to ensure the comments made sense and were properly formatted after mention of the pref was removed.

Refactoring consumers

Deleting use of the pref required some attention that the remaining code was left in the appropriate state given what you are trying to make permanent.

I’ll give an example in pseudocode. Let’s say this is where a pref is accessed:

if (some_pref() && other_condition) {
  // do stuff
}

If some_pref has been defaulted to true and this is being made permanent, the conditional simplifies to true && other_condition, which can be left as simply other_condition. if, however, it should be false, the conditional simplifies to false && ... which will never be true, and you would want to delete this entire conditional branch as it could never happen!

This pref was effectively being set true permanently, so I was able to take the former approach, effectively replacing any usage with true and simplifying accordingly.

In my patch I changed this:

if (StaticPrefs::dom_event_wheel_event_groups_enabled() &&
    (wheelEvent->mDeltaX != 0.0 || wheelEvent->mDeltaY != 0.0)) {

To this:

if (wheelEvent->mDeltaX != 0.0 || wheelEvent->mDeltaY != 0.0) {

Finalizing the patch

I locally ran affected tests to verify they continued to pass. After checking with the bug reporter if I should run any other tests, I submitted the patch for review and it was approved. After spending a month in the beta, it shipped to Release channel Firefox with Firefox 150.

Practices and strategies that helped me

I’ll finish off by rambling about some things I did that seemed to be pretty helpful. These aided my first contributions to Firefox, but none are specific to that context.

Creatively explore the context

You can get a lot of mileage out of simple text search, especially with some creative use of regex or partial strings (e.g. wheel.event.groups instead of the whole thing). Search for file names, search within files… Perhaps use a bespoke search tool such as Searchfox if it exists for what you’re working on.

Look for explanatory comments or documentation. Check the top of long files, check parent directories, check external documentation sites. Click through if your bug mentions another bug, to see if it offers helpful context. (Reminder: In Firefox development, “bug” is semi-synonymous with “issue” or “ticket”.)

Coding agents such as Claude Code can be a helpful option for a fuzzy search of a codebase, especially if you aren’t sure what to run exact text search for. Usual cautions apply: double check conclusions, etc.

Take notes as you get up to speed

I take notes in markdown, linking related files with [[Wikilinks]]. I’ve heard good things about Obsidian. For accessibility reasons I use VSCode, with an extension project called Foam.

Save relevant links: to the bug page, related bugs, documentation…

Paste in a list of the files you modified, and use that to help figure out what tests you should be running. Save a code block with the command you need to run your tests. Record which tests are passing or not.

Explain in your own words what’s going on.

Draft questions to ask a bug mentor or other developer, and record key parts of their answers.

I took copious notes. They were helpful to remember what I had tried, what I had figured out or was still unsure about, and where key information was. They also made writing these posts much easier.

Final Thoughts

This was a good first bug. As I discuss at the end of I Contributed to Firefox, it’s easier to get used to the development process if the particular issue you are solving isn’t a huge lift.

I went on to land a couple more patches with similar scope, and as of writing I have a fourth patch in review which is quite different.

I have enjoyed my contributions to Firefox, and intend to make more.

I have landed three patches so far, resolving bugs 1895394, 1899687, and 1950995.

Beginning in this post, I’ll write about some of the work I’ve done and Firefox development generally.

This post introduces the tools of the trade, how to pick your first bug, and some brief notes on what my first contributions were.

I continue this story in My First Firefox Patch.

The tools

The Firefox development ecosystem includes numerous tools, but some of the most important to understand are Bugzilla, Phabricator, Matrix, and Searchfox.

Bugzilla is the issue tracking system, where bugs (issues) are reported, discussed, and closed.

When you are working on a bug and have code to contribute, either as a work in process or ready for review, you push it to Phabricator. On Phabricator, code changes are discussed, reviewed, and approved.

For more general communication, community communication channels are Matrix chat rooms. There is an #introduction channel ideal for new contributors’ questions.

Searchfox is a bespoke search tool for the Firefox source code, useful both for finding things yourself and for linking specific lines of source code in discussions with other developers.

The Firefox source has a dedicated documentation site, including onboarding information for new contributors. See for instance Getting Set Up To Work On The Firefox Codebase.

Pick a “good first bug”

I will describe some basics of how to make your first contribution to Firefox. If you wish to contribute, refer to the Firefox source docs for thorough and up to date instructions.

Contribution starts with setting up your development environment. Use the bootstrap script to download the source code and install dependencies, confirm you can build and run it, and debug any issues that crop up.

To make your first contribution, you will probably want to pick an existing bug that has been described and categorized as a good first bug. You can filter on Bugzilla for the keyword good-first-bug, or browse Mozilla’s Codetribute, a site for finding your first bug.

One benefit of Firefox development happening out in the open is that you can dig into the source code and start thinking about a bug on your own without having to ask permission or make any commitments. Hopefully, a look around the bug description and relevant source code will give you a sense of whether it is a problem you want to tackle.

You can post on Bugzilla indicating that you are planning to submit a patch for the bug, thereby saving someone else the trouble of wasting time doing parallel work, but you can also wait until you have a solution, and then submit a patch.

As you work on a bug, there’s a good chance you will have questions, whether about general development processes or the particular bug. If there is a mentor assigned to the bug on Bugzilla, that’s a great person to ask questions about the particular bug. You can also ask in Matrix.

My first contributions were cleanup

The name “bug” may lead you to think that the issues tracked on Bugzilla are things that are broken or missing. They can be, but there are also tasks aimed at improving code that already works. You may even end up mostly deleting code, as I did in my first contributions.

The first three patches I landed all related to removing “prefs” that were no longer needed or wanted. A pref is a setting, such as for a user preference or a feature toggle. There are a lot of them, and some of them aren’t necessary anymore. This excess is enough of an issue that there is a meta bug collecting bugs about removing old prefs.

Deleting code may sound easy, and these were reasonably accessible bugs to start out with, but it does require some care to make sure that what you leave behind is correct. Even when taking a feature toggle that has been defaulted to on for years, and removing the prefs that allows it to be turned off, you may find it cropping up across the codebase in ways that can’t simply be deleted.

In future posts I will discuss some of the complications I ran into on these bugs.

Contributing is its own problem

I recommend deliberately starting with bugs that are easy enough that solving the programming problem of the bug is not a major obstacle. The development process is easier to learn if you aren’t also trying to solve a hard programming problem. Knock out some easy bugs while learning how to submit code and communicate throughout the development life cycle.

My first contributions to Firefox did not have earthshattering impact on the browser, but they made me ready to tackle harder problems.

The followup post My First Firefox Patch discusses the first bug I completed, telling the story of how I got my wits about me and sharing some of the lessons I’ve learned so far.

This post is about a study strategy and how that strategy relates to a specific course within the Core Curriculum of Launch School. The course in question is Object Oriented Programming (OOP), denoted in the Ruby track as RB120 (lessons) and RB129 (assessments).

This post is the product of a collaboration with fellow student Wook Kim, and its backstory begins with an insight he had after completing his RB129 assessments, especially the interview.

Wook felt something was missing in his preparation that would have solidified his understanding and fluency, but he had an idea of what would have helped. He eagerly described his proposal and urged me to try it as I prepared for the same assessments.

Having passed both assessments after putting into practice Wook’s idea, I can strongly recommend it.

Wook’s Insight

Wook described two struggles.

First, he felt that while he understood individual concepts, he didn’t have a comprehensive mental model to tie everything together.

Second, when asked to provide examples, he had to come up with them on the fly. His suggested study strategy would address both points.

The technique he proposed was to pick a real world domain I was familiar with and model it in Ruby using the OOP concepts from the course. Specifically, his idea was to create a single model covering all the concepts in one place. I’ll call this the “unified model.”

I will attempt to detail a “recipe” for this strategy, but I improvised every step of the way. It’s plausible that I didn’t make every best choice.

Furthermore, when I returned to Wook during my studies to clarify the specifications for an end product, he instead encouraged me to focus on “the why.” In this case, that meant focusing on building understanding rather than achieving a particular end product.

The point is not to write a Ruby file fulfilling a certain specification; the point is an integrated understanding of OOP concepts. If the path you take creates understanding, mission accomplished.

“Part of a Balanced Breakfast”

This was far from the only strategy I employed while studying for these assessments.

I can highly recommend this technique together with peer study sessions, TA sessions, and good old-fashioned curriculum review.

I err on the side of over-preparing for Launch School assessments. These were no exception, but they were my most comfortable assessment experiences yet. The unified model strategy was key in bringing me from tentative understanding to fluency and quick recall.

The Recipe

Think of my detailed instructions as more a record of my improvisation than dogma you must follow.

1. Domain: Choose something familiar. Workplaces, sports teams, and other human organizations are great candidates. Pick something where a general audience will be able to understand your snippets without extra context.
2. Individual snippets: In the context of your chosen domain, give a code example to illustrate XYZ concept. Can you model the positions on a team using class inheritance? How does encapsulation relate to a customer’s experience in a restaurant? What kind of collaborator objects would a PlayerCharacter class have in a roleplaying game?
3. Refine: Make your snippets better! I elaborate on this later. With many of these concepts, we are in the fuzzy zone of making design decisions with tradeoffs. Try things out!
4. Unify: Start with a checklist of the concepts you want to make sure your unified model illustrates. Then do it all in one big (hopefully not too big!) Ruby file. Refine further!
5. Practice: With little to no reference to your existing snippets, quiz yourself by writing from scratch code illustrations of different concepts from the course.

Why Metaphor? / What It Is We’re Doing Here

The Value of the Concrete

We deliberately use nontechnical nouns and verbs as the subjects of our metaphors when developing mental models.

The Launch School curriculum frequently illustrates object oriented concepts through examples such as types of vehicles or animals.

These concrete things make for much better illustrations than abstract data types because we can jump-start our understanding of code relationships by piggybacking on our existing understanding of relationships in the real world.

Piggyback on Existing Integration

Setting your illustrations of different OOP concepts in the same domain makes them easier to integrate.

Your “assignment” is not just to write code so much as to develop a library of connected metaphors to fluently draw from when called upon to explain concepts. We develop the metaphor to integrate our mental models, and we write corresponding Ruby to develop integrated examples.

Finally, in case it is not already clear, we are not writing a program here. These are more like mental maps or diagrams in code form.

Putting It Into Practice

When I first began reviewing OOP concepts, the prospect of illustrating them all in a unified model was daunting. Before writing the unified model, I alternated reviewing course materials with writing individual snippets to illustrate specific concepts.

I started with the concepts I was most confident with. Class inheritance and module mixins?–no problem. Constant scope?–let me get back to you. This brings me to a clarifying question:

Q: When should I start doing this?
A: Once you have completed the lessons and seen the study guide, you may be comfortable enough with some concepts to write illustrative examples of them. Later, combine concepts into larger illustrations, and eventually a unified model. In other words, this is a review strategy. Do it when you’re reviewing!

My Particulars

For a domain I picked a bookstore, and began by writing individual snippets to illustrate the concepts.

Attempting to write the snippets revealed shortcomings in my understanding that I addressed mostly through rereading the course material. Refining the snippets brought fluency and clarity. I wrote some intermediate snippets that combined several concepts, and eventually wrote the suggested unified model that utilized all the key concepts from the course.

Coming up with your own code illustrations and model is the helpful bit, so I won’t be providing my final unified model for your reference. However, I will give smaller examples, both to paint a broad picture of what I did and to illustrate some of the lessons I learned in revising.

The Bookstore Metaphor

So, how did I model object oriented programming concepts in the domain of a bookstore?

• Class inheritance: types of employees (manager, bookseller, owner…)
• Polymorphism: unrelated product types that all get treated the same at the cash register
• Collaborator objects: an instance of Inventory stores instances of Book
• Protected methods: Employee instances can access certain methods such as a work schedule from other employees, but those methods are off limits to a Customer

Hopefully you get the idea.

Creating Effective Illustrations

I revised many of my snippets. Some improvements were immediately obvious, but others came after going to TA sessions and SPOT sessions (Launch School’s peer-lead study groups) and getting feedback on the illustrations I provided.

I’ll demonstrate some rules of thumb that may improve your illustrations.

Simplify

You may feel the urge to write code examples that are more fully featured, that look more like a “real program.” This impulse can add unnecessary and distracting detail.

Here I’ll share two snippets: one that has some unnecessary complexity and then a simplified version.

I wrote the following to illustrate collaborator objects and private getters:

class Inventory
  def initialize
    @stock = Hash.new(0)
  end

  def [](book)
    stock[book]
  end

  def []=(book, quantity)
    stock[book] = quantity
  end

  def all_titles
    puts stock.keys.map(&:title)
  end

  private

  attr_reader :stock
end

class Book
  attr_reader :title

  def initialize(title)
    @title = title
  end
end

white_fang = Book.new('White Fang')
piranesi = Book.new('Piranesi')

store = Inventory.new
p store[white_fang] # 0
store.all_titles # no output

store[piranesi] = 3
store[piranesi] -= 1
p store[piranesi] # 2
store.all_titles # Piranesi

Upon further reflection, I realized that the above snippet can be cleaned up a bit. Using a hash introduces complexity that doesn’t further the concept I’m trying to illustrate. Also, instantiating two book objects serves no purpose here; one would do just fine.

Below is a slightly simplified snippet. It uses a simple array rather than a hash. Also, the #in_stock? method is a clearer example (than #all_titles) of a public method that responds based on private state that is not exposed.

class Inventory
 def initialize
   @stock = []
 end

 def in_stock?(title)
   stock.any? { |book| book.title == title }
 end

 def receive(book)
   stock << book
 end

 private

 attr_reader :stock
end

class Book
 attr_reader :title

 def initialize(title)
   @title = title
 end
end

inventory = Inventory.new
p inventory.in_stock?('Piranesi') # false
inventory.receive(Book.new('Piranesi'))
p inventory.in_stock?('Piranesi') # true
inventory.stock # error

Every bit of simplicity counts. When you are taking an assessment, half of your brain might be in panic mode. You want to build up a library of examples that you won’t get tripped up trying to reproduce. Also, when you eventually unify your snippets, compact and efficient examples will be easier to integrate.

To simplify a snippet, ask yourself questions like:

• Can I illustrate this with fewer methods?
• Does this collection need this many entries? (Your example array probably doesn’t need ten elements. Three will do.)
• Can I use a simpler data structure?
• When I “run some code” at the end to demonstrate the concept, are my examples redundant? What’s the simplest way to show how it works?

Regarding that last point…

Run Some Code

Don’t just write classes that illustrate the concepts at hand; run some code to show how it works!

The above snippets are primarily concerned with illustrating collaborator objects. As such, it’s critical to include that last section where I populate the Inventory with a Book object and test the public interface. In some cases it may be useful to demonstrate code that throws an error, for instance to show where we can and can’t invoke private methods.

When putting together your unified model, I recommend leaving out the demonstrative code-running. It clutters the file to demonstrate dozens of things.

Annotate Your Snippets

As your understanding improves and you review snippets you’ve written, you may come to realize… well, all sorts of things! Leave comments in your snippet files to preserve your observations alongside the relevant code.

One genre of comment I left in several snippets was essentially, “When would I want to use this?”

For instance:

# class variables are useful for storing common state
# ...tied to the class rather than specific instances
# a basic example is incrementing the instance count on initialization

class Book
  @@books_on_record = 0

  def self.how_many_exist
    @@books_on_record
  end

  def initialize
    @@books_on_record += 1
  end
end

Some things to consider reflecting on and annotating:

• When would I use this concept? What is a classic use case?
• Does the real world situation I’m modeling here feel like it would be better modeled with a different structure? (When illustrating polymorphism, you may come to realize the nouns you are using to illustrate duck typing would make more sense in a common class inheritance structure, or vice versa.)

Your snippets may be saved in Ruby files, but they are part of your notes, and you can write whatever you want in them!

Contradict Yourself

I’ve shared a couple implementations of a Book class that looked quite different. You may wonder if your snippets should play nice with each other and be non-contradictory, so that you can easily just combine them when you want to build a unified model. I say no!

When you are writing many snippets to illustrate a particular concept or a few concepts together, this is a great time to “explore the space” of your metaphor. Model the same noun in different ways, or use different nouns to model the same concept, and see what looks better.

The Book snippets I’ve shared are not contradictory in the sense that you could combine them, but in each snippet I only included the detail necessary for the concept at hand. The same overall principle applies in that each snippet is an independent effort to illustrate something. Consistency comes later.

The Unified Model

All this talk about snippets, but wasn’t the whole point to build a unified model? When should you put it all together and what should it look like?

Let’s refresh what we’re trying to do here:

• We want to integrate our understanding of different concepts.
• We want fluency with giving examples to illustrate concepts.

And our strategy is:

• We develop an extensive mental model mapping object oriented programming concepts to a real world domain.
• We use that metaphor as the setting for code illustrations of concepts.

Truth be told, writing separate snippets that draw from the same context does a lot of work solidifying our understanding. You could stop there and have benefited greatly, but don’t! Distilling that work into a unified model is quite worthwhile.

Why Bother With the Unified Model?

Goal Power

One reason to plan on creating the unified model is simply the purpose it serves being in the back of your mind as a goal. It is a daunting task that acts as a litmus test for your confidence in the material, and it encourages taking intermediate steps of study to clarify and condense your understanding.

Resolving Contradictions

Putting your examples for all the concepts in the same place encourages compact examples, but it also forces you to resolve any contradictory or confusing overlapping metaphors.

I encouraged experimentation within individual snippets, but when it comes to the unified model you need to “make a choice” about which nouns to tie to which concepts.

This is the final stage of refining the examples you will draw from when asked to explain concepts. You want to be able to illustrate all concepts without your examples stepping on each other’s toes.

An Aside: Be Flexible

The particular implementation you use to illustrate a concept in your unified model is not the only way to do things. You may very well do things differently on an assessment.

You will be more flexible if you have tried out similar implementations during the snippet phase.

Quick Reference

The desire for tidy examples brings me to the final use of the unified model: a quick reference study tool. If all the relevant concepts are illustrated in your unified model, you can skim it and ask yourself “do I understand what’s happening here?” and rest assured you’re covering everything. I’m talking about jogging your memory, not achieving initial mastery.

What It Is, What It Isn’t

To reiterate what I’m suggesting the unified model be:

• The unified model’s purpose is more like notes than a program.
• The unified model illustrates all relevant concepts.
• All illustrations in the unified model should be set in the same general context.
• Different aspects of the unified model do not need to interact with each other in code.

Closing Thoughts

Good Enough

When I created my “unified” model, the disconnectedness of different illustrations made me feel sort of like I had just put separate snippets in the same file. That’s fine!

Having that file allowed me to go to one place to review the model I developed, and ensured that the particular illustrations I drilled late in the study process were not contradictory.

By that time I was starting to think “I should just take the assessment already,” so I wasn’t overly concerned with spending a long time doing it just right.

This goes back to my point about how having the unified model as a goal leads you to some great review before you even get to the “unified” part.

“They’re More Like Guidelines”

Again, my detailed instructions are an attempt to be clear and helpful, rather than prescriptive.

The initial suggestion I followed left room for interpretation. What I improvised worked well for me and I wanted to share it. Take what makes sense to you and adapt it to your needs!

Reach Out (I’ll Be There)

I’m very curious to hear from other students about whether they’ve done something similar and how it went. Feel free to reach out with your thoughts.

The backbone of my assisted computer input (and the topic of this post) is the voice command/dictation software Talon Voice. Talon builds out functionality with user scripts in Talon’s command scripting language and python. Practically speaking, you can just clone the community maintained starter repo to get started.

What Talon Looks Like

It’s tricky to pick the perfect demonstration of Talon. Personalization is a key feature and everyone’s setup is a little different. Some of the best short and sweet video demonstrations are primarily demonstrations of the (amazing, game-changing) auxiliary tool Cursorless. There are some great conference talks about Talon that are years old and therefore partly outdated. I recommend approaching demonstrations with the aim to get an idea of the possibilities. If you choose to dive in, refer to current documentation.

Here are some demonstrations:

• Josh W Comeau’s great post on hands free coding includes some demos and explanations of Talon basics. It is a few years old, written I believe before Cursorless existed.

• Short and sweet 1 minute demo of writing some Java with Talon (YouTube).

• Here’s a 2 minute demo (YouTube) from the creator of Cursorless, using Talon with Cursorless.

• Emily Shea’s 40 minute conference talk (YouTube) from September 2019 shares her experience transitioning to code by voice using Talon. Includes a demo, discussion of voice coding pros and cons, tips, and what things are and aren’t actually problematic. Keep in mind it’s over 4 years old now. Some of the technical specifics are outdated, but it’s a helpful glimpse into a development career enabled by voice coding.

On that last note, I just want to underscore that there are professional developers whose careers would have ended without these tools. Dictation is a viable alternative to mouse and keyboard. Voice controlled computing has grown tremendously in the last decade, and I expect it will only improve.

Getting Started

Want to give it a go? See the Talon Community Wiki.

The starter repo is expansive and regularly updated. I continue to discover useful commands I didn’t realize exist. Get to know the community repo and tweak things to your liking.

Most of the modifications I’ve made have been keyword changes or simple commands to insert specific text. I haven’t gotten that into the weeds but you certainly could if you want. Here’s a typical tweak commit I made to my fork. You can get a lot of mileage out of simple tweaks that don’t require understanding more complex concepts.

Beyond the starter repo, my top recommendations to extend Talon would be Rango for browser navigation and Cursorless for programming and text editing.

Parting Advice

Expect some feelings of overwhelm. These are powerful tools and there’s a lot to figure out. That said, I’ll emphasize again you can get a lot of bang for your buck by getting comfortable with the basics and finding personalized solutions to your biggest friction points.

The Talon Slack (linked on the website) is a great place to get help if you are stuck. Standard advice on asking for help applies: do your best to figure things out by yourself first (read the manual!) and explain what you have tried.

Feel free to reach out to me with questions.

For my brag sheet, please visit my home page, narjo.dev.

I use dictation for most computer input, such as Coding with Talon Voice.

You can subscribe to this blog via the RSS feed.

Contact

You can contact me at dev@narjo.dev.