Skip to main content

· 5 min read

Motivation

I write my blog posts in Markdown and my personal site is powered by Gatbsy.js. Within a Markdown file, there are frontmatter and content.

  • Frontmatter is a YAML block that contains the post's metadata such as title, date and description. It will be parsed and used by the site generator to generate the post's page.
  • The content is simply Markdown-styled text.

For example, this post will look something like this in the source code:

---
title: Create VSCode Snippets for Markdown Blog Workflows
date: 2023-01-03T15:09:34Z
description: Utilize VSCode snippets to simplify the creation of new posts
tags: ["markdown", "vscode"]
---

## Motivation

I write my blog posts in Markdown and...

And the rest of the body text...

For the past year, what I had to do when creating a new post was to copy the frontmatter from an existing post and then manually update it. This was not particularly pleasant. I am ashamed to admit that I just let laziness take over and did not do anything about it.

Let's fix this with VSCode snippets.

Create a snippet

A VSCode snippet is a pre-defined text that can be inserted on a trigger. You can specify:

  • the triggering word or phrase
  • what should be inserted
    • can be a simple text
    • can have placeholders
    • can use variables

The details can be found in the VSCode documentation.

Let's go through my use case as a concrete example.

Steps

What I want to achieve:

  • insert a frontmatter block with the key-value pairs required
  • auto-populate the date field with the current date-time in ISO 8601 format (this is the format that my parser expects)
  • insert some boilerplate headings for the content

1. Create a snippet file

  1. Open VSCode
    • Open the repository of your choice, if any
    • My blog is contained in a folder called blogging, so I will open that folder
  2. Go to File > Preferences > Configure User Snippets
  3. Choose the scope of the snippet
    • In my case, I want to create a snippet just for my blog project, so I will choose New Snippets file for "blogging"...
  4. Give it a name
    • I will call it blog

With that, a file called blog.code-snippets will be created in the .vscode folder.

2. Create the snippet

The blog.code-snippets file will be prepopulated with comments:

{
// Place your blogging workspace snippets here. Each snippet is defined under a snippet name and has a scope, prefix, body and
// description. Add comma separated ids of the languages where the snippet is applicable in the scope field. If scope
// is left empty or omitted, the snippet gets applied to all languages. The prefix is what is
// used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
// $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders.
// Placeholders with the same ids are connected.
// Example:
// "Print to console": {
// "scope": "javascript,typescript",
// "prefix": "log",
// "body": [
// "console.log('$1');",
// "$2"
// ],
// "description": "Log output to console"
// }
}

Read the comments if you would like to understand the default example given. Let's clear the file and start from scratch.

Let's first give the snippet a name and a description:

{
"Blog template": {
"description": "Blog template for a new article"
}
}

This is the metadata of the snippet. The name is what will be displayed in the IntelliSense dropdown. The description is what will be displayed in the snippet preview.

Let's choose a trigger word, here I am choosing a simple two character bt:

{
"Blog template": {
// ...omitted for brevity
"prefix": ["bt"]
}
}

This means that when I type bt in my project files and press ctrl+space, the snippet option will show up.

Lastly, let's add in what will be inserted when the snippet is applied:

{
"Blog template": {
// ...omitted for brevity
"body": [
"---",
"title: ${1:blog title}",
"date: $CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T$CURRENT_HOUR:$CURRENT_MINUTE:${CURRENT_SECOND}Z",
"description: ${2:blog description}",
"tags: [$3]",
"---\n",
"## Motivation\n",
"$0",
"## Conclusion\n",
"## References\n"
]
}
}

Some details to note:

  • the ${1:blog title}, ${2:blog description} and $3 are placeholders. When the snippet is applied, the cursor will be placed at the first placeholder and the user can tab to move or type to replace/fill in the spot. The tab order is ascending from 1 onwards
    • $0 is the final cursor position.
  • the CURRENT_YEAR, CURRENT_MONTH variables are predefined by VSCode
  • the items in the body array are joined together with a new line

Completed snippet

For reference, this is the final content in .vscode/blog.code-snippets:

{
"Blog template": {
"description": "Blog template for a new article",
"prefix": ["bt"],
"body": [
"---",
"title: ${1:blog title}",
"date: $CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T$CURRENT_HOUR:$CURRENT_MINUTE:${CURRENT_SECOND}Z",
"description: ${2:blog description}",
"tags: [$3]",
"---\n",
"## Motivation\n",
"$0",
"## Conclusion\n",
"## References\n"
]
}
}

Conclusion

My use case is for creating blog posts, but code snippets can be used in other scenarios as well. If VSCode is your main editor, do take a moment to think about what snippets you can create to make your life easier.

References

· 2 min read

A "brag document" is a document that lists every key accomplishments so that you can refer to it when you get to performance review season (from Julia Evans).

Taking that idea, this living document is a collection of my achievements that I am proud of, a long form extension of my resume.

Projects

MarkBind

A a senior developer/maintainer, I decided to zero in on making sure we have the best developer experience. I created an onboarding bootcamp, detailing how a new developer can get started with MarkBind. This directly impacts batches of student developers from NUS every year, to help them get started with possibly their first open source project. It also serves as a good introductory material to any interested developer who wants to go deeper into MarkBind.

To increase the outreach of MarkBind, I have put in effort to help projects currently using MarkBind for their documentation to upgrade or improve their MarkBind setup. For example, helping CATcher to migrate their MarkBind version to V4.

I have also pushed for the adoption of MarkBind in NUS, by helping to introduce MarkBind as a documentation tool in CS2103T Software Engineering's group assignment. This allows groups to create their project documentation using MarkBind (as opposed to the previous method of using Jekyll). I consider this a success as there were quite a few groups who have adopted MarkBind, bringing our npm weekly downloads to a new high of 1-2k (from 1-4 hundred previously). I provided necessary support to the students who encountered issues with their MarkBind setup.

npm download stat

Another aspect of maintaining open-source software is to get invovled in the release process. With much preparation, I have drafted and released MarkBind V4.1.0 🚀. In the spirit of always improving and always documenting, I have also made a follow-up Documentation PR to clarify the release process for future maintainers.

Other notable contributions include:

MDN Web Docs

MDN Web Docs is a Mozilla project that aims to document the web.

  • issues I have opened or investigated
  • PRs I have made and merged

I have worked on editing articles written by other technical writers to fix errors and improve the quality of the articles.

· 5 min read

Motivation

About one year ago, I had no idea how to contribute to open-source projects and yet it was something that I really wanted to do. I read articles and watched YouTube videos that provided good suggestions and resources, but somehow I just could not get over the initial hurdle and actually contribute to Open Source Software (OSS) projects. I have done things like trying first-contribution, starring and bookmarking projects and doing all the preparation to end up not being able to contribute to any projects out there.

Looking back, two issues prevented me from moving forward:

  1. How to find a project that is of the right technical level and has beginner-friendly issues
  2. After finding one such project, how to navigate through its large codebase and start working?

I have made some progress over the past year and I hope to pen down my thoughts on open-source work. I am not a "10X" developer, but my perspective could be helpful to people who are just starting.

What do I really need to know?

As you can see from the first issue mentioned above, the number of available projects for you depends on your technical ability and interest. Before anything, it is really important to know how Git & GitHub (or Gitlab) works because most OSS projects are done with the help of Git for version control and GitHub (or Gitlab) to host the code for sharing among developers.

In particular, you should minimally understand:

  • What’s a commit and how to write good commit messages?
  • What’s a PR?
  • What’s a branch?
  • What’s branching workflow and forking workflow?

With that out of the way, the main bulb of learning is on the tech stack of the project. This can be difficult if you are completely new. However, my experience has been that depending on the complexity of the project, you don't always need to be an expert in the tech stack to contribute. What I would recommend is to go through some tutorials and try to understand the basics of the tech stack. With that, the rest of the learning can be done on the go.

Something else I feel strongly about is getting to know the product from a user's perspective. This will open doors for you to

  • verify the correctness of the documentation (or lack of it)
  • find edge cases that are not covered
  • think of new features that can be added
  • reproduce bugs and help in the debugging process
  • participate in discussions on how to improve the product

Non-technical contributions can be very important. They also provide chances for you to interact and find out more about the project and the community. After all, the project is not just about the code. It's also about the people who are working on it.

How to understand a project's repo?

It's important to remember that it's okay to not understand everything right away. It may take time and practice to fully grasp the project's codebase. This "advice" is not unique but I think most articles and guides don’t emphasize it enough.

With limited time and also limited interest (you may never want to work on certain aspects of the project), prioritize what you should know according to what you want to do. Here are some tips that I have found useful:

  • make use of the project's developer guide, if available. This document should provide an overview of the project's architecture and workflows.
  • start by focusing on a specific aspect of the project that interests you or that you feel confident in tackling. This could be a bug or a feature that needs to be implemented. As you work on this task, you will naturally become more familiar with the codebase and be able to contribute more effectively.
  • stalk the project's ongoing issues and PRs. This will give you a sense of what the project's maintainers are working on and how they do it.

Contribute when the opportunity arises

I have found that when you start working on just a single project, it will naturally lead to other opportunities (e.g. upstream libraries, similar projects, etc). When I started working on MarkBind, a static site generator, I was also making occasional contributions to some of the plugins for markdown-it, the Markdown parser that MarkBind uses. I was fixing bugs in MarkBind by discovering the root causes in the upstream libraries and pushing fixes there to hopefully benefit other projects as well. I even made a pull request to fix the documentation that I was reading on an MDN page for <tbody>: The Table Body element, something that broke the server-side rendering of MarkBind.

Closing thoughts

Working on OSS projects can be challenging and sometimes frustrating. While it is rewarding to contribute to projects that others may benefit from, it's important to recognize that at times, it's just free labor that some people will not even appreciate. You will also realize that "The reward for good work is more work".

Being a developer involves more than just writing code. It may also include tasks such as investigation, discussion, research, proper documentation, and explaining your code to others. These are important software engineering tasks, but may not always be as satisfying as simply writing code.

My conclusion about OSS is that it's worth trying out and you will learn a lot from it. It's also not as "glamorous" as you may think. People abandon OSS projects all the time and you may not always get the recognition you deserve. I hope that this short article will help you to get started on your journey into open source. Good luck!