DEV Community: Jay-Em

neovim-final-final: Why I Can't Stop Tinkering With My Dev Environment (And Why That's Okay)

Jay-Em — Fri, 05 Jun 2026 19:13:33 +0000

Let me paint you a picture.

It's a perfectly good Saturday afternoon. You had plans. Real plans. Maybe you were going to finish that side project, maybe finally write some tests (lol), or at the very least touch grass for twenty minutes.

Instead, you're 4 hours deep into your Neovim config, you've rewritten your keymaps.lua for the third time this month, your lazy.nvim plugin list has grown by six plugins you don't fully understand yet, and your repo—God help you—is named neovim-final-final.

Not neovim-config. Not dotfiles. neovim-final-final.

Because the one before it was final, and that was a lie, and you knew it was a lie when you named it, and you did it anyway.

Hi. My name is Josh, and I have a configuration problem. I'm not in recovery.

"Just Use VS Code" — A Eulogy

I did use VS Code. For a long time, actually. It's fine. It's great, even. It has extensions for everything, it works out of the box.

But at some point, something shifted. I'd be in the middle of coding and I'd think: this editor doesn't feel like mine. It felt like renting an apartment versus owning a house. Everything worked, but none of it was mine. I couldn't knock down a wall. I couldn't rewire the kitchen. The landlord (Microsoft) was always one update away from rearranging the furniture while I slept.

So I did what any completely normal, well-adjusted developer does.

I nuked it. Installed Neovim. And fell into a rabbit hole I haven't climbed out of since.

Credit where it's due: a big part of what pushed me over the edge was ThePrimeagen. If you've never watched him, he's a developer who moves through code so fast it looks illegal, and he does it all in Neovim. Watching him work made me feel like I was using a tricycle when I could be riding a motorcycle. He didn't just inspire me to switch editors — he inspired me to tinker. To care about the tools. To never just accept the defaults.

The First Config Is Always a Disaster (And That's the Point)

Here's what nobody tells you about switching to Neovim: the first week is a humbling experience.

Honestly, my first encounter with Vim wasn't even intentional. I made a git commit without the -m flag, and suddenly I was staring at a screen I did not ask for. I had no idea what it was. I just knew I was stuck. Couldn't type, couldn't exit, couldn't do anything. I literally Googled "stuck in commit can't exit" — not even "how to exit vim" — because I didn't even know it was Vim. That Stack Overflow question with 2 million views? I am one of those 2 million people.

And yet, somehow, that cursed moment planted a seed.

Fast forward to actually switching to Neovim full time: you forget how to save files. You accidentally enter some mode you've never seen before and the only way out is to close the terminal and pretend it never happened.

But then something clicks. You learn that every single thing—every keybind, every behavior, every color on your screen—is a choice you made. Nobody pre-packaged it for you. When your LSP starts working and Telescope fuzzy-finds a file in 0.1 seconds and your statusline shows exactly the info you care about and nothing else...

That feeling? That's ownership. That's craftsmanship. That's the closest thing a programmer gets to carving their name into something.

The Configs That Taught Me More Than Any Tutorial

Here's the dirty secret about tinkering with your dev environment: it's not actually about the tools.

Sure, I love my which-key setup. I love that I've bound <leader>\ to Telescope and <leader>gg to NeoGit and my fingers just know where to go without thinking. I love that my Neovim is fast—genuinely, disgustingly fast—in a way that VS Code on a good day can only dream about.

But what I actually learned from all of this:

How Lua works, because your Neovim config is just a Lua program. You are literally programming your editor.
How LSPs work—like, actually work. What a language server protocol is, why it exists, what mason.nvim is doing when it installs one.
How terminal multiplexing works, because once you go Neovim you inevitably end up in Tmux, splitting panes, managing sessions, and feeling like a wizard in a movie about hackers.
How to read documentation, because Neovim will teach you patience or it will break you. There is no middle ground.

None of that came from a course. It came from breaking things, reading the source code of plugins at 1 AM, and occasionally nuking the whole config and starting over.

Which brings me to something important.

The Nuclear Option Is Not Failure. It's a Feature.

I've deleted my Neovim config and started from scratch multiple times.

Every time, I told myself this is the final one. Every time, I was wrong. Hence: neovim-final-final. (Spoiler: there will be a neovim-final-final-v2. I've made my peace with this.)

And you know what? Each restart made my config better. Because I stopped copying configurations I found online wholesale and started understanding why things were structured a certain way. I stopped installing plugins because some YouTuber had them and started asking "do I actually need this, or does it just look cool in a demo?"

The tinkering is the learning. The mess is the process.

There's a certain type of programmer who looks at someone like me and says "that's a waste of time, just use the defaults." And look, I get it. Pragmatism is a virtue.

But there's something those programmers are missing: the act of configuring your environment forces you to understand it. You can't set up an LSP without learning what an LSP is. You can't write a keymap without thinking about your own workflow. You can't structure a Lua config without picking up at least some programming instincts.

Tinkerers aren't wasting time. They're learning sideways.

Tmux: The Part Where I Become Insufferable at Screen Shares

I need to talk about Tmux for a second.

Tmux is a terminal multiplexer, which is a fancy way of saying "multiple terminals in one terminal, with sessions that persist even when you close everything." It sounds niche. It sounds unnecessary. Every person I've shown it to in a screen share has said some variation of "wait, what just happened" followed by either genuine curiosity or quiet concern for my mental health.

I love it.

I have a Tmux session for every project. I detach, I reattach, I split panes horizontally and run my dev server on one side and my Neovim on the other. My workflow is a single terminal window and nothing else. No alt-tabbing. No losing focus. Just me, my keyboard, and a black screen full of text that somehow builds web applications.

Is this more efficient than having a normal setup? Genuinely, yes. I think so.

Is part of the appeal that it looks like I'm doing something extremely technical and impressive at all times?

...also yes. I'm not a saint.

There's also this other thing that happens during screen shares that I didn't expect: occasionally, someone will see my setup and just light up. Not confusion — recognition. They'll say something like "wait, are you using Neovim and Tmux?" and suddenly we're talking like old friends. It's happened with developers I've never met before, halfway across the world — and as a Filipino working remotely, that moment of unexpected connection hits different. It's like stumbling into a secret club. The terminal is the handshake. It's a small community, but it's ours.

Why You Should Try It (Even If You Don't Stick With It)

Here's my honest take: you don't have to use Neovim or Tmux forever. You don't have to commit. You don't have to throw away VS Code or Cursor or whatever IDE is paying your rent right now.

But you should tinker with something outside your comfort zone. Configure something from scratch. Break it. Fix it. Break it again. Name the repo something embarrassing like neovim-final-final because that's just the natural endpoint of caring about your tools.

Because here's what I've found: programmers who understand their environment write better code. Not because Vim makes you smarter (it doesn't, I've tested this on myself), but because the curiosity that drives you to customize your editor is the same curiosity that drives you to understand your codebase. It's the same instinct.

The tinkerers are the ones who ask "why does this work this way?" instead of accepting it.

And that question—why does this work this way?—is the most important question in this entire profession.

Go Break Your Config

Stop using default settings for everything (unless you have a deadline, in which case: godspeed, use VS Code, no judgment).

But when you have a free Saturday? Crack open a Neovim config. Spend four hours on a keymap. Name the repo something ridiculous. Feel the specific joy of your editor doing exactly what you want it to do.

It's worth it. I promise. And if you nuke the whole thing and start over, that's fine too.

That's just neovim-final-final-v2 waiting to happen.

Enjoyed this? Follow me for more programming blogs where I justify my terrible life choices with technical reasoning.

Catch you in the next one. 🚀

I Built an ORM That Starts With JSON So You Can Stop Overthinking Your Database

Jay-Em — Thu, 19 Feb 2026 03:36:05 +0000

You know that thing where you have a project idea at 1am, you're hyped, and then you spend the next 2 hours setting up Postgres, writing migrations, configuring connection strings, and by the time you're done your motivation is gone and you go to bed?

Yeah. That kept happening to me. So I built something about it.

What is SeedORM?

SeedORM is a Node.js ORM that stores everything in local JSON files. No database server, no Docker, no connection strings. You define your models and start building immediately.

Then when your project is ready for the real world, you migrate to Postgres with one command. Same models, same queries, same API. Nothing changes except where the data lives.

npm install seedorm

The Problem

Every side project I start follows the same pattern:

Cool idea hits me
Create new folder, npm init
Okay now I need a database
Do I use Postgres? MongoDB? SQLite?
Spend 30 minutes setting up Docker, env vars, connection pooling
Write migration files
I'm tired now
Abandon project

I wanted something where step 3 is just... skip.

How It Works

Define your models like you normally would:

import { SeedORM, FieldType } from "seedorm";

const db = new SeedORM();
await db.connect();

const User = db.model({
  name: "users",
  fields: {
    name: { type: FieldType.String, required: true },
    email: { type: FieldType.String, unique: true },
    age: { type: FieldType.Number },
  },
});

await User.init();

That's it. No database running. No config file pointing to localhost:5432. It just writes to JSON files in a data/ folder.

Now use it like any ORM:

// Create
const user = await User.create({ name: "Josh", email: "josh@hey.com", age: 24 });

// Query
const adults = await User.find({ filter: { age: { $gte: 18 } } });

// Update
await User.update(user.id, { age: 25 });

// Delete
await User.delete(user.id);

Relations

It supports the relation types you'd expect:

const Post = db.model({
  name: "posts",
  fields: {
    title: { type: FieldType.String, required: true },
    body: { type: FieldType.String },
  },
  relations: {
    author: {
      type: "belongsTo",
      model: "users",
      foreignKey: "authorId",
    },
  },
});

hasMany, belongsTo, manyToMany. They all work the same way when you eventually switch to Postgres.

The Studio

I got tired of opening JSON files to check my data, so I built a visual browser for it. Run seedorm studio and you get a web UI at localhost:4200 where you can browse collections, search across fields, paginate through documents, and edit records.

It's nothing fancy. It's just nice to have when you're building and want to see what's in your database without writing a query.

Per-Collection File Storage

One thing that bugged me early on was that everything was stored in a single seedorm.json file. With a few thousand documents across multiple collections, that file gets massive.

So now each collection gets its own file:

data/
  users.json
  posts.json
  comments.json

Each file is minified (single line), writes only happen for collections that changed, and if you have an old seedorm.json from a previous version it auto-migrates on startup. You don't have to do anything.

When You're Ready for Postgres

Your project took off. Congrats. Time for a real database.

seedorm migrate to postgres

Your models stay the same. Your queries stay the same. You just change the adapter config:

const db = new SeedORM({
  adapter: {
    adapter: "postgres",
    url: "postgresql://localhost:5432/myapp",
  },
});

That's the whole point. Build fast with JSON, switch when it matters.

What It's NOT

Let me be clear about what SeedORM is not:

It's not a Prisma replacement for your production app with 10 million users
It's not meant for high-concurrency workloads
It's not trying to be the last ORM you'll ever use

It's for prototyping, side projects, hackathons, and that 1am idea that deserves to exist without a 30 minute setup ritual.

Try It

npm install seedorm

GitHub
npm

If you try it, I'd genuinely love to hear what you think. What's missing? What's annoying? What would make you actually use this?

Thanks for reading.

Dart Extensions: Unleashing the Power of Your Code! 🚀

Jay-Em — Sat, 18 May 2024 02:04:50 +0000

Hello everyone! Welcome to another exciting post. I hope you'll find this one just as useful!! Arigatogozaimasuuu! 🎉

Have you ever felt limited by the built-in methods in Dart? Ever wished you could add your own methods to existing classes? Well, you're in luck because today I'm going to show you how to harness the magic of Dart extensions! 🌟

Extensions allow you to add new functionality to existing libraries. They're a game-changer for making your code cleaner and more readable. Let's dive right in!

Prerequisites

Dart SDK
A Dart project setup

Getting Started with Dart Extensions

First things first, make sure you have Dart installed. If you don't, you can download it from Dart's official website.

Creating Your First Extension

Let's say you want to add a new method to the String class. Here's how you can do it:

Open your Dart project and create a new file called string_extensions.dart.
Inside string_extensions.dart, add the following code:

extension StringExtensions on String {
  bool isPalindrome() {
    return this == this.split('').reversed.join('');
  }
}

What did we just do? We created an extension on the String class that adds a method called isPalindrome. This method checks if a string reads the same backward as forward. Cool, right? 😎

Using Your Extension

Now, let's use this new method in our project.

Import your extension into your main Dart file:

import 'string_extensions.dart';

Use the new method on any string:

void main() {
  String word = 'level';
  print('Is "$word" a palindrome? ${word.isPalindrome()}');
}

Run your Dart program, and you should see the output:

Is "level" a palindrome? true

Boom! You've just extended the String class with a custom method. 🚀

More Practical Examples

Let's explore some more practical examples to get you comfortable with extensions.

Example 1: Adding a `toCapitalized` Method

Sometimes you might need to capitalize the first letter of a string. Let's create an extension for that.

extension CapitalizedString on String {
  String toCapitalized() {
    return this.length > 0 ? '${this[0].toUpperCase()}${this.substring(1)}' : '';
  }
}

Example 2: Adding a `num` Extension

You can also extend numeric types. Let's add a method to double a number.

extension NumExtensions on num {
  num doubled() {
    return this * 2;
  }
}

Using the New Extensions

Don't forget to import your extensions and use them in your code:

import 'string_extensions.dart';

void main() {
  String name = 'dart';
  print('Capitalized: ${name.toCapitalized()}');

  num value = 42;
  print('Doubled: ${value.doubled()}');
}

Conclusion

That's it! You've just learned how to create and use Dart extensions to make your code more powerful and expressive. 🎉

Extensions are a fantastic way to add custom functionality to existing classes without modifying their source code. Use them wisely to keep your code clean and maintainable.

I hope you've enjoyed this post and found it useful. Stay tuned for more exciting content! 🚀

Auto update React app in Heroku upon git push on GitHub

Jay-Em — Sat, 16 Jul 2022 12:28:45 +0000

Hello everyone! This is going to be my first ever post here. I hope you'll find this useful!! Arigatogozaimasuuu!

Update: Heroku is not free anymore, these tutorial is outdated and will be updated soon

Have you ever wondered if it is possible to just push your application update in your Github repo and then it will auto re-deploy your app in Heroku? Well, stop wondering because today I will share you the process on how to setup one in your React app project and save you the hassle of searching it on your own!

We will utilize the use of what we call, "the magical" Github Actions. This is the main key that will unlock the possibility on how to make this idea come true.

I will assume that you already know how to create a Github repo, create an application in Heroku, and know the basics of Git. With that in mind, let us now start doing it!

Prerequisites

Setting up Github and Heroku

1) First, you need to create a Github repository and push your React project there. In my case, I just pushed the default React app created by using npx create-react-app.
2) After that, you can now create an app in Heroku. Just leave the tabs open for the moment ;)

Setting up your React app

3) Now in your project's root directory, create a new folder or a directory if that's what you want to call it, name it as server and then create a new file inside naming app.js and paste this code.

const path = require('path');
const express = require('express');
const port = process.env.PORT || 3000;
const app = express();

const publicPath = path.join(__dirname, '..', 'build');
app.use(express.static(publicPath));

app.get('*', (req, res) => {
res.sendFile(path.join(publicPath, 'index.html'));
}); 

app.listen(port, () => {
console.log(`Server is up on port ${port}!`);
});

What in the world does this code do? Well, if you read it carefully, it's just serving your app's public folder to the browser.

4) The project should look something like this.

5) Now open your favorite terminal, navigate inside the server directory of your React app, and initiate node.js by

npm init --y

6) Now from here, I recommend using yarn, and then install express.js by

yarn add express

7) After installing express you should probably add a .gitignore file containing node_modules inside. You don't want to push it in Heroku because of its massive size. It should look like this.

8) Navigate back to our project's root directory and create a Procfile file and paste this inside

web: node ./server/app.js

It should now look something like this.

Setting up the Github action

9) After adding that, open a new terminal and login to Heroku by typing

heroku login

If heroku is unknown to your system, you should install the Heroku cli first. It will open a login prompt in your browser. Just follow the instructions there and if it works, you should see something like this.

10) After successfully logging in, switch back to your previous terminal or open a new one and navigate back to your project's root directory. Commit all of your changes to your local branch, and add a remote branch for Heroku by typing in

heroku git:remote -a [name of your app]

It should look like this.

11) Now push your React app to Heroku by typing

git push heroku [your master branch]

My master branch is main so it should look like this.

12) After pushing it to Heroku successfully, from your project's root directory, create a new directory following this structure.

13) In the newly created file main.yml, paste this code inside.

name: Deploy

on:
  push:
    branches:
      - [gitmainbranch]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: akhileshns/heroku-deploy@v3.12.12 # This is the action
        with:
          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
          heroku_app_name: "[herokuappname]" #Must be unique in Heroku
          heroku_email: "[emailloggedinheroku]"

Replace [gitmainbranch] with your master branch or main branch.
Replace [herokuappname] with your Heroku app name.
Replace [emailloogedinheroku] with the email you use in your Heroku account.

This code is just a simple Github workflow that tells Github to auto update Heroku upon changes in the main branch of your React application.

With my setup, it should look like this.

14) In your Heroku account, go to account settings and reveal your API key, and guess what? Copy it.

15) In your Github repo, go to your repository settings and add a new secret named HEROKU_API_KEY and paste the API key you copied from Heroku.

16) We're almost done!!! Now save all files, commit all the changes and push it to your Github repo by

git push origin main

It should be something like this.

You're done! Congrats!

17) Hooray!! We're done! Try making some changes in your app and push it on Github repo by

git push origin main

or by merging a certain branch to your master branch. This action will be triggered whenever there's a change in your master branch. Once you've pushed a change, you'll see something like this in your action tab.

You'll also gonna see the logs in your Heroku app

Thanks!

That's it! You have now successfully setup your Github-Heroku workflow that will auto update your deployed React app on the go.
I hope you've liked my first content here at DEV! I will post more in the future! Please see my website to know me more! Thanks!

DEV Community: Jay-Em

neovim-final-final: Why I Can't Stop Tinkering With My Dev Environment (And Why That's Okay)

"Just Use VS Code" — A Eulogy

The First Config Is Always a Disaster (And That's the Point)

The Configs That Taught Me More Than Any Tutorial

The Nuclear Option Is Not Failure. It's a Feature.

Tmux: The Part Where I Become Insufferable at Screen Shares

Why You Should Try It (Even If You Don't Stick With It)

Go Break Your Config

I Built an ORM That Starts With JSON So You Can Stop Overthinking Your Database

What is SeedORM?

The Problem

How It Works

Relations

The Studio

Per-Collection File Storage

When You're Ready for Postgres

What It's NOT

Try It

Dart Extensions: Unleashing the Power of Your Code! 🚀

Prerequisites

Getting Started with Dart Extensions

Creating Your First Extension

Using Your Extension

More Practical Examples

Example 1: Adding a toCapitalized Method

Example 2: Adding a num Extension

Using the New Extensions

Conclusion

Auto update React app in Heroku upon git push on GitHub

Prerequisites

Setting up Github and Heroku

Setting up your React app

Setting up the Github action

You're done! Congrats!

Thanks!

Example 1: Adding a `toCapitalized` Method

Example 2: Adding a `num` Extension