Forem: Rafi

Choosing the editor for the next decade

Rafi — Sat, 08 Jun 2024 03:57:41 +0000

I have used lot of editors over the years. For the last 5 years I have been using VSCode. It has been a great editor. It initially was quite slow but has improved over the years. And the ecosystem itself has a lot of plugins. Potentially making it close to a general purpose IDE. Which is pretty great if you are looking for a single editor that can pretty much work with everything and has support for new thing that comes up out of the box without any configuration without using a full fledged IDE

Using minimal tools

Over the years I have started to believe that having a minimal set of handpicked tools that you know well so that it doesn't get in your way is better than having a batman utility belt that can do everything by default. Minimal tools doesn't mean using notepad out on a touch screen without keyboard 😅. But more like using a focused tool that is sophisticated enough to do what you want easily and should be extendable in the future if you need it to be

Choosing the editor

While VSCode is awesome it has been slowly turning into an IDE and has a lot of things by default that I don't need. I wouldn't be surprised if 5 years down the lane they try to replace Visual studio with VSCode. Also I would I have been thinking about switching to something simpler that can serve me well for the next decade. Here is list of things I think I need in a text editor

It should be fast
It should be very minimal just enough to serve my editing needs
It should be extendible in-case I need to do something more in the future
It should work everywhere
It should be able to survive the test of time and not be abandoned in the next few years

I initially thought of Sublime Text. Which is a great editor. But it is frozen in time, it does get updates now and then. While it is extendible to some extent but not everything is up for change.

Then I thought of VIM which is something that I tried briefly in the past for sometime

It was blazingly fast
It was minimal by default but can be extended to do anything
It definitely works everywhere
It has been around for a long time and will be around for a long time

But Vimscript was awful. I really wished it used a general purpose programming language for writing plugins instead of some arcane scripting language. But a lot has changed since then now we have Neovim which has all the goodness of Vim but with a modern plugin system that uses Lua. A general purpose programming language that is easy to learn and use. Once you get the hang of it VIM motions are awesome. You can take them to any editor. There is even a browser extension that lets you use VIM motions to navigate the web.

I have been using Neovim for the last few weeks with minimal setup and I am loving it. Let's see how it goes.

Originally posted in https://approxhuman.substack.com/

Minimal theme for Youtube

Rafi — Wed, 31 Aug 2022 09:54:22 +0000

I was bored today, so I build this simple Chrome extension that adds minimal theme to youtube to make it boring and less distracting.

The extension uses manifest v3 and works by hiding some elements in the page by injecting custom css

here is the link to the Chrome extension and the link to the repo

Optimizing pull request for developer happiness

Rafi — Sat, 26 Jun 2021 08:11:13 +0000

We as developers create a lot of pull requests from building new features to fixing bugs and typos.

When we create pull requests it is important to optimize for easy review by other developers and even by yourself at a later point in time. The goal of PR is to keep it simple, clutter-free and allow others to review without any cognitive overhead.

1. Provide clear context

It is better not to make assumptions in the pull request. Since the person reviewing it might not understand all the discussion that happened elsewhere outside the pull request
If there are links to slack discussions / other documentations do mention them too
Explaining why the code change is needed and what it does helps
Don't use big words or any jargons if it is not needed
If you do something new in the codebase explain it
Follow some pull request template so that structure of the PR description is always the same and it is easy to find things

2. Write code spec document if possible

When you are about to work on a big feature that would affect everything. To avoid any surprise you could write a simple spec document of change you propose to do and get it reviewed by other devs in your team
This would allow you to avoid later disagreements and complete rewrite after the code is written
This might not always be needed but will help for very big features

3. Keep PR size small

It is better to have few changes in PR as possible
If the feature is big rather than a shipping feature in a single PR it might be possible to break the feature into smaller features and ship it incrementally (ship it in parts at least to staging). That way the feature is easy to review and spot bugs. And you if would find issues with the feature and don't have to re-work the feature completely when everything is done
If you find some other issue while writing the code create a different PR to fix the issue

4. Add Video / screenshots

If you have visual changes add video or screenshots of the changes in the PR description
If it is a bug fix provide screenshots of before and after the change. So that they don't have to jump to issues to see the bug

5. Host the changes

Host the PR and provide a link for the reviewer to checkout
You could use automated deployments to create preview URL for PR in frontend codebase using Vercel or Netlify

6. Highlight critical changes

If there is any critical change you could highlight them by adding a Github comment explaining why you did it and providing more context
You could also add a small video of walkthrough through the code changes if needed
If you think there is something to look out for write down that too

7. Don't squash the commits once the review has begun

Squashing commits during the review will make it harder to track changes for the reviewers

8. Automate repeated checks

Using tools like prettier, Eslint to automate basic checks will help
If there is an issue specific to the repo that comes up multiple times in different PR's automate it if possible either using custom Eslint rule or using some other tool so that the reviewer can be sure that issue handled and don't have to think about it

9. Don't get angry over a PR

If the reviewer suggests some change and you disagree with it. You could disagree in a respectful way explaining your case. It is not worth getting angry over a PR. Since it is just the code change the reviewer disagrees.
If you learned something new from the code review give a shoutout to the reviewer :)

Photo by Tim Mossholder on Unsplash

Simple hook to handle featue flags

Rafi — Wed, 31 Mar 2021 05:18:52 +0000

Let's say you want to enable or disable some features based on users role or some permission that the user is granted in the frontend. You could do this with a simple conditional rendering in each component by checking for users permission

<div>
 {role==='guest' && <GuestBanner/>}
</div>

But this is really messy if you have to do this in multiple components. We could instead create a custom hook that returns Boolean saying if we should enable or disable the feature

import { useSelector } from 'react-redux';

const useFeature = (feature) => {

 // If you use something other than redux replace useSelector with equivalent
// getRole is selector to select user role from redux state
const role = useSelector(getRole)

if(feature === 'guestBanner') {
  if(role === 'guest') return true;

  return false;
}

return true;

}

And then in your component you use this as follows

import useFeature from './use-feature';

const GuestBanner = () => {
  const enable = useFeature('guestBanner');

  if(!enable) return null;

   return <h1>Guest Banner</h1>

}

Star background using Houdini CSS

Rafi — Sat, 19 Dec 2020 06:00:50 +0000

I was playing with Houdini css and built this. It is a worklet that allows you to render stars in the background.
It takes in two properties number of star and maximum size of a given star. you can use it as follows

.container {
  background: paint(stars), #282828;
  --star-count: 3500;
  --star-max-size: 0.5;
}

here is the actual worklet code

class Stars {
  static get inputProperties() {
    return ['--star-count', '--star-max-size'];
  }

  getRandom(min, max) {
    return Math.floor(Math.random() * (max - min + 1)) + min;
  }

  paint(ctx, geom, props) {
    const count = parseInt(props.get('--star-count').toString());
    const maxSize = parseInt(props.get('--star-max-size').toString());

    const colorrange = [0, 60, 240];
    for (let i = 0; i < count; i++) {
      const x = Math.random() * geom.width;
      const y = Math.random() * geom.height;

      const radius = maxSize ? this.getRandom(1, maxSize) : Math.random() * 1.2;

      const hue = colorrange[this.getRandom(0, colorrange.length - 1)];
      const sat = this.getRandom(50, 100);
      ctx.beginPath();
      ctx.arc(x, y, radius, 0, 360);
      ctx.fillStyle = 'hsl(' + hue + ', ' + sat + '%, 88%)';
      ctx.fill();
      ctx.closePath();
    }
  }
}

registerPaint('stars', Stars);

it is hosted here and here is the source code.

Converting GIF to MP4

Rafi — Sun, 15 Nov 2020 06:02:00 +0000

GIF's are awesome we use them everywhere. But the issue with GIF's are they are usually much larger in size compared to their video counterparts.

To overcome this we usually convert GIF to MP4 and play them in loop. Usually we do this conversion in the server using ffmpeg or wrapper over ffmpeg. This conversion might be resource intensive.

Luckily there is WASM port of ffmpeg. Which means we could use it to convert GIF to MP4 easily as follow

import FFmpeg from '@ffmpeg/ffmpeg';
import { even } from 'prelude-ls';

const { createFFmpeg, fetchFile } = FFmpeg;

const ffmpeg = createFFmpeg({ log: true });

document
  .getElementById('fileInput')
  .addEventListener('change', async ({ target: { files } }) => {
    const { name } = files[0];
    await ffmpeg.load();
    ffmpeg.FS('writeFile', name, await fetchFile(files[0]));
    await ffmpeg.run('-f', 'gif', '-i', name, 'output.mp4');
    const data = ffmpeg.FS('readFile', 'output.mp4');
    const video = document.getElementById('player');
    video.src = URL.createObjectURL(
      new Blob([data.buffer], { type: 'video/mp4' }),
    );
  });

Here is the demo and here is the source

Note

There could be additional flags supplied to ffmpeg to limit the frame rate, height and width of the video file...

Implementing custom liquid tags

Rafi — Thu, 12 Nov 2020 04:32:28 +0000

Liquid tags are awesome dev.to uses some custom liquid tags to embed posts, gist, github repos, twitch streams and lot more. To understand how liquid tag works in dev.to I tried to implement similar custom liquid tag.

We will build a gist liquid tag. That renders a gist when provided with url like below

You can get the boiler plate for this project from here in boilerplate branch

$ git clone https://github.com/Rafi993/custom-liquid-tags
$ cd custom-liquid-tags
$ git checkout boilerplate
$ bin/setup

It provides you with basic routing, layout and CSS.

Liquid template language

Liquid is templating language created by shopify (similar to erb). We will include liquid gem in the project by adding liquid in the Gemfile and running bundle install

gem 'liquid', '~> 4.0', '>= 4.0.3'

to parse liquid tags in user content we can do the following in the preview action

  def preview
    @template = Liquid::Template.parse(params[:text])
    @parsed_html = @template.render()
    render "preview"
  end

and liquid tags should work now

we will disable these default tags later

Custom tags

First we will create a app/liquid_tags/liquid_tag_base.rb
from which all the liquid tags will inherit from.

class LiquidTagBase < Liquid::Tag
  def self.script
    ""
  end

  def initialize(_tag_name, _content, parse_context)
    super
  end
end

If you have some common code that needs to be shared across all liquid tags you can place it here.

Then we will create our gist liquid tag app/liquid_tags/gist_tag.rb we could copy the code from Forem repo for this :)

class GistTag < LiquidTagBase
  PARTIAL = "liquids/gist".freeze
  VALID_LINK_REGEXP =
    %r{\Ahttps://gist\.github\.com/([a-zA-Z0-9](-?[a-zA-Z0-9]){0,38})/([a-zA-Z0-9]){1,32}(/[a-zA-Z0-9]+)?\Z}
      .freeze

  def initialize(_tag_name, link, _parse_context)
    super

    raise StandardError, "Invalid Gist link: You must provide a Gist link" if link.blank?

    @uri = build_uri(link)
  end

  def render(_context)
    ApplicationController.render(
      partial: PARTIAL,
      locals: {
        uri: @uri,
      },
    )
  end

  private

  def build_uri(link)
    link = ActionController::Base.helpers.strip_tags(link)
    link, option = link.split(" ", 2)
    link = parse_link(link)

    uri = "#{link}.js"
    uri += build_options(option) unless option&.empty?

    uri
  end

  def parse_link(link)
    input_no_space = link.delete(" ").gsub(".js", "")
    if valid_link?(input_no_space)
      input_no_space
    else
      raise StandardError,
            "Invalid Gist link: #{link} Links must follow this format: https://gist.github.com/username/gist_id"
    end
  end

  def build_options(option)
    option_no_space = option.strip
    return "?#{option_no_space}" if valid_option?(option_no_space)

    raise StandardError, "Invalid Filename"
  end

  def valid_link?(link)
    (link =~ VALID_LINK_REGEXP)&.zero?
  end

  def valid_option?(option)
    (option =~ /\Afile=[^\\]*(\.(\w+))?\Z/)&.zero?
  end
end

Liquid::Template.register_tag("gist", GistTag)

The above code parses provided argument to gist liquid tag and generates proper uri that it can use. It also specifies which partial to use for the liquid tag.

we will create that partial file that says how to render this tag app/views/liquids/_gist.html.erb

<div>
  <script id="gist-ltag" src="<%= uri %>"></script>
</div>

If we actually try to use the gist liquid tag now it will throw error saying tag gist is not defined

Initializing liquid tag

We can create our initializer in config/initializers/liquid.rb that loads our custom liquid tags

Rails.application.config.to_prepare do

  # Custom Liquid tags are loaded here
  Dir.glob(Rails.root.join("app/liquid_tags/*.rb")).sort.each do |filename|
    require_dependency filename
  end
end

The above code looks for liquid_tags in the specified path and loads them.

Now when we try our gist liquid tag it should work

Disabling default tags

You may not want default tags like assign, raw to work. You could disable those by adding the following code to config/initializers/liquid.rb

  # Tags to disable
  Dir.glob(Rails.root.join("lib/liquid/*.rb")).sort.each do |filename|
    require_dependency filename
  end

and defining those tags there inside lib/liquid folder

# lib/liquid/raw.rb
module Liquid
  class Raw < Block
    remove_const(:FullTokenPossiblyInvalid) if defined?(FullTokenPossiblyInvalid)
    FullTokenPossiblyInvalid = /\A(.*)#{TagStart}\s*(\w+)\s*#{TagEnd}\z/om.freeze # rubocop:disable Naming/ConstantName
  end

  Template.register_tag("raw", Raw)
end

# lib/liquid/variables.rb
module Liquid
  class Variable
    def initialize(_markup, _parse_context)
      raise StandardError, "Liquid variables are disabled"
    end
  end
end

Now you should not able to use default tags like assign, abs ...

You can find the source for the project here

Note:

Forem does little more when by checking if the user can access a liquid tag using pundit gem

cover image by Vitaly Vlasov from Pexels

How do you manage your github notifications?

Rafi — Tue, 20 Oct 2020 17:26:16 +0000

I primarily use email to manage my Github notifications.
I have setup rules for auto labelling in my email. So when a new notification email comes in it gets labelled as pull request, assigned, merged or closed (and other labels based on Github labels too) depending on the subject or email contents. I have tried octobox but I have not used it extensively. What are your thoughts?

Photo by cottonbro from Pexels

Git internals

Rafi — Thu, 20 Aug 2020 04:12:34 +0000

We developers use git all the time. Git internals might feel like magic, but what git actually does is really simple. Let us peek under the hood to see how git works.

Lets create a empty folder and then run initialize the git repo by running

$ git init

This creates .git folder inside your empty folder. The structure of this .git folder is as follows

.git/
├── branches
├── config
├── description
├── HEAD
├── hooks
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

If you open up the HEAD file in your text editor you will see
the following text in it

 ref: refs/heads/master

which means that your current branch is master.

Now add a file and make a first commit by doing

 $ echo "Hello" >> README.md
 $ git add .
 $ git commit -m "Initial commit"

now run $ git log and you will get

commit acde617e8ab39bb157821d3bf84d04e157bff52c (HEAD -> master)
Author: username <test@email.com>
Date:   Wed Aug 05 18:43:48 2020 +0330

    Initial commit

Note:

The exact commit hash that you get will differ from what you see here depending on your username, email and time that you make the commit

And if you open up refs/head/master it will have text acde617e8ab39bb157821d3bf84d04e157bff52c inside it.

In git each commit is associated with a hash. The content of the file refs/head/master means master is pointing to the commit
acde617e8ab39bb157821d3bf84d04e157bff52c

 // TODO:

 1. Now make a second commit
 2. check `$ git log` and content of **refs/head/master**

After you have made your first commit if you inspect the contents of the .git folder again you will see something new

.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           └── master
├── objects
│   ├── ac
│   │   └── de617e8ab39bb157821d3bf84d04e157bff52c
│   ├── dc
│   │   └── 0a29da1d9b3f68dcd56af0e34f8df4fbf8b24f
│   ├── e9
│   │   └── 65047ad7c57865823c7d992b1d046ea66edf78
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

There is a new file called index and some weird things inside object folders (we will ignore all other new things for now).
When you run $ git add . git takes the changes that you have made and creates objects for it. The names of the objects are determined by running your file content into SHA1 algorithm. SHA1 algorithm basically takes some input and outputs 40 character string.

Let's try to generate SHA1 of the file README.md. You can do that by running

$ git hash-object README.md

which will give you output

e965047ad7c57865823c7d992b1d046ea66edf78

So that is where the content of the file README.md is stored (inside objects folder). The first two characters of the hash are used for folder name. The file 65047ad7c57865823c7d992b1d046ea66edf78 is binary file to see its
content we can run

$ git cat-file -p e965047ad7c57865823c7d992b1d046ea66edf78

which outputs

Hello

Which is the content of your README.md !!!

But what are other two objects?

There two other objects that are present in the objects directory. What are those?
Git has four types of objects blob, tree, commit and tag. Blob is used to store the content of the file the one we just saw is a blob.
You can see the type of the object by running

$ git cat-file -t e965047ad7c57865823c7d992b1d046ea66edf78

which will print

blob

When you run

$ git cat-file -p acde617e8ab39bb157821d3bf84d04e157bff52c

and you will get

tree dc0a29da1d9b3f68dcd56af0e34f8df4fbf8b24f
author username <test@email.com> 1597845162 +0530
committer username <test@email.com> 1597845162 +0530

Initial commit

That is our actual commit and it has author, committer and something called tree which is another git object

Lets see what that tree object has by running

$ git cat-file -p dc0a29da1d9b3f68dcd56af0e34f8df4fbf8b24f

It outputs

100644 blob e965047ad7c57865823c7d992b1d046ea66edf78    README.md

It has the name of the file and name of the blob that has the file content. It is essentially how your working directory looked like at that commit.

Let's sum up our understanding till now. When you make a commit in git. The content of the file are passed through an SHA1 hash to get a 40 character length string, file is created with that name storing the contents. Then it creates a tree object which is essentially how your working directory looked at that point in time. The tree says which blobs are associated with which file names. Then there is a commit object which points to this tree object and also has the commit message, author, committer, and email.

 // TODO

 1. Now make another commit
 2. inspect the contents of the .git folder
 3. See what are the objects that are there in .git folder
 4. Look at content of objects

Branching

Now lets create a branch by running

$ git branch feature-1

Now lets take a look at content of .git folder

.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           ├── feature-1
│           └── master
├── objects
│   ├── ac
│   │   └── de617e8ab39bb157821d3bf84d04e157bff52c
│   ├── dc
│   │   └── 0a29da1d9b3f68dcd56af0e34f8df4fbf8b24f
│   ├── e9
│   │   └── 65047ad7c57865823c7d992b1d046ea66edf78
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   ├── feature-1
    │   └── master
    └── tags

Now there is a new file called refs/heads/feature-1 and if we take a peak at its content it will be the commit hash from which you created the branch.

Now if we checkout feature-1 branch by running

$ git checkout feature-1

The content of our HEAD file changes to

ref: refs/heads/feature-1

 // TODO

 1. Try creating a file refs/heads/feature-2
 2. Run git log
 3. Put the hash inside that file
 4. Try running git branch

Staging area

When you create a file you are creating the file in your local file system and after you are done you add the file to git by running $ git add . this adds the file to the staging area. Then when you make commit the files the commit object is created for files in the staging area.

So the question now is where is this staging area? The answer is it is in the index file

We can see the contents of the staging area by running

$ git ls-files --stage

which gives us

100644 e965047ad7c57865823c7d992b1d046ea66edf78 0 README.md

 // TODO

 1. Create a README2.md file
 2. Run git ls-files --stage and look at its content
 3. Run git add .
 4. Now run git ls-files --stage again

Note:

We have skipped some details like tags, packing...
The number 100644 is essentially permissions of the file

Thanks to Yancy Min for sharing their work on Unsplash

Building GUI for your shell script using zenity

Rafi — Fri, 07 Aug 2020 04:01:07 +0000

Sometimes the shell scripts that you write asks questions to the user so that they could change the some default value. We usually do this as text input. But for values like date, file path etc.. it would be nice if you show a calendar or a file picker.

There is a really nice command called zenity. Which allows you to build simple GUI for your shell script. Making your shell script more user friendly.

Let's say you want user to select a date you can do

$ zenity --calendar

and it will return you selected date as string

and for a file selection you can simply do

$ zenity --file-selection

When your shell scripts finishes you can notify the user using

$ zenity --notification --text "script completed"

zenity can do much more and it is has been out there for a while and it is available for most Linux distributions and even for other OS like Mac and Windows (but you may need to install them separately)

Edit: You can look for more details about all the options that zenity provides by runinng

$ man zenity

Tiny alternative to electron

Rafi — Sat, 18 Jul 2020 06:59:32 +0000

I wanted to build a small desktop app for my own usage but using electron felt like an overkill (since I won't be using most of the API electron provides). So I wrote a really tiny alternative to electron.

you can easily use it as follows

const Tiny = require("tinytron")

const window = new Tiny();
window.setSize(500, 600);
window.setTitle("Your app");

// When using your own app use express to run the server and pass the url
window.navigate("http://dev.to/");
window.run();
window.destroy()

But unlike electron it does not come with node packed in so you may need to use something like pgk to generate binary that user can use

here is the link to the repo.

Markdown like syntax parser

Rafi — Wed, 08 Jul 2020 13:37:57 +0000

Sometimes you want markdown like syntax but not exact markdown specification. I build a really tiny markdown like syntax parser that you can use out of box or use the functions it exposes to write a custom markdown parser

you can install the package using npm or yarn

$ npm i pico-markdown-parser

Simple usage

import pico from "pico-markdown-parser";

const htmlOutput = pico(`
  # Hello

  This is a sample text!!
`);

Building your own parser

This parser is composed of many small parsers you can import those small parsers from the library and put them together in ways you see fit (like Lego pieces).

import {
  choice, 
  many,
  heading,
  bold,
  anything 
 } from "pico-markdown-parser";

// This new parser now supports only bold and heading
const parser = (input) =>
  many(choice([heading, bold, anything]))
    .run(input)
    .result.join("");

const htmlOutput = parser(`
  # Hello

  This is a **sample** text!!
`);

If the small parsers it gives does not suit your need you can even write your own parser and combine it. This parser is based on arcsecond

Here is the repo. PR's are welcomed !!!