Forem: Rickvian Aldi

Run Leetcode locally - Javascript test case for practices

Rickvian Aldi — Fri, 10 Apr 2026 05:34:25 +0000

Leetcode debugging feature sits behind paywall.
Stop paying for that!

I once wish i could just use VScode
and leverage some of the debugging feature
you can do that easily, but how about the test cases?

Thats why i collect build my own playground repo to practice solving Leetcode Javascript.
I decided it has enough tests, so i open sourced it, check it out!

Tip: use Jest/Vitest runner extension in VScode, clicking debug will attach debugger on the specific case

I find debug mode is the most useful feature to figure out where i did mistake during practice.

https://lnkd.in/gW34BMp9

So far i cover blind 75 list, will add top 150 later, and gradually covering 3K questions

How to use this repo

Clone this repo
run npm install

this repo contains practice problem playground you can run under

leetcode-playground/
└── /[problemsname].js
open the .js file, you can start exercise of solving problem.

Run test
every problem has respective test case you can run using `Vitest
It contains test scenarios ready to battle test your solution (You can contribute test case!)
Tests grouped under /tests folder.

Tips for debugging
To assist your learning, debugging mode is useful to understand why your code does not work,
you can attach breakpoint, and run test in debug mode.
I personally use VScode extension "Jest/ Vitest runner by firsttris". When you open the file, simply click 'debug' to run specific test or describe block. it will run your test in debug mode.

start using Ralph with npx ralph-scaffold

Rickvian Aldi — Wed, 21 Jan 2026 08:27:09 +0000

You might have heard about RALPH,
I publishedralph-scaffold npx script which can provide you with all files needed to start using ralph, simply run

npx ralph-scaffold

and you are good to go.
(I use setup from Ryan Carson)
https://x.com/ryancarson/status/2008548371712135632
What is Ralph?

its a workflow, simple idea, to loop the code agent over and over, until it reach the goal, each time it make mistake it will learn from it. each time it make progress it will take note.

Every loop, will restart code agent starting with fresh context window, supply it with notes on things it learned so far, and progresses
This eliminate the weakness of "Context Drift",

However,
this can dramatically increase token usage, and if it drifts, its gonna snowball through entire iterations, potentially wasting tokens.

Ralph works well on

Small Task Stories
Good feedack on interations , like typecheck or linters,
Explicit criteria

Matt Pocock explained this really well
https://www.youtube.com/watch?v=_IK18goX4X8

Since the token usages could potentially out of control, you may want to try it with claude premium plans, and avoid API based token (i tried it, the token usage is nuts)

How It Works

A bash loop that:
Pipes a prompt into your AI agent
Agent picks the next story from prd.json
Agent implements it
Agent runs typecheck + tests
Agent commits if passing
Agent marks story done
Agent logs learnings
Loop repeats until done

Memory persists only through:

Git commits
progress.txt (learnings)
prd.json (task status)

scripts/ralph/
├── ralph.sh
├── prompt.md
├── prd.json
└── progress.txt

ralph.sh

The loop:

#!/bin/bash
set -e

MAX_ITERATIONS=${1:-10}
SCRIPT_DIR="$(cd "$(dirname \
  "${BASH_SOURCE[0]}")" && pwd)"

echo "🚀 Starting Ralph"

for i in $(seq 1 $MAX_ITERATIONS); do
  echo "═══ Iteration $i ═══"

  OUTPUT=$(cat "$SCRIPT_DIR/prompt.md" \
    | claude --dangerously-skip-permissions 2>&1 \
    | tee /dev/stderr) || true

  if echo "$OUTPUT" | \
    grep -q "<promise>COMPLETE</promise>"
  then
    echo "✅ Done!"
    exit 0
  fi

  sleep 2
done

echo "⚠️ Max iterations reached"
exit 1

Make executable:

chmod +x scripts/ralph/ralph.sh

prompt.md

Instructions for each iteration:

# Ralph Agent Instructions

## Your Task

1. Read `scripts/ralph/prd.json`
2. Read `scripts/ralph/progress.txt`
   (check Codebase Patterns first)
3. Check you're on the correct branch
4. Pick highest priority story 
   where `passes: false`
5. Implement that ONE story
6. Run typecheck and tests
7. Update AGENTS.md files with learnings
8. Commit: `feat: [ID] - [Title]`
9. Update prd.json: `passes: true`
10. Append learnings to progress.txt

## Progress Format

APPEND to progress.txt:

## [Date] - [Story ID]
- What was implemented
- Files changed
- **Learnings:**
  - Patterns discovered
  - Gotchas encountered
---

## Codebase Patterns

Add reusable patterns to the TOP 
of progress.txt:

## Codebase Patterns
- Migrations: Use IF NOT EXISTS
- React: useRef<Timeout | null>(null)

## Stop Condition

If ALL stories pass, reply:
<promise>COMPLETE</promise>

Otherwise end normally.

prd.json

Your task list:

{
  "branchName": "ralph/feature",
  "userStories": [
    {
      "id": "US-001",
      "title": "Add login form",
      "acceptanceCriteria": [
        "Email/password fields",
        "Validates email format",
        "typecheck passes"
      ],
      "priority": 1,
      "passes": false,
      "notes": ""
    }
  ]
}

Key fields:
branchName — branch to use
priority — lower = first
passes — set true when done

progress.txt

Start with context:

# Ralph Progress Log
Started: 2024-01-15

## Codebase Patterns
- Migrations: IF NOT EXISTS
- Types: Export from actions.ts

## Key Files
- db/schema.ts
- app/auth/actions.ts
---

Ralph appends after each story.
Patterns accumulate across iterations.

Running Ralph

run the ralph script with 25 iterations

./scripts/ralph/ralph.sh 25

Ralph will:

Create the feature branch
Complete stories one by one
Commit after each
Stop when all pass

Understanding TypeScript’s Comments: @ts-ignore, @ts-expect-error, and Friends

Rickvian Aldi — Tue, 10 Jun 2025 02:00:05 +0000

When working with TypeScript, you've probably seen some strange-looking comments like // @ts-ignore or // @ts-expect-error. These are TypeScript directives, often called “magic comments” — and they can change how the compiler behaves for specific lines or files.
what exactly is it? what are the difference?

Let's walk through the 4 most important directives you should know.

1. // @ts-expect-error

This directive tells TypeScript:

“I expect the next line to throw a type error. If it doesn't, fail the build.”

// @ts-expect-error
const name: number = "John"

If the error is later fixed (intentionally or by accident), the compiler throws an error:

Unused '@ts-expect-error' directive.

✅ Why it's good:
• Enforces that you're suppressing an error on purpose.
• Helps with testing or gradually migrating code.

🛠 Use when:
• You're writing a test that expects an error.
• You're temporarily keeping known type errors but want safety.

2. // @ts-ignore

This tells TypeScript:

“Ignore all errors on the next line. I know what I'm doing.”

// @ts-ignore
const user: string = 123

Unlike @ts-expect-error, this will never alert you even if the error is gone later. It's silent and dangerous if overused.

⚠️ Why it's risky:
• Suppresses all type checking on that line.
• Can hide bugs and technical debt.

🛠 Use only when:
• There's no other option.
• You're integrating with legacy code, third-party libs, or non-typed APIs.

I would avoid this at all cost.

3. // @ts-check (for .js files)

This enables TypeScript type-checking for plain JavaScript files.

// @ts-check

/**
 * @param {number} x
 * @returns {number}
 */
function square(x) {
  return x * x
}

🔍 Why it's useful:
• Allows you to catch type bugs in JS without migrating to .ts.
• You can annotate with JSDoc for full type checking.

🛠 Use when:
• Gradually migrating a JS codebase to TS.
• You want lightweight type safety in JS.

4. // @ts-nocheck

Disables all TypeScript checking for a file even in .ts or .tsx.

// @ts-nocheck

const user = getUser()
user.doSomethingThatDoesNotExist()

💀 Why it's dangerous:
• Completely disables the TypeScript compiler for that file.
• Silently ignores all type and syntax errors.

🛠 Use only when:
• You're working with untyped legacy code.
• You're debugging or temporarily disabling TS during migration.

Overall, my take:
• Prefer @ts-expect-error over @ts-ignore for long-term maintainability.
• Use ESLint rules like @typescript-eslint/ban-ts-comment to restrict or require justification for using these comments.
• In a real project, flag every @ts-ignore for later cleanup.

| Directive          | Scope       | Description                                      | Safe? |
|-------------------|-------------|--------------------------------------------------|--------|
| `@ts-expect-error` | One line    | Expect a type error. Fails if no error.         | ✅     |
| `@ts-ignore`       | One line    | Ignore any TS error on the next line.           | ⚠️     |
| `@ts-check`        | Whole file  | Enable TS checking in JS files.                 | ✅     |
| `@ts-nocheck`      | Whole file  | Disable all TS checking.                        | ❌     |

Use them wisely to reduce friction, not to hide problems.

This article is part of my personal note, as reminder of problems and learnings i encounter on my daily work. I did use AI to help build the article.
If you interested, follow.

Breaking Curse of Knowledge

Rickvian Aldi — Fri, 25 Oct 2024 02:32:41 +0000

At work, we spend years honing our technical skills, mastering fundamentals and frameworks, and optimizing our code. But there’s a common trap we can all fall intO

curse of knowledge.

This cognitive bias happens when you’ve worked on something for so long that you forget what it’s like not to know it, leads to poor communication.

I shares a bit of my experience.

Breaking the Curse of Knowledge: Simple Tips

Check Understanding
Don’t assume everyone is on the same page. Check in to see if others have questions or need clarification. What seems obvious to you may not be for them.
People can be in any quadrant:

Explain the “Why” First
Before diving into a solution or technical detail, explain why it's important or why you're suggesting it. It helps others follow along and understand the broader context.

Simplify Your Language
Avoid jargon or overly complex terms unless you’re sure your audience understands. If you need to use them, take a moment to explain.

Be Patient
Give people the space to ask questions and admit when they don’t know something. Encourage a culture where it’s okay to say, “I don’t understand.”

Give Reference: When Understanding Isn’t Critical Right Now
Sometimes, the person you're explaining something to doesn’t need to grasp every detail in the moment. In such cases, it’s often better to provide them with a reference or resource they can review later, on their own time. This way, you can move forward with your discussion without overwhelming them.

When to Give Reference:
Low Urgency: If understanding the concept isn’t essential to the current task, providing a well-sourced reference for later is ideal, allow them to enggage you through other async communcation channel such as chat, PR comments, etc
Complex or Technical Topics: Deep-dive topics often require more time to digest. A reference allows the person to absorb the information at their own pace.
Self-Directed Learning: Some people learn better by doing their own research. By providing resources, you empower them to take control of their learning process.
Example:
In a frontend development meeting, you may introduce a new framework but don’t need everyone to immediately understand its internals. You can say, “Here’s a link to the documentation for further reading. We’ll move on, but feel free to go through it later.”

Try Analogy: When You Need Immediate Understanding
In situations where the other person must understand now, simplifying the concept with an analogy can be extremely effective. Analogies work because they relate the unknown concept to something the person already understands.

When to Try Analogy:
High Urgency: If they need to understand right away to make progress, using an analogy can simplify complex ideas.
Breaking Down Complex Concepts: Analogies make difficult technical subjects more relatable by linking them to everyday experiences.
Engaging the Listener: People are more likely to grasp a new concept if they can relate it to something familiar.
Example:
When explaining how React’s state management works to someone unfamiliar, you could say, “Think of React’s state like the memory of a calculator. It stores the numbers and operations, and when something changes, the display (your UI) updates automatically.”
Though analogy is less accurate, I found this often worked better than giving definition.

here are gist for you
https://gist.github.com/rickvian/54fd86a1439ea81bef1b1ca2ac55bf13

Don't ask me to review your huge PR

Rickvian Aldi — Thu, 12 Sep 2024 08:10:48 +0000

TL;DR Huge PRs are bad. Break it to smaller PR,
”as small as possible, as big as necessary.”

There are lots of benefits on Smaller PR. I'm giving perspective of problem with huge PR provides better understanding of why it matters:

Problems of Huge PRs:
Complexity:
Difficult to understand the scope and impact of changes.
Increased chance of missing bugs or issues during review.

Review Fatigue
Reviewers may experience fatigue, leading to less thorough reviews.
Critical feedback may be overlooked.

Merge Conflicts
Higher likelihood of merge conflicts, especially in active codebases. Resolving conflicts can be time-consuming and error-prone.

Delayed Feedback
Engineers have other task to do, pushing them to review your huge PR soon will messed with their working schedule, this also means indirectly increase THEIR cycle time.
Longer review times delay the feedback loop.
Increases YOUR cycle time.
Slower integration of features or bug fixes into the main codebase.

Deployment Risks
Larger changes increase the risk of introducing significant issues.
Harder to isolate the root cause of problems if they arise post-deployment.

Reduced Collaboration
Larger PRs can discourage collaborative review processes.
Team members might find it challenging to stay informed about ongoing changes. Navigating history of Pull request will be painful

Disrespect to other engineer
unless you are inexperienced engineer, i will consider it disrespect to rise huge PR

Category
Estimated First-loop Review time needed (dedicating time)

Small PR
< 30 minutes

Medium
Up to 1 Hour

Large

1 hour

Subjective estimation and can change. Line and file changes may not be good proxy.

Rules & Guidelines

Non-urgent changes on app behaviour or refactor must include associated ticket to track history and reason why it done.

Split Large PRs:
Split large PRs into smaller, more manageable chunks.
in case you have bad commit management discipline, nothing stop you from creating multi PR in same ticket
feature/TASK-1234-part-1-scenario-a
feature/TASK-1234-part-2-scenario-b
feature/TASK-1234-part-2-test-and-refactor

But supposedly ticket shouldn’t be huge at first place. If i find i have huge PR, normally i will look at how i breakdown task in ticket and breakdown further.

Context and Documentation: Normally small enough PR already self explanatory. You may provide detailed descriptions and context for the changes to facilitate easier reviews.

Collaborative Review: if you must, for very large or complex PRs, consider collaborative reviews or pair programming sessions. This speed up feedback-loop process and allow everyone to understand further.

check existing SSH public key in Windows

Rickvian Aldi — Tue, 14 Nov 2023 14:47:00 +0000

To check your existing SSH public key in Windows, you can follow these steps:

Check Existing SSH Public Key in Windows (PowerShell, for Bitbucket use)
1.Open PowerShell.
2.Navigate to your SSH key directory (replace YourUsername if needed):

cd $env:USERPROFILE\.ssh

3.Display your public key:

Get-Content id_rsa.pub

4.Note: If id_rsa.pub does not exist, generate a new key:

ssh-keygen

parseInt vs _.toInteger vs _.toNumber

Rickvian Aldi — Tue, 07 Nov 2023 03:20:01 +0000

const _ = require('lodash')

const values = [
  null,
  undefined,
  '11text',
  'null',
  'NaN',
  'Infinity',
  '',
  '19.5',
]

values.forEach((value) => {
  console.log(`_.toInteger(${JSON.stringify(value)}):`, _.toInteger(value))
  console.log(`_.toNumber(${JSON.stringify(value)}):`, _.toNumber(value))
  console.log(`parseInt(${JSON.stringify(value)}):`, parseInt(value))
  console.log(`\n`)
})

Results:

_.toInteger(null): 0
_.toNumber(null): 0
parseInt(null): NaN


_.toInteger(undefined): 0
_.toNumber(undefined): NaN
parseInt(undefined): NaN


_.toInteger("11text"): 0
_.toNumber("11text"): NaN
parseInt("11text"): 11


_.toInteger("null"): 0
_.toNumber("null"): NaN
parseInt("null"): NaN


_.toInteger("NaN"): 0
_.toNumber("NaN"): NaN
parseInt("NaN"): NaN


_.toInteger("Infinity"): 1.7976931348623157e+308
_.toNumber("Infinity"): Infinity
parseInt("Infinity"): NaN


_.toInteger(""): 0
_.toNumber(""): 0
parseInt(""): NaN


_.toInteger("19.5"): 19
_.toNumber("19.5"): 19.5
parseInt("19.5"): 19

Step by step to work on Front end feature request

Rickvian Aldi — Wed, 26 Jul 2023 03:35:10 +0000

Ever think about your approach of doing a feature request?
I do, and sometimes i don't do it in consistent way,
sometimes i read the requirement and straight to the code, and just missing out some edge cases / scenario and i had to re-work my state, component structure

here are small notes from me, that i think an ideal step-by-step approach to complete a small feature request (consider it like a jira ticket if you use jira)

Define scenarios that you want to test as a unit test
Read the Acceptance criteria in the ticket (the requirement).
write blank test, without assertion first, but write the scenario and step by step to run it by using comment
if you use TDD approach, start writing the test after that
if you don’t use TDD approach for some reason, skip and do the unit test after the code is completed.
Don’t code yet, do little white boarding, or pen/paper to design your state, code, containers, components compositions, etc.
ensure your design can cover scenario 1 , 2, 3 of the unit test.
Break your plan into subtasks, make a checklist from it. (todolist, comments, whatever you like, but ensure you keep on track on every small thing you need to do)

⚠️this list will help you to focus.
for example you doing task A, and you just realized you need to add B and C, instead of getting distracted you can add B and C to the list first, and complete A first without switching back and forth doing different things.

Start code
develop to cover scenario 1, then cover 2, then 3 then etc…
If you haven't, Complete the unit test
Create commit, recommended to follow this approach https://www.conventionalcommits.org/en/v1.0.0/
then Raise a PR.

you can then continue to test the feature in your staging environment, and once passed, deploy to prod